On JPMorgan’s third quarter earnings call this week, Jamie Dimon said the bank will block outside AI agents from logging in to customer accounts (Fortune, Oct 15, 2026):

“We’re not going to allow just any outside agent to come inside the company, because that’s just too risky for clients and for JPMorgan. You don’t want rogue agents.” Jamie Dimon, JPMorgan Q3 2026 earnings call

Citi and Bank of America have since put similar restrictions in place (Yahoo Finance). My friend Simon Taylor covers the story from the innovation and enablement side in Fintech Brainfood, and he makes good points. I write this one from the bank side. Jamie Dimon is spot on here. In a big way.

My perspective, former banker: I ran online and payments at Wachovia and consumer channels globally at Citi. I founded and ran Commerce Signals, a payment data business. I have been on the bank side of aggregation since the day it started, and last year I broke the story on JPMorgan charging for data access (Open Banking is Dead in the US). This post connects those threads.

The Problem Is Permissions and Credentials, Not Data

Look at what JPMorgan blocked. It did not block data. Simon notes that read access through Plaid still works. A JPMorgan spokesperson told Fortune the bank stops agents that access accounts “by obtaining customers’ banking credentials,” and that JPM supports customer-authorized sharing through open banking providers (i.e., registered, approved and paying a fee).

The core issue is consumers handing their online banking username and password to a third party agent. This is the big problem, for consumers and for the banks managing those credentials.

When you hand a third party your banking credentials, it acts as you. The bank cannot tell the difference. A login opens every function online banking offers, not only the balance. What stops an agent from initiating a Zelle payment? From adding a payee? From updating your phone number so the one time passcode goes to a new device? Nothing. Once the phone number changes, whoever controls the agent controls the step up authentication meant to protect you. That is the textbook account takeover, except the consumer opened the door.

Zelle is the worst case because real time payments are irrevocable. As I wrote in my identity assessment this summer, there is no rule assigning liability for an unauthorized agent initiated transfer on instant rails. Simon reports that Dimon warned customers of a “liability transfer” when they hand an agent their logins. That is the right phrase. The liability moves to the consumer.

I Have Seen This Movie

Aggregation has been in banking since 1999. Wachovia was Yodlee’s first customer, and our customers loved it. We also lived with the consequences. As I wrote when the CFPB proposed its 1033 rule, scraping represented over 30% of our traffic and 20% of our call center complaints (Open Banking in US: Quick Take on the CFPB Proposed Rule). While I ran channels at Wachovia, we updated our consumer agreement: if you share your credentials, you are at risk for everything that happens. We had no other tool. We could not see who was logging in, why, or what they did with the data.

It has been a nightmare to manage ever since. Banks spent the last decade moving aggregators from screen scraping to tokenized APIs. Credential sharing agents threaten to undo that work in a quarter.

Banks Want Consumers to Use Their Data

Banks are not fighting consumer use of data. Every large bank lets you download your transactions, and every large bank supports permissioned sharing through APIs (some with a cost). There is no friction on that point. The friction is in two questions:

1. Who is responsible when problems happen? An agent pays the wrong biller, moves the wrong amount, or is hijacked. Who makes the consumer whole?
2. Who bears the cost of expanding the systems? Supporting agents and consumer permissions means new APIs, permission tracking, monitoring, and customer service. As I argued in 2023, these operating costs do not scale toward zero.

Banks have put both questions on the record. The ABA’s October 2025 letter to the CFPB asked the Bureau to designate screen scraping an unfair, deceptive, or abusive practice and to have liability follow the data downstream to aggregators and recipients, not only the bank (Rahul Jindal, Autonomous Research, “Open Banking: Trouble on the Playground,” Nov 2025).

Agents Multiply the Risk by 10x

Aggregators pulled data on a schedule. Agents act. They log in when asked, navigate any screen, and execute any function the consumer can. One consumer may run several agents across several banks, each holding the same password. Every agent is a new attack surface, and the credential store of a popular agent becomes a target. A Cloud Security Alliance note cited by Fortune describes three open source agents working together to breach at least 27 organizations and take more than 600,000 card records from two of them.

My estimate is that agents multiply the risk of aggregation by 10x. And the consumer has no way to tell the bank what the agent is allowed to do. The bank sees a login.

We Should Have Solved This With Akoya

Banks had the answer. Akoya was designed as a clearinghouse: tokenized, restricted access to data, with a common data sharing agreement(s) between the bank and every data requestor. When the banks bought Akoya from Fidelity in 2020, I called it a brilliant bank move (New Bank Consortium Created Around Akoya). In 2024 I gave it five stars (Akoya: Short Blog).

I was wrong about the execution. Akoya completely failed in its vision. It never became the clearinghouse of permissions and agreements the market needed, and banks went back to bespoke bilateral deals. IMHO most of the blame sits with TCH. The Clearing House does not do many new things well.

Morphing data economics did not help. Autonomous modeled Akoya at roughly $20 to $40 million in annual revenue per bank owner by 2030 and called it “paltry” (Jindal, Autonomous Research, Nov 2025). No one builds a permission utility for that. Had Akoya worked, agents would plug into a single tokenized interface today, under a standard agreement, with consumer permissions already tracked. Instead every bank is building its own.

Have, Use, Share

I was fortunate to have Russ Schrader, Visa’s former global Chief Privacy Officer, on my team at Commerce Signals. Russ would say that every user of consumer data needs three permissions from the consumer (Consumer Data Bureau?):

1. The right to have the data
2. The right to use the data
3. The right to share the data

Apply that to an agent holding your banking password. The agent has the data. No one defined how it may use it. No one defined with whom it may share it. None of that is in place. I made the same point when Plaid pitched itself as a data hub: permission and the value of data depend on use, and if you cannot define use, you cannot gain permission (Plaid Fights for Relevance).

What Banks Are Building

I talked with several banks this week. The need is clear:

1. The consumer permissions the agent and authorizes a specific use. Not “access my account.” Rather, “read my balance detail for budgeting.”
2. Banks create common APIs for each use (balance detail, for example) and track the consumer permission against each one.
3. Agents sign terms committing to abide by those restrictions. Bank of America, JPMorgan, and Wells Fargo have these controls in place today, but each is bespoke.
4. Banks obtain consumer permission for each agent action. Reading data and moving money are different permissions.

The ideal is a consumer signing each request with a device bound credential provisioned by the bank. The bank knows it is you, on your device, approving this action. AP2 points in that direction but is not there yet. I covered the problems in AP2 Operations: Near Term, Long Term: a mandate is only as trustworthy as the key that signs it, and the protocol needs operating rules that assign the risk when authentication breaks (Google Rolls Out AP2).

There will be fees for agents. There will be controls for consumers. JPMorgan set the pricing floor for data access last year at roughly $1.50 per authorization token and $0.05 to $0.20 per data request (APIs: More Banks to Follow JPM, Pricing Implications). An agent that acts on an account will pay more than an aggregator that reads it, because the bank stands behind the action (Retail, Roles and Know Your Agent).

The Near Term Fix: Muse Signs the JPM Agreement (modeled by Plaid). Plaid is restricted on end points.. they are not a clearing house, banks must know “who” is requesting, “how” the data will be used, and have a consumer authorization behind every action.

Meta launched Muse in September with finance features that connect accounts through Plaid (Meta’s Muse: The Agent Becomes the Control Point). Plaid signed a paid data access agreement with JPMorgan in September 2025 (Payments Dive, Sep 16, 2025), and JPMorgan later struck similar deals with Yodlee, Morningstar, and Akoya. The near term solution is for Muse to sign the same agreement. Same terms, same permission model, same accountability. JPMorgan gets a counterparty, the consumer gets controls, and the agent operates inside rules.

Meta told Fortune it is building “Poppy,” a personal agent protocol with Sierra, to signal when an agent acts for a customer. That helps identify the agent. It does not answer who pays when the agent is wrong. A protocol is not a contract.

Apple Is Best Positioned

In the near term, Apple is best positioned to help banks. Apple already holds bank provisioned credentials in the Secure Enclave, binds them to the device, and authenticates the consumer with Face ID. Banks trust that model today for Apple Pay (WWDC 2026: Apple Wallet). A consumer approving an agent action on an iPhone, signed with a bank issued key, solves the signing problem above.

Apple will not do it for free. Banks need to create the economic incentive. They did it once for Apple Pay. They can do it again.

What to Watch

• Undeclared agents. Most agents work through a browser today and do not identify themselves. Former CFPB regulator Dan Murphy argued at FinovateFall that limiting APIs will not stop agents; it pushes them back toward screen scraping (Timothy Chiodo, UBS, “FinovateFall 2026: Recapping Key Takeaways,” Sep 2026). Banks that block must also detect. Dimon said JPMorgan is building those tools.
• Who builds the permissiong platform? EWS? Visa? Apple?… See my blog on customer data bureau
• Who signs first. Whether Meta, OpenAI, or Google signs a bank agreement that covers agent actions, not only data.
• Bank agents. JPMorgan is piloting its own. Simon notes Smart Cash, which moves money between Chase accounts for yield.
• A common API. Whether banks standardize agent permissions, or each bank stays bespoke.
• Pricing. The first published fee schedule for agent access.

Simon’s warning deserves attention: “The risk for banks is you keep the account and lose the customer.” He is right that consumer agents are coming. But a bank that lets an unknown agent send Zelle payments with a borrowed password loses more than the customer.

Verdict

This is a red hot mess, and banks cannot just let it happen. Their regulatory and consumer exposure is too broad. They are right to block it. JPMorgan is best in class at protecting consumer data, and it is doing what a bank should do: say no until there is a counterparty, a contract, and a consumer permission for every action.

Agents will get access. They will get it on terms that define who is responsible, with fees for agents and controls for consumers. That is how it should work.