Know what is on your site before a plaintiff’s firm does.Free website scanScan Your Site
Log in Sign up Book a demo
Home› News› Wells Fargo Wants Proof You Fired Your AI…
NEWS

Wells Fargo Wants Proof You Fired Your AI Agent. Federal Payments Law Hasn’t Caught Up

Wells Fargo customers who hand an AI agent their online banking login will soon carry a new obligation: if they want the agent to stop, they have to be able to prove they told it to.

Nov 3, 2026 1 min read

Wells Fargo customers who hand an AI agent their online banking login will soon carry a new obligation: if they want the agent to stop, they have to be able to prove they told it to. An updated version of the bank’s Online Access Agreement, effective November 24, 2026, makes customers responsible for revoking an AI agent’s authorization, requires them to keep evidence of that revocation and hand it over on request, and states that until the bank is notified, the customer “remain[s] responsible for all the AI Agent’s activities, to the extent permitted by law or regulation.”

American Banker, which first reported the clause on November 2, described Wells Fargo as apparently the first U.S. bank to tie customer liability to proof of revocation. JPMorgan Chase has already rewritten its own Digital Services Agreement along similar lines. The changes land in a gap that federal payments law has never had to fill: what happens when the “person” a consumer authorized to use an account is software, and that software does something the consumer never asked for.

Ghibli-style painting of a small-town bank on a rainy evening, a glowing paper-and-brass robot courier leaving the vault with envelopes of coins while a worried customer holds a lantern and a torn permission slip at the door

What the Wells Fargo terms actually say

The relevant language sits in a new Section 15 of the upcoming Wells Fargo Online Access Agreement, titled “Third-Party Artificial Intelligence Agents or Agentic AI.” It does not ban agents. It shifts the risk of using them onto the customer, and it does so in broad terms.

  • A wide definition. An “AI Agent” is “any software, application, program, or other technology that takes autonomous, semi-autonomous, or non-autonomous action on behalf of any person or entity.” Read literally, that reaches far beyond chatbots to budgeting apps, scripts and browser extensions.
  • Deemed authorization. If a customer gives an agent their login credentials or otherwise authorizes it, any instruction, action or transaction the agent initiates is “deemed to have been initiated and authorized directly by you, without further verification.” The bank says it has no obligation to investigate the agent’s authority.
  • Risk on the customer. Use of an agent is “AT YOUR OWN RISK,” in the bank’s capitals. The customer is responsible for monitoring the agent, keeping it within its authority, and, unless law provides otherwise, for unintended actions, actions caused by “incomplete, inaccurate, or manipulated inputs,” and the agent exceeding its authority.
  • Proof of revocation. Section 15(f) requires the customer to revoke authorization “properly and timely,” retain evidence of the revocation and provide it at the bank’s request. Responsibility continues until the customer notifies Wells Fargo under the agreement’s security section.
  • Privacy carve-out. The bank says it does not monitor or certify any agent’s security or data handling, that its own privacy and security policies do not apply to the agent, and that a customer using an agent “expressly consent[s] to the sharing” of financial, account and personal information with it.
  • Bank controls reserved. Wells Fargo may require customers to register agents, change or shut API access, and restrict or terminate any agent’s access.

Asked what counts as evidence of revocation, a Wells Fargo spokesman told American Banker that customers may authorize or revoke an agent “outside of Wells Fargo,” and that the agreement asks them to keep a record because the bank “may not otherwise have visibility into when that occurred.” The bank did not say what form of record it would accept.

Chase took a different route to a similar place

JPMorgan Chase’s current Digital Services Agreement (marked “Last updated: October 2026”) states that, effective October 27, 2026, third parties “including External AI, automated tools, or data aggregators” are prohibited from using a customer’s login credentials. Chase says it permits third-party tools, including AI, to reach account data through approved APIs with the customer’s authorization.

The agreement then spells out what happens if a customer shares credentials anyway. The customer is deemed to have expressly authorized the third party to transact, agrees that Chase will treat the third party’s instructions as the customer’s own, and accepts responsibility for errors “including where the third party performs unintended actions, makes transactions you did not intend, or exceeds the authority you gave it.” The indemnity clause extends to the acts of “AI agents or agentic AI” to whom the customer gives access.

So the two banks differ in posture. Chase prohibits credential-based agent access and assigns the consequences when customers ignore the ban. Wells Fargo permits it at the customer’s risk and adds the revocation-evidence duty. Both qualify their liability language with phrases such as “to the fullest extent permitted by law” or “unless otherwise provided by law or regulation,” and that qualifier is where the legal fight, if there is one, will happen.

Where Regulation E fits, and where it doesn’t

For consumer accounts, the Electronic Fund Transfer Act and its implementing rule, Regulation E (12 CFR part 1005), cap a consumer’s liability for unauthorized electronic fund transfers. If the consumer reports a lost or stolen access device within two business days of learning of it, liability is limited to the lesser of $50 or the amount taken before notice. Later reporting raises the cap to $500, and failure to report within 60 days of a statement showing the transfer can expose the consumer to losses after that window. The rule is explicit that no agreement between a consumer and a bank may impose greater liability than those limits, and the statute separately voids contract terms that waive EFTA rights.

That sounds like it would neutralize the new clauses. It may not, because of how Regulation E defines “unauthorized.” Under section 1005.2(m), an unauthorized transfer is one initiated by someone other than the consumer “without actual authority” and from which the consumer receives no benefit. The definition excludes transfers by a person to whom the consumer furnished the access device, unless the consumer has notified the institution that transfers by that person are no longer authorized.

The official interpretation goes further. Comment 2(m)-2 says that if a consumer furnishes an access device and grants authority to a person “such as a family member or co-worker” who exceeds the authority given, the consumer is “fully liable” for the transfers until they notify the bank. The CFPB’s commentary on liability limits points back to that same comment as the exception to the rule that consumer negligence cannot increase liability.

The banks’ terms track that structure closely. Handing an agent your password looks a lot like furnishing an access device. An agent that overspends looks like a co-worker who exceeds authority. And the trigger for ending the consumer’s exposure in both the regulation and the contracts is notice to the bank.

Three questions remain open, and we found no court decision or CFPB rule that answers them for AI agents:

  1. Is software a “person” that was furnished an access device? The commentary’s examples are human. An agent run by a technology company sits somewhere between a tool the consumer uses directly, which would make its transfers the consumer’s own, and a third party acting on delegated authority.
  2. Does a hijacked agent still have “actual authority”? Regulation E treats transfers by someone who obtained the access device “through fraud or robbery” as unauthorized. If an attacker uses a prompt-injection attack to make a consumer’s agent send money to the attacker, a consumer could argue the transfer was initiated by the fraudster, not by an authorized person exceeding instructions. Wells Fargo’s terms pre-emptively describe “manipulated inputs” as the customer’s responsibility, subject to law.
  3. What counts as notice? Regulation E lets consumers notify an institution in person, by phone or in writing, and treats notice as given when the consumer takes reasonably necessary steps to inform it. A duty to retain and produce evidence of revocation is not the same thing as notice to the bank. Whether a bank could rely on the absence of a saved revocation record to resist a Regulation E claim is untested.

Two limits on Regulation E matter here as well. It covers consumer accounts only, so business customers are governed by their contracts and, for wire transfers, by UCC Article 4A, which Wells Fargo’s agreement explicitly invokes when it says that letting an agent in “may adversely impact the commercially reasonable security procedures” the customer agreed to. And Regulation E excludes wire transfers from its coverage altogether, even for consumers.

The evidence problem nobody has solved

The practical objection to the Wells Fargo clause came from the people American Banker interviewed. Douglas Borthwick, a former Morgan Stanley and Standard Chartered executive, said it was fair for the bank to want a record but not realistic to expect customers to produce one: “Telling a chatbot to stop leaves nothing in the customer’s hands that anyone else can check.” A screenshot, he added, “shows you asked. It doesn’t show the agent stopped, and screenshots are easy to fake.”

Elaine Duffus of Wolters Kluwer raised the harder case, in which a customer revokes access, keeps proof, and the agent misbehaves anyway. “Who’s at fault then? Is it me? Is it the bank? Is it the AI provider?” she asked. Her answer was an agent-governance layer that lets a bank see when things go wrong and “hit the kill switch,” something Wolters Kluwer says it is developing.

This is the part that should interest privacy and security teams outside banking. The bank’s position is that it cannot see when a consumer revokes an agent because revocation happens at the agent provider. That is true only because credential-based access makes the agent indistinguishable from the customer. Delegated access through a bank-issued token, with its own scope and its own revocation endpoint, would give both sides a shared record. That architecture is essentially what the CFPB’s open banking rule under Section 1033 of the Dodd-Frank Act was built around, and that rule is still being reconsidered and has not taken effect.

Why this is a privacy story as much as a payments story

Section 15(c) of the Wells Fargo terms is a consent clause. By using an agent, the customer “expressly consent[s]” to sharing financial, account and personal information with it and acknowledges that the agent and its provider may access, use, reuse, store or share that information outside the bank’s control. Chase’s agreement contains matching language. Financial institutions have long told customers that sharing passwords with aggregators puts their data outside the bank’s privacy protections, but writing it into the account agreement for AI agents specifically signals how banks expect regulators and courts to view the data flow: as a disclosure the consumer made, not one the bank made.

For the agent providers, that framing has consequences. A company whose AI assistant logs into bank accounts is collecting some of the most sensitive data a consumer has, with no bank-side contract governing retention, secondary use or security. Depending on how it is structured, that company may itself be a financial institution under the Gramm-Leach-Bliley Act’s broad definition, and it is squarely exposed to unfair or deceptive practices enforcement if its descriptions of what the agent does and stores are inaccurate.

What organizations deploying or building agents should take from this

The bank clauses are aimed at consumers, but the logic applies to any company that lets an AI agent act inside a third-party system with an employee’s or customer’s credentials. Some steps follow directly:

  • Inventory where agents hold credentials. List every agent or automation that logs into a financial, HR or vendor portal with a human’s username and password, and who owns each one.
  • Prefer scoped, revocable access. Where a provider offers API or token-based delegation, use it instead of shared passwords. It produces a revocation record on the provider’s side.
  • Log revocation as an event, not a chat. Record when an agent’s authority was withdrawn, by whom, and how that was communicated to the system it accessed. A deleted integration or a rotated password is stronger evidence than an instruction typed into the agent.
  • Read the account terms you already accepted. Corporate treasury and card agreements are being updated too. Check for deemed-authorization and indemnity language covering “automated tools” or “AI.”
  • Map the data the agent sees. Treat the agent provider as a recipient of account data in your records of processing and vendor reviews, with its retention and training terms on file.

Captain Compliance’s assessment, vendor review and AI governance workflows can help a team document which agents have access to which systems, the basis for that access and when it was withdrawn. They do not control a bank’s systems or decide how a bank or court will treat a disputed transfer, and no tool can guarantee that an agent will stay within its instructions. Our earlier coverage of how banks began restricting AI agents looks at the consent questions from the bank side, and our guide to agentic payments as a compliance problem covers card-network and merchant issues. For the open banking rulemaking, see our explainer on the CFPB Personal Financial Data Rights rule; for the data-sharing duties that sit underneath, our Gramm-Leach-Bliley Act compliance guide. Retailers facing the same question at checkout can start with the legal and privacy issues in agentic commerce, and teams designing audit trails for agents can use our piece on AI agent accountability records.

Frequently asked questions

When do the Wells Fargo terms take effect?

The updated Online Access Agreement is labeled “Version Effective November 24, 2026.” The agreement says continued use of the service after an effective date counts as acceptance of the change.

Does Regulation E still protect a Wells Fargo or Chase consumer whose agent goes rogue?

Regulation E’s liability caps still apply to unauthorized transfers from consumer accounts, and contracts cannot override them. The open question is whether a transfer by an agent the consumer gave credentials to is “unauthorized” at all. Under the existing rule, transfers by a person the consumer furnished an access device to are generally treated as authorized until the consumer notifies the bank, even if that person exceeds instructions.

Has the CFPB said anything about AI agents and Regulation E?

We found no CFPB rule, official interpretation or published guidance addressing AI agents specifically as of November 3, 2026. The bureau’s reconsideration of its Section 1033 open banking rule, which would shape how third parties access account data, has not been finalized.

Is a screenshot of telling the agent to stop enough evidence?

Wells Fargo has not said what evidence it will accept. A record from the agent provider showing the connection was removed, or a password change through the bank, is likely to be more persuasive than a screenshot of a chat. Regulation E separately recognizes notice to the bank by phone, in person or in writing, so customers who want to end an agent’s authority should tell the bank directly as well.

Do these terms apply to business accounts?

The agreements cover both personal and business online banking, but Regulation E protects consumer accounts only. Business losses from agent-initiated wires are governed by contract and UCC Article 4A, under which a payment order accepted in compliance with an agreed security procedure is generally effective as the customer’s order.

The password was never meant to be a power of attorney

Regulation E’s authorization rules were written for a world where handing someone your card meant handing it to a person you could later call and fire. Banks are now applying that model to software that can act thousands of times a day and can be steered by a stranger’s hidden instructions on a web page. The first consumer who loses money to a hijacked agent, keeps the screenshots, and files a Regulation E dispute will force the question the contracts are trying to settle in advance. Whichever way it comes out, the answer will matter well beyond banking.