Chopra's AI agent liability split: the bank challenge
Two very different answers to the same question are now on the table. From November 24, Wells Fargo's updated terms treat any instruction an AI agent submits with a customer's credentials as authorized by the customer, “without further verification.” Whatever the agent does, the customer did.
Rohit Chopra set out the opposite view in an interview with Politico. The former director of the Consumer Financial Protection Bureau is now Secretary of California's Business and Consumer Services Agency, which has said it will investigate how businesses deploy AI. In his two-way split, the consumer pays in neither case. If an agent strays from the consumer's instructions, the developer is liable. If a bank or service provider accepts instructions that don't reasonably look like the consumer's, the bank or provider is liable. He also wants agents treated as products under product liability law, which is generally stricter than liability for services.
His is one proposal among several, but it draws a line other proposals are converging on.
When the agent strays, the developer pays
The first limb has growing support from very different directions. In Congress, Rep. Lori Trahan's draft CLAIM Act would hold AI developers liable when their systems cause harm that would be unlawful if a person did it, unless a user or intermediary was at fault. Bank Policy Institute staff argued that AI agents serve their developers rather than their users, and that developers shouldn't be able to disclaim liability for the losses they cause. And Lead Bank's proposed liability waterfall puts model defects and inadequate safeguards on the AI provider.
The difficult part is deciding when an agent has strayed. If a customer gives an ambiguous instruction and the agent reads it in a way that's reasonable but wrong, it isn't obvious that's the developer's fault. The CLAIM Act's exception for user fault raises the same question from the other side: does a loosely worded instruction count as the user's fault? Until courts or regulators draw that line, expect it to be argued case by case, and often in litigation.
There's also the question of who the developer is. It could be the AI lab that built the underlying model, or the company that built the agent on top of it and put it in front of the customer, and they're often not the same business. The largest labs have deep pockets. Many of the companies building consumer agents on their models are young and thinly capitalized. A developer's liability is only as good as its ability to pay, and assigning responsibility to a company that can't cover a loss, or that no longer exists, doesn't make the customer whole.
When the instruction doesn't look like the customer's, the bank pays
The second limb is harder, because it's partly a verification problem and partly a question of intent. When an agent logs in with the customer's username and password, every instruction looks like the customer's, because to the bank it is. A bank can't decline an instruction that doesn't look like the customer's if it can't tell the customer, an agent the customer authorized and a rogue agent apart.
Intent means asking what the customer was trying to do, and whether this is usual for them. Card issuers have become good at this over the years. A purchase that doesn't fit a cardholder's pattern gets held, and the customer gets a text asking them to confirm before it goes through. Current account banking hasn't applied the same logic as consistently to money leaving an account. Agents raise the stakes, because an agent doesn't behave like its owner. To judge what's usual, a bank first needs to know it's dealing with an agent, and whose.
This is where Chopra's split and Wells Fargo's terms collide most directly. Under his test, a bank that accepts an instruction that doesn't reasonably look like the customer's is liable, which in practice means it has to check. Under Wells Fargo's terms, accepting it without further verification is the stated policy.
What “looks like the customer” would take
For the second limb to be workable, a bank needs to know that an agent is acting at all, which company stands behind it, and what it has been permitted to do. The OCC's new examiner framework points to the same things for outside agents: identity, provenance and delegation.
It's worth being precise about who does what. Judging whether an individual instruction fits a customer's normal behavior is the bank's own fraud-control job. Knowing which company stands behind an agent, and whether that company is still in good standing, is a network job, and one no bank can do well alone when the same agents are knocking on every bank's door.
The gaps the split leaves
Two cases still fall between the limbs. An agent can follow its instructions perfectly while the company behind it has been compromised. And, as above, a developer can be liable on paper but unable to pay. Both point to the same need: knowing who is in the chain, and how their risk is changing, before something goes wrong. Banks are already feeling its absence. In Canada, where several of the largest banks have now blocked outside agents, RBC has cited liability, a lack of visibility into agent-initiated transactions and consent as its reasons.
The split only works on identified routes
Chopra's model gives customers far more protection than terms that put everything on them. But it only works if banks can tell whose agent they're dealing with, and credential sharing makes that impossible. Bringing agents onto identified, permissioned routes, knowing the companies behind them and whether they're still in good standing, and agreeing across the chain where liability lands is what makes either limb enforceable. That's the infrastructure Invela is building.
Invela is the infrastructure layer that makes open finance trustworthy - accrediting who's in the network, monitoring risk in real time, and ensuring liability lands in the right place.
