Why Banks and Marketplaces Are Blocking Outside AI Agents, and the Sanctioned Routes Left Open
If you run a bank, a marketplace or a platform with customer money behind it, an outside AI agent has probably already knocked on your door. It arrives carrying a customer's login and a polite instruction: do what they would do. The early signs are that incumbents are saying no. JPMorgan Chase has reportedly blocked outside AI agents from direct access to customer accounts while backing open-banking routes instead, and Amazon has been reported to be shutting out Meta's Muse shopping agent. The interesting question is no longer whether agents will touch money. It is which routes in are sanctioned, who carries the liability on each, and which one you should build on before your customers decide for you.
The block is a liability decision, not a technology decision
Start with what was reported, because the evidence here is narrower than the headlines suggest. Finextra, citing CNBC, reported in mid-October that JPMorgan Chase blocks outside AI agents from accessing customer accounts directly and backs open-banking routes. Amazon's move against Meta's Muse agent, reported on 7 October, is the marketplace version of the same pattern. Two named cases do not make a market. But they point the same way, and they sit inside a theme that has now dominated agentic-commerce coverage for three consecutive reporting cycles: not "can an agent pay?" but "who authorised it, and who is liable when it goes wrong?"
That framing matters, because it explains why a block is the rational first response. An agent that logs in with a customer's own credentials is, to the bank's systems, indistinguishable from the customer. The bank cannot tell whether the customer meant the transaction, whether the agent misread an instruction or whether someone else is behind it. If something goes wrong, the dispute lands on the bank's desk, and the bank has no contract, no audit trail and no control over the software involved.
The consumer assistants driving this are also scaling quickly. Sensor Tower, as reported by PYMNTS, put Meta's Muse at more than 10 million downloads in the United States and Canada within 35 days. Treat that with care: downloads are not active use, and the data covers North America only. Even so, a distribution channel of that size explains why incumbents are not waiting to see how this plays out.
Our reading, which is interpretation rather than reported fact, is that the blocks are less a rejection of agents than an insistence on a different kind of access: routes where consent is explicit, scope is limited and responsibility is written down.
Three routes an agent can take to a customer's money
For product leaders, the useful move is to stop talking about "agent access" as one thing. In practice there are three routes, and they distribute consent, control and liability very differently.
Route one: credential sharing
This is the route being closed. The customer hands the agent their username and password, or lets the assistant operate a logged-in session, and the agent acts as the customer. It is fast to launch, which is why it appears first, and it has the weakest answers to the questions a regulator or risk committee will ask.
Consent is implicit, because the bank sees a login and not a decision. Scope is unlimited, because the agent can do anything the customer can do. Evidence is poor, because there is no record of what the customer actually asked the agent to do. And liability is muddled, because bank terms typically require customers to keep credentials private. A customer who shares them with an assistant is, on a plain reading, in breach of that obligation before anything has gone wrong.
Route two: open banking and consented data
Open banking is the alternative the incumbent reports point towards, and in the UK it is the most mature. Access runs through regulated third parties using standardised interfaces. The customer gives specific, revocable consent for specific data or a specific payment. The bank can see who is asking and why. The third party sits inside the FCA's regulatory perimeter, which gives the bank, the customer and the regulator someone to hold to account.
For agents, two features matter most. The first is consented data: an agent can read a customer's transactions or balances with permission that is scoped and visible rather than borrowed. The second is payment initiation, including variable recurring payments, where a customer authorises an agent or a service to make payments within agreed limits rather than approving each one individually. That structure looks very much like what an agent needs: standing authority with a ceiling, rather than open-ended access.
Route three: scheme-token access
The third route runs through the card networks. Visa, Mastercard and American Express have each put out an agent-oriented offering in recent weeks. Visa, BILL and Billtrust are running a live pilot of AI agents paying business-to-business invoices through Visa Intelligent Commerce, which Visa has called a first; that is Visa's own claim and we have not seen it verified elsewhere. Mastercard has opened early access to Agent Pay for Machines, with buyer-side and seller-side APIs and a sandbox. American Express has published an "Intent Intelligence" framework linking authenticated purchase intent to agent transactions.
The common idea is that the agent never holds the customer's card number or login. It holds a token, issued under a network's rules, that is bound to a mandate. Liability follows the scheme's rules, which merchants and issuers already understand. The trade-off is dependence: each network is sponsoring its own approach, and the reported picture is of standards multiplying without convergence. Choosing a scheme route today means choosing a side in a race that has not finished.
What UK open banking gives an agent today
Because the UK has an established open-banking ecosystem, it is worth being specific about what it offers an agent and what it does not.
One open-banking provider repositioned itself on 13 October around "programmable payments and financial insights", built on commercial variable recurring payments and consented data, and named AI agents as a principal reason for the change. It cited UK open banking usage above 16 million users and monthly payments above 40 million in May 2026. Those are the provider's own figures in its own marketing, and we have not checked them against Open Banking Limited's published data, so treat them as indicative of direction rather than as an authoritative market size. What is more telling than the numbers is that infrastructure providers are now rewriting their propositions for agents. Open banking is being treated as the sanctioned lane.
Here is what the ecosystem gives you, in plain terms.
- Scoped, visible consent. The customer approves a defined purpose and can see and withdraw it, which is exactly the property credential sharing lacks.
- A regulated counterparty. Third parties that access accounts or initiate payments operate within the FCA's perimeter, so there is a named, supervised firm in the chain.
- A payment rail with limits built in. Variable recurring payments let a customer set the parameters inside which a service or agent may pay, such as a maximum amount or a time window.
And here is what it does not give you.
- A way to identify the agent. Open banking tells the bank which regulated third party is calling. It does not tell the bank which software agent is acting, who built it or whether it behaved as instructed.
- Consumer-grade conversion by default. Redirect-based consent journeys introduce friction. An agent that must repeatedly send a customer to approve things is not much of an agent.
- A settled answer on disputes. Rules for who bears the loss when an agent misunderstands an instruction are still being worked out in practice.
The gaps the sanctioned routes still leave
The case for open banking is that it is the best available lane, not a finished one. Three gaps stand out.
Agent identity is unresolved
A vendor ecosystem is forming around agent identity and delegated authority. In a single week in October, reports covered an agent-authorisation module from Sumsub, Proof's x401, World ID, Evervault and a Skyfire and Forter partnership. No single standard has emerged, and x401, know-your-agent modules and scheme tokens coexist. Search interest in "know your agent" is still tiny, at roughly 40 to 50 UK searches a month. Any identity layer you choose today may need to be swapped.
Regulators are applying old rules to new behaviour
On 19 October the FCA published what it considers good and poor practice in AI and said AI providers should add disclaimers to AI financial advice. It also acknowledged agentic finance. As reported, the regulator is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than writing new rules for agents. That is helpful and demanding in equal measure. It means there is no agent-specific safe harbour to hide behind, and a firm that lets an agent act on a customer's behalf will be judged against outcomes it is already responsible for. This is general context, not legal advice, and firms should take their own advice on how it applies to them.
Customers trust agents to research before they trust them to pay
Consumer surveys reported in October found that willingness to use AI to research outpaces willingness to let it complete the purchase. That is consistent with the liability debate: people are comfortable letting an agent look, and cautious about letting it act. For product leaders it is a sequencing hint. Read-only, consented-data experiences are likely to find acceptance before delegated payments do.
How to choose a route: five questions for platform and retail-bank leaders
The decision most teams face is whether to build on open banking now or wait for scheme tokens to settle. Waiting is a legitimate choice, but it should be a decision rather than a drift. These five questions are our own framework, not an industry standard.
- Who is the customer's counterparty when the agent acts? If the answer is "the customer, via borrowed credentials", you have chosen route one. Decide whether you are choosing that on purpose.
- What is the maximum an agent should be able to do without a human approving? Define the ceiling in pounds, time and counterparties. Variable recurring payments and token mandates both express ceilings; credential sharing cannot.
- Where does the audit trail live? For every agent-initiated action, you should be able to show who authorised it, when, under what scope and with what result. If your design cannot produce that, a complaint will be painful.
- What happens when the identity layer changes? Given that agent identity standards are multiplying, keep the identity component behind a clear interface so that you can replace it without rebuilding the payment flow.
- Who bears the loss on a misunderstood instruction? Settle this in your terms and your partner agreements before launch, not in your first dispute.
A pragmatic pattern follows. Use open banking and consented data for the read-only and capped-payment experiences where it is strong now, keep your agent-facing layer thin enough to add a scheme-token route when one of the networks' approaches proves itself, and do not build on credential sharing. If you are shaping a roadmap in agentic commerce and payments, the sequencing matters more than the technology choice.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and agentic commerce and payments is one of our specialist areas. The questions above are the ones we work through with clients: which access route is appropriate, how the mandate and ceiling are modelled, and where the audit trail sits. We design compliance in from day one, because an agent that cannot show its authority is a liability, not a feature. We build for regulated clients rather than being one, so the regulatory conclusions remain the client's to draw with their own advisers.
As an implementation partner across multiple fintech platforms, we help brands find a fast, compliant route to launching financial products, and that includes products where an agent is one of the users. If you are weighing open banking against a scheme-token route, our Agentic Commerce & Payments work is the place to start. If you would rather test an approach before committing, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding.
FAQ
Can an AI agent access my bank account?
An AI agent can access a bank account only through routes the bank permits, and the direction of travel is towards sanctioned access rather than shared logins. JPMorgan Chase has reportedly blocked outside agents from direct account access and backed open-banking routes. In the UK, the sanctioned route is open banking, where a regulated third party acts with the customer's specific, revocable consent.
What is the sanctioned route for AI agent payments?
There is no single route yet, but open banking is the most established. A customer consents to a regulated third party initiating payments, sometimes within limits set through variable recurring payments. The card networks are building a second route through tokens and mandates, including Visa Intelligent Commerce and Mastercard Agent Pay, though those are early and each network is pursuing its own approach.
Why are banks and marketplaces blocking outside AI agents?
The most likely reason is liability. An agent using a customer's credentials looks identical to the customer, so the bank cannot verify who authorised an action or prove what was intended. Blocking pushes access towards routes with explicit consent, limited scope and a named, accountable party. That is our interpretation of the reported blocks, not a statement from the firms involved.
Is open banking safer for agent payments than sharing credentials?
Open banking is structurally better on consent, scope and accountability, but it is not risk-free. The customer's permission is specific and visible, and a regulated third party sits in the chain. It does not, however, identify the individual software agent or settle who bears the loss if an agent misreads an instruction, so those controls still need to be designed.
Should we build on open banking or wait for scheme tokens?
Build the parts that are strong now, and keep the rest replaceable. Open banking and consented data suit read-only experiences and capped payments today, while scheme-token approaches are still arriving and standards have not converged. A thin, well-defined agent layer lets you add a token route later without rebuilding. Avoid building a product on credential sharing in either case.
Conclusion
The blocks reported at JPMorgan and Amazon are best read as a demand for sanctioned access, not a refusal of agents. Credential sharing is the route being closed. Open banking and consented data are the most mature alternative in the UK, scheme tokens are the one to watch, and neither yet answers agent identity or loss allocation completely. The teams that will do well are the ones that decide who authorises, who is liable and where the audit trail lives before they choose a technology, and who build so that one component can change without the rest being rebuilt.
