Rail Governance

Fiduciary and Agency Law Exposure When AI Executes Customer-Directed Transfers

Editorial team · · 11 min read
Cover illustration for “Fiduciary and Agency Law Exposure When AI Executes Customer-Directed Transfers”
AI Accountability · October 4, 2026 · 11 min read · 2,443 words

When an AI agent executes a customer-directed transfer, it does something no banking statute was written to handle. It acts as an instrument of the bank, a delegate of the customer, and a decision-maker in its own right, all at the same moment, and no existing legal category is built to hold all three roles at once. Regulation E, UCC Article 4A, agency doctrine, fiduciary duty: each of these frameworks assumes a human actor who forms intent, receives instructions, and can be held responsible when those instructions get ignored. Regulation E defines an unauthorized transfer as one "initiated by a person other than the consumer without actual authority to initiate the transfer and from which the consumer receives no benefit." That wording presumes a human being on the other end of the keyboard who configured the scope themselves.

The novelty isn't that AI has shown up in banking. Recommendation engines and fraud-scoring models have lived inside banks for years, and the law mostly shrugged at them because a human still pressed the button. Agentic AI presses the button itself. It completes multi-step workflows, moves funds, and creates a settled fact on the payment rails before a single human reviews what happened. An IMF analysis makes the structural point directly: RTGS systems, card networks, and instant payment platforms run deterministically. Transactions follow preset rules, outcomes are binary, and legal finality is guaranteed by design. That means an agentic error isn't a draft that gets corrected before it goes out: it's a wire that already landed.

That single fact, finality arriving before review, is what forces Regulation E, agency law, and fiduciary doctrine into a role none of them were drafted for. Each of the sections that follow takes one of those frameworks and asks the same question from a different angle: who answers for an action that was never really a human decision?

How agency law applies to an AI actor

Agency law is the closest fit available, and starting there is the clearest way to see where the fit runs out. The doctrine was built to govern relationships between legal persons: a principal who grants authority, and an agent who exercises it. An AI agent is neither of those things in the statutory sense, and that gap in categorization is exactly where a bank's exposure opens up.

The whole doctrine turns on scope of authority. A human agent who exceeds the authority a principal granted creates a clean allocation of blame: the principal answers for apparent authority, and the agent answers personally for acting outside the lines. That personal liability is the hinge the whole system swings on, and without it the system has nothing to hinge on.

Take an AI agent that exceeds its configured scope, whether by misreading an instruction, hallucinating a payee, or acting on a corrupted input. There's no agent in the legal sense to hold personally responsible. The question doesn't resolve, it just moves. It lands back on the bank and the customer, with nowhere else to go.

That leaves the bank sitting in three positions at once, and none of them clean. The bank deployed the agent, which makes it look like the principal. The customer configured what the agent was allowed to do, which makes the customer look like the principal instead. And the agent's underlying decision logic may run on a model built by a third-party provider the law doesn't yet treat as a party to the transaction. Agency liability depends on whether the harm came from the agent's own conduct or from the principal's instructions. That line is hard enough to draw with a human agent who made a judgment call. It gets structurally unclear when the "conduct" in question is a probabilistic inference rather than a deliberate choice, because there was no moment of deliberation to point to.

One might argue the law already covers this well enough: if the bank deployed the agent, the bank pays for what it does, and apparent authority doctrine handles the rest. That argument settles who writes the check. It doesn't settle what the bank had to do beforehand to avoid writing it. Apparent authority tells you who pays. It says nothing about what governance the bank needed in place, what counts as an adequately scoped authorization, or whether a customer who configured an agent has satisfied the duty to safeguard credentials that Regulation E assumes a human account holder owes. Those questions stay open even after the liability check gets written, and they're the ones a bank actually has to answer before anything goes wrong, not after.

Where Regulation E's authorization framework meets an agent-initiated transfer

Regulation E was built around a binary: a consumer either authorized a specific transfer, or they didn't. That binary is clean when a human decides to send money. An AI agent operating under delegated scope breaks it, and once it breaks, neither the bank nor the consumer is left with a clear liability position when something goes wrong.

The statute assumes human intent at two separate points: the consumer who grants access to the account, and the person who initiates each individual transfer. A consumer who turns an AI agent loose on their account has authorized that agent to exist. That's not the same as authorizing every transaction the agent later decides to make. Whether granting an AI agent account access satisfies Regulation E's authorization requirement at the transaction level is a question the statute doesn't answer, and right now nobody can answer it with confidence. Regulation E also has nothing to say about what happens when an agent, once granted access, violates the consumer's actual instructions. Is that an unauthorized transfer the bank absorbs, or a consumer-negligence failure the consumer absorbs? The statute doesn't tell you, because it was never asked the question.

Consider the hallucination scenario, because it's the sharpest version of this problem. An agent misreads ambiguous instructions and sends money to the wrong payee. The consumer did authorize the agent. The agent did act on what it understood the consumer to want. No third party without authority touched the transaction. Every fact Regulation E checks for comes back looking like an authorized transfer, and yet the outcome is a misdirected payment the consumer never intended and would never have approved if asked directly. The statute has no category for an authorized actor making an unauthorized mistake.

That gap is the mechanism that turns an operational AI error into a balance-sheet event for the bank, because there's no statutory framework sitting in the gap to decide who absorbs the loss. Whoever ends up paying, pays because no court or regulator had already drawn the line, not because the line was clear.

The fiduciary duty question: whether deploying an AI agent that acts on a customer's behalf creates a new fiduciary exposure for the bank

A bank that deploys an AI agent to monitor a customer's financial position and execute transfers on their behalf may be building something courts will later call a fiduciary relationship, whatever the bank's contracts say about it. The contractual disclaimer and the functional reality can point in opposite directions, and courts have historically cared more about the second one.

Fiduciary duty attaches to relationships built on trust and discretion. A party with discretion over someone else's assets has to act in that person's best interest, not just follow instructions mechanically. An agent configured to "optimize yield" or "manage liquidity within a low-risk profile" exercises judgment over a customer's money, deciding among options the customer never specifically approved. That's the exact kind of discretion that has triggered fiduciary analysis in other contexts for decades. A bank's terms of service might disclaim any advisory or fiduciary role outright, but courts evaluating fiduciary status look at what the relationship actually does, not just what the contract calls it.

The exposure sharpens when the agent's optimization logic quietly diverges from the customer's actual interest in ways the customer has no way to see. Picture an agent that routes transfers in a way that happens to serve the bank's own liquidity position better than it serves the customer's yield. No one at the bank made that call on purpose. The agent made it on its own, chasing whatever metric it was told to optimize. But the structural facts of a fiduciary breach can exist without a single human decision behind them. That's the core of what's been called the "Fiduciary Gap" in agentic banking: a programmable institution needs fiduciary boundaries built into the system itself, safeguards that keep the agent acting in the client's long-term interest rather than just chasing one optimization target efficiently. An AI agent without those constraints coded in can breach a fiduciary duty with no bad decision from anyone to point to.

The obvious counterargument: banks have never been fiduciaries to ordinary deposit customers, so an AI agent can't manufacture a duty that never existed. That's true as far as it goes, but it answers the wrong question. The exposure here doesn't come from the deposit relationship. It comes from the discretionary account management relationship the agent itself creates the moment it starts exercising judgment over the customer's assets. That's a different relationship from a checking account, and it's exactly the kind of relationship courts have been willing to classify as fiduciary based on what it does, regardless of what the account was originally called.

The regulatory gap in SR 26-2 and banks' own governance standard for agentic transfers

The April 2026 interagency model risk guidance places agentic AI outside its own scope. That means the banks most exposed to everything described above are operating without a regulatory safe harbor at precisely the moment their legal exposure is highest. A missing standard doesn't lower what examiners expect. It raises it, because examiners apply existing principles to new technology whether or not an agency has written them down for this specific case.

The same IMF analysis names the risks supervisors will look for regardless of whether agent-specific guidance exists yet: traceability, opacity, systemic effects including correlated behavior across agents, cybersecurity, and legal uncertainty. None of those risks wait for a rulebook to materialize before an examiner starts asking about them.

In the U.S., NYDFS Part 500, amended in 2023, comes closest to an operational standard. It requires covered institutions to run risk assessments, maintain access controls, and keep audit trails for their information systems. The 2023 amendment itself never mentions AI by name, but an October 2024 NYDFS industry letter confirmed those requirements apply to AI systems handling nonpublic information. Until something more specific arrives, Part 500 functions as the de facto floor for agentic AI governance, simply because nothing more tailored exists yet.

The EU shows a parallel version of the same gap. The AI Act's high-risk obligations for standalone Annex III systems now apply from December 2, 2027, following the Digital Omnibus deferral enacted on July 27, 2026. A bank running an agentic system that executes client transactions sits under both AI Act deployer obligations and its existing conduct and safeguarding rules at the same time. But whether these systems even count as high-risk isn't settled. The regulator's Article 6 high-risk classification guidelines weren't finalized as of mid-2026, though draft guidelines came out on May 19, 2026, and are still open to stakeholder input. A bank in either jurisdiction is building controls against a target that regulators haven't finished drawing.

Authorization traceability requirements for AI agents

Diagram: Mandate-Based Authorization vs. Broad Access Grant. Visualizes: Contrast two authorization models side by side: the current broad-access model (a vague, one-time grant of account access made 'weeks or months earlier' covering 'whatever the…

The hardest problem here isn't logging that a transaction happened. Every system does that already. The hard part is reconstructing the relationship between what the customer actually asked for and what the agent actually did, in enough detail that an examiner can tell whether the action was authorized, stayed within scope, and matched the customer's intent. That reconstruction is what every legal gap in the sections above is actually asking for, whether the statute says so directly or not.

The IMF's analysis points to several emerging responses, and each one maps onto a specific gap already described: mandate-based authorization, architectural separation of decision-making from execution, agent identity frameworks, programmable payment controls, audit trails, and tiered human-in-the-loop review.

Mandate-based authorization answers the problem that Regulation E's authorization framework can't resolve for agent-initiated transfers. Instead of a broad access grant that covers "whatever the agent decides," the agent's authority gets defined as a specific, bounded mandate: which payees qualify, what the dollar ceiling is, how often it can act. Each transaction gets checked against that mandate rather than against a vague grant of access made weeks or months earlier. Architectural separation addresses the difficulty of knowing why an agent acted the way it did: when the reasoning step and the execution step get recorded as two distinct events, the record shows not just what got paid but what the agent believed it was doing when it paid it. Agent identity frameworks resolve the difficulty of identifying who the principal is by giving the agent its own distinct identity in the transaction record, separate from the customer and separate from the bank, so a liability analysis actually has somewhere to point.

Voice and conversational interfaces raise the bar further. The audit trail has to survive the call itself, the quality-assurance review after, and a regulator's request that might come years later. Every action needs to be reconstructable: who started the interaction, when, what they actually asked for, what the agent said back, which tool calls fired as a result, and what the account of record shows afterward. Article 50 of the EU AI Act requires providers of AI systems that interact directly with people, voice agents included, to make sure users know they're talking to AI unless that's already obvious from context. That disclosure duty took effect August 2, 2026, and wasn't delayed by the Digital Omnibus negotiations. The Omnibus did carve out a narrow four-month grace period, to December 2, 2026, but only for the machine-readable marking sub-obligation under Article 50(2), and only for generative AI systems already on the market.

The FIS Financial Crimes AI Agent, built with Anthropic and in development with BMO and Amalgamated Bank, shows what governance-by-design looks like in practice. Amalgamated Bank's Financial Crimes Compliance team was embedded directly in the design process, so the resulting agent reflects how investigators actually work rather than how an engineering team assumed they worked. The agent's decisions stay traceable and auditable inside FIS-controlled infrastructure. That's the shape every mitigation in this section is reaching toward: not a system that works well most of the time, but a chain of custody detailed enough that someone can walk it backward, months later, and name who decided this.

Sources

  1. How Agentic AI Will Reshape Payments in: IMF Notes Volume 2026 Issue 004 (2026)
  2. AI Agents Under EU Law
  3. AI Agents and the Law
  4. AI Agents in Payments: Applications, Risks and Regulations
  5. Agentic Transaction Security Framework
  6. Governing AI Agents
  7. Governing Generative AI Across Financial Institutions: An SR 26-2-Compatible Framework for Generative AI Risk Control

More in AI Accountability