Before AI Agents Trade on Your Behalf: Verifying Delegated Authority in Finance

Imagine an AI agent buying and selling mutual funds on your behalf. What sounded like a distant possibility only a few years ago is now being treated as a practical design problem by financial institutions.

The hardest question may not be whether the model can identify and execute a trade. It is whether the institution can verify—both at the time of the transaction and afterward—that the customer authorized that specific agent to take that specific action.

What the new subcommittee is—and is not

On June 30, 2026, Mitsubishi UFJ Financial Group, Inc. (MUFG) and Mitsubishi UFJ Trust and Banking Corporation (the Trust Bank) announced the establishment of the “AI Agents and Financial Transactions” subcommittee within the DID/VC Co-Creation Consortium (DVCC), which is organized by the Trust Bank.

MUFG is a global financial services group and one of Japan’s largest banking institutions. The Trust Bank is its wholly owned trust-banking subsidiary and a core company within the group.

The subcommittee brings together 28 participating organizations—financial institutions, vendors, and legal counsel, including two organizations whose names were not publicly disclosed. It is expected to operate from July 2026 through March 2027.

It is worth being precise: this is not a mechanism going live. According to the announcement, the subcommittee will examine how to ensure the reliability, safety, and transparency of transactions in an era when AI agents autonomously execute transactions involving financial products on customers’ behalf. It will also address the practical, legal, and governance issues involved. In particular, it will organize the issues around defining and proving the scope of delegation and the verifiability of execution results. It will assess the potential uses and implementation requirements of verifiable credentials (VCs) as a supporting technology. And it will design an architecture, with a proof of concept using actual systems planned for fiscal 2027 (which begins in April 2027 in Japan).

In other words, this is not a set of settled answers. It is an early effort to identify—grounded in financial practice—what must be verifiable before a task can be delegated. That framing is what this article focuses on.

Why verifiable delegation matters in financial transactions

An AI that selects products, places orders, and pays on a customer’s behalf is often described as “agentic commerce.” Technical standardization in this area is advancing internationally, centered on e-commerce and payments.

In transactions involving financial products, the nature of the difficulty changes. The announcement notes that, beyond customer protection, accountability, and AML/CFT (anti-money-laundering and countering the financing of terrorism), several legal and governance requirements must be addressed. One example is how contracts entered into by an AI agent without reflecting the customer’s intent would be treated under Japan’s Civil Code. These are questions of Japanese financial and civil law, not a claim about any other jurisdiction.

Put differently, in finance the question that comes before “can the AI trade well?” is this: can we later reconstruct and verify on whose authority, and within what limits, a transaction was carried out? This is a challenge that is independent of raw model performance. Our position is that what matters most in an AI’s decision-making is not intelligence itself but the design of the authority it is given. Delegated trading in finance is where that principle is tested most rigorously.

Three layers of verification

Verifiable delegation is not a single thing, and what must be verified is not monolithic. It helps to divide it into three layers. The issues the subcommittee raises map broadly onto them.

Identity: Who authorized which agent?

The first layer concerns identity and the chain of authority. Who is the customer behind the transaction? Did that customer actually authorize the action? And is the agent placing the order the same agent that received the authorization? Only when these connect does the transaction have a firm starting point.

The announcement lists confirming the customer’s identity first among the items financial institutions should check, and that corresponds to this layer. If the customer is impersonated, the authorization record is invalid, or the agent is misidentified, the rest of the control design rests on a faulty foundation.

Confirming the customer’s identity connects to existing know-your-customer (KYC) practice. But confirming which agent holds which authority, and from whom, is not settled by identity alone. Beyond verifying the customer, an institution must separately confirm the agent’s identity, the establishment of the authorization, and whether that authorization is currently valid.

Scope: What may the agent do, under what limits, and for how long?

The second layer is the scope of delegated authority, and it needs the most careful construction in practice. A common mistake is treating “delegate a trade” as a single permission. In reality it contains several categories of authority that differ in character. In the future picture the subcommittee presents, these actions are drawn as separate steps:

• Search and comparison of information (gathering data on issues and products)
• Recommendation and selection support (narrowing down and presenting candidates)
• Investment decisions (allocation and timing)
• Application and contracting (the contractual act of buying or selling a product; some businesses separate order generation from external submission)
• Settlement (payment of funds)
• Post-trade management (recording, reconciliation, and monitoring)

These differ greatly in their impact on the customer, their monetary risk, and their reversibility after execution. Authority that only gathers information is not the same as authority that reaches into contracting or settlement. In particular, authorizing a product’s application and contracting and authorizing its settlement should be designed as separate steps. Not treating a trade as one broad permission is the starting point of the design.

One caveat: “it is only information-gathering, so allow it broadly” does not always hold. Search and comparison are not low-risk when they involve access to confidential or personal data, and the range of data that can be referenced should also be treated as subject to limits.

On top of that, each authority is given explicit limits. Examples include monetary caps (per transaction and per period), the range of eligible products or accounts, the range of permitted actions, a cap on the number of transactions, and an expiration. It is the same approach used when granting authority to an employee—scope of duties, approval limits, validity period, records, and revocation, defined as a set—applied to an AI agent.

What is easily overlooked is that being able to configure an expiration or a revocation is not enough. Authorization can be revoked partway through. So at the moment a transaction executes, the system must be able to confirm whether that authorization is still valid, or has already expired or been revoked. A credential valid at issuance is not necessarily valid at the moment of use. Only when this real-time validity check is included does the scope of authority hold up in practice.

Execution: Did the agent act within its authority?

The third layer is the verifiability of execution results: keeping records so that, after a transaction ends, you can reconcile what was actually executed against the scope of authority. The “record of the basis for consent to the transaction” and the “verifiability of execution results” cited in the announcement belong here.

In practice, the institution must be able to reconstruct what happened: which customer granted the authority, which agent acted under it, what the agent did, and when. It must then be possible to compare that action with the authorized scope.

Here, explainability and auditability are not an either-or choice. Explaining a decision to a customer requires organizing its rationale. Responding to incident investigations and disputes requires an audit trail that lets you trace what actually happened. Rather than waiting only for a complete internal explanation, we prioritize designing, in advance, a state in which authority and execution records can be reconciled. An audit trail alone does not determine where legal responsibility lies, but it is a prerequisite for confirming whether authority was exceeded and for examining the facts and the responsibilities that follow.

Valid authority does not make a transaction suitable

It helps to separate two ideas that are easy to conflate. Whether an authorization is valid and whether the transaction is suitable for the customer are different questions.

A trade can be correctly authorized and executed within its limits, yet still be unsuitable given the customer’s risk tolerance, knowledge, or means. So, apart from the three-layer verification, cross-cutting controls are needed: investment suitability (is the product right for the customer), customer protection, accountability, and AML/CFT. That the announcement includes these among its topics reflects a simple point: verifying authority alone cannot secure the soundness of a financial transaction.

Verifying the authorization chain secures the validity of the entry point. Whether the trade should happen at all is a separate judgment, checked at a separate gate.

VCs may support verifiable delegation—but they are not the whole solution

The technology the announcement names to support this verification is the verifiable credential. What it says it will assess for potential use and implementation requirements is, mainly, the VC.

Verifiable credentials are tamper-evident digital credentials containing claims made by an issuer about a subject. A holder can present a credential to a verifier, which can then validate its provenance and integrity. In this context, a VC might represent the scope of delegated authority, such as eligible products, transaction limits, permitted actions, and an expiration date. However, a VC does not by itself establish that every claim is substantively true, that the authorization still reflects the customer’s current intent, or that a transaction satisfies applicable suitability requirements. What a VC can help verify is mainly who issued which content, and whether that content has been altered.

Even if VCs are adopted, where to record a revocation or suspension, and how to confirm the current status at the time of a trade, must be designed separately.

As for the decentralized identifier (DID), the DVCC itself advocates business co-creation of VCs linked with DIDs. But what this subcommittee explicitly names as a concrete object of study is chiefly the potential use and implementation requirements of VCs. A concrete technical configuration that includes DIDs is not laid out in this announcement. Presenting VCs or DIDs as an all-purpose answer would not be accurate today. Whatever the mechanism, the design of what must be verified and controlled—the three layers plus the cross-cutting controls above—comes first, and technology is how you implement it.

Authority design matters as much as model performance

Model capability is not enough. The decisive question is whether the organization has defined, and can enforce, the agent’s authority: which actions it may take, within what limits, for how long, and subject to which approval, suspension, and revocation conditions. That this subcommittee begins from organizing questions of verifiable delegation and governance, rather than from a performance race, aligns with that view. What is needed is not that the AI can call itself the customer’s proxy, but that you can verify who authorized which agent, what actions were permitted, within what limits, and for how long; that the authority was still valid at the moment of the trade; and that the execution fell within the authorized scope.

This does not mean that every transaction should require human approval. A more practical approach is to apply controls in proportion to the action and its consequences. Lower-impact, reversible actions may be automated more broadly, but only within clearly defined data-access limits. Contract formation, order submission, and settlement should be subject to stricter limits, time-bound authorization, real-time validity checks, and human review when specified thresholds or exceptions are triggered. Prediction, judgment, and execution should not be lumped together; the design should vary layer by layer.

As a starting draft for your own review, here is what to decide first in authorization design. This is only one example; the specific thresholds and degree of human involvement are for each organization to set. In finance, legal, contractual, and customer-protection constraints come before an organization’s own risk tolerance.

What to decide	Example	Main enforcement point
Action authority	Search and compare only; contracting and settlement tools unavailable	Authorization service / tool allowlist / API
Monetary cap	Per-transaction, daily, and monthly limits	Trading system / settlement system
Scope	Limited to pre-approved product sets and accounts	Authorization layer / trading system
Expiration	Automatic lapse on expiry	Delegation management platform / authorization service
Revocation / emergency stop	Immediate stop by customer or administrator	Delegation management platform / trading gateway
Real-time status check	Confirm expiry and revocation status just before an order	Trade execution system
Human involvement	Re-approval above a threshold, on exceptions, or on cap breach	Approval workflow
Re-delegation	Prohibited by default, or limited to specified delegates	Authorization policy
Audit trail	Record delegation ID, agent, action, timestamp, and result	Trading system / audit log platform

The right-hand column is labeled “enforcement point” rather than “location” for a reason. Instructing an AI agent not to handle a product is different from having the system actually refuse that action. Important authority must be enforced not by prompts or agent settings alone, but at boundaries such as the API, the authorization service, and the trading system. The line-drawing of action authority and the conditions for human involvement live in internal business rules and approval flows. Caps on amounts and counts live in the system that executes trades. Managing an authorization’s validity lives in the issuance and verification platform. Treat these as one and assume that configuring the agent will suffice, and you may fail to restrict anything effectively.

In our own publishing workflow, generation, review, approval, and publication are separate steps. Financial transactions involve far greater legal and monetary risk, but the same separation-of-duties principle applies: decompose the actions, define the authority, and establish intervention and stopping points before automation begins.

The subcommittee’s discussions are still ahead. But even while awaiting its conclusions, if your organization plans to entrust anything to an AI agent, documenting who authorized what, within what limits, and for how long—and how that is verified—is a practical first step toward the era ahead.

Sources and date of review

This article was prepared as of July 2026, drawing primarily on the joint announcement by Mitsubishi UFJ Financial Group and Mitsubishi UFJ Trust and Banking Corporation, “Establishment of the ‘DID/VC Co-Creation Consortium — AI Agents and Financial Transactions Subcommittee’” (June 30, 2026). The subcommittee’s topics, participating organizations, and schedule, as well as the positioning of the related institutions and technologies (VC and DID), may change. Please confirm the latest details in each party’s official announcements.