FinOpineArguments about money, priced by the room
← United States
USPayments

A bank deciding which agents may act for you is a competition call, not a safety one

JPMorgan Chase says outside AI agents cannot reach into retail accounts. The security case is real — but a blanket perimeter with no published route through it settles who owns the customer relationship, not who is safe.

FinOpine deskOctober 15, 20264 min readmachine-drafted, human-checked
What this is about

New artificial-intelligence assistants can be told to do things for you, not just answer questions — including handling money. JPMorgan Chase, the largest bank in the United States, has said it will not let such assistants built by other companies reach into its retail customers' accounts. The announcement came weeks after the technology company Meta launched an assistant of its own.

Our view

Refusing outside AI agents access to accounts makes sense while nobody has decided who pays when an agent misfires. It stops making sense the moment the bank's own assistant is allowed to do what rivals cannot.

Ask who owns the front door

The customer thinks they own the front door of their bank account. The bank knows it does. Most of the time this never has to be settled, because the only things walking through the door are the customer and the bank’s own software. Agentic artificial intelligence — programs that do not just answer questions but take actions on your behalf — forces the question into the open, and the biggest bank in America has now answered it.

Weeks after Meta launched an assistant called Muse, Jamie Dimon said JPMorgan Chase will not allow outside agents to access accounts directly on behalf of retail customers. As a holding position in the first months of a new technology, that is defensible. As a settled arrangement it decides something a bank should not get to decide by itself: whether a customer may delegate, and to whom.

The word doing the work is “directly”

There are two very different things an agent might do. It might read — pull balances, transactions, fees, rates — so it can tell you that you are paying for three subscriptions you forgot about. Or it might write: move money, open an account, pay a bill, switch a provider. The risk profiles are not comparable. A read-only agent that is compromised leaks data. A write-enabled agent that is compromised empties an account.

A single word, “directly”, covers both. That matters because the two cases have different remedies. Read access is a permissions and scoping problem that banks already solve for payroll providers and accounting software. Write access is a liability problem, and liability is where this argument actually lives.

Nobody has said who pays

If an autonomous agent is tricked — by a malicious instruction hidden in a web page it reads, say — into sending money to an account the customer never chose, who bears the loss? The customer, who clicked a consent screen they could not meaningfully evaluate? The agent’s developer, which may be thinly capitalised or offshore? Or the bank, which has the deepest balance sheet, the regulator on its back and the complaint queue?

In the absence of a rule, the bank’s working assumption must be that it ends up paying. On that assumption a blanket block is rational. It is also an admission that the rule is missing. A bank refusing agent access because the loss allocation is undefined is making a case for someone to define it, not a case for the perimeter to be permanent.

The test that separates safety from strategy

Here is the test. Does the bank’s own assistant get to do things outside agents cannot? If in-house software can read a customer’s transaction history and act on a spoken instruction while third-party software is barred from the same account on security grounds, the security argument is doing work it cannot support. The attack surface of an agent does not shrink because the bank wrote it; prompt injection does not check the vendor.

That asymmetry, if it emerges, is a competition decision wearing a risk-management uniform. The commercial logic is not sinister, merely obvious: the agent that sits between the customer and the account becomes the customer’s interface. It decides which products surface, which fees get flagged, which switch gets suggested. A bank that lets someone else own that layer becomes a balance sheet with an application programming interface — plumbing, not a brand.

The strongest version of the other side

The case for the block is better than its critics allow. Consent is the weak point. A customer authorising an agent is not authorising a known set of actions; they are authorising an open-ended delegation to a system whose future behaviour nobody, including its developers, can fully specify. Ordinary consumer-protection reasoning assumes the person understood what they agreed to. Here they cannot.

Banks also carry the consequences. Fraud losses, regulatory attention and the furious phone call all land on the institution holding the money, regardless of whose software caused the problem. And agents are new enough that there is no track record to price. Moving slowly with other people’s deposits is not cowardice.

All true — and none of it argues for a wall with no door. It argues for a door with conditions. The alternative is worse security, not better: if customers want agents badly enough, they will hand over their banking passwords and let software log in as them. Credential sharing is the least safe arrangement available, it cannot be revoked selectively, and it is exactly what a blocked interface produces. Australia’s experience of retail investors leaning on AI for financial guidance — the Australian Securities Exchange now counts a record 11.5 million adults holding investments outside super and the family home, with AI advice among the emerging trends — suggests demand does not wait for permission.

What a door would look like

It is not complicated. Scoped access, so an agent gets read-only unless it is separately admitted for payments. Strong authentication that identifies the agent, not just the human. Per-transaction limits and instant revocation. An accreditation bar any provider can clear, published in advance, applied to the bank’s own assistant on identical terms. And a written answer to the liability question, so that the party best placed to prevent a loss is the party that wears it.

Until that document exists, the honest description of the current position is not “we are protecting customers”. It is “we have not decided what we are willing to be responsible for”.

JPMorgan Chase should publish the conditions under which an outside agent could be admitted — authentication, scopes, limits, revocation — and commit to applying them to its own assistant on identical terms. If it will not, US banking and consumer regulators should set the loss-allocation rule for agent-initiated payments themselves, because that rule is the thing standing between a cautious bank and a closed one.

What would change this view

I am wrong if JPMorgan publishes, within a year, a technical and liability standard that any accredited outside agent can meet to obtain the same account access its own in-house assistant has — scopes, authentication, revocation, and a stated allocation of loss for agent-initiated transactions — and admits at least one unaffiliated provider under it.

If that document appears, the current block was a staging decision and the critique collapses to impatience. If a year passes with the perimeter intact, no standard published, and the bank's own assistant acting on accounts, the commercial reading is the correct one and a US regulator should set the terms instead.

Worked from

  1. JPMorgan Chase blocks outside AI agents from directly accessing customer accounts
    Finextra · 2026-10-15
United States. Opinion and commentary of general circulation. Not investment advice and not personalised to any reader.