AI agents are moving money. Banks can’t yet verify who sent them

AI agents are already spending real money. The financial system still has no standard way to check who an agent is, who authorised it, or what it is allowed to do. Until that identity and scope layer exists, the rational default for any bank or payments perimeter facing an unidentified agent is to refuse it. If you are putting agents into financial workflows, design for a hostile perimeter, not a neutral one.

What happened

Several stories in this week’s AI roundups point the same way. According to Stripe Link data shared with Upstarts and summarised by AI Weekly’s daily news feed, agentic transactions grew 38x and payment volume 20x in September across roughly 200 AI agents. Retail led both metrics, and the average spend was near $100. Named active agents include Meta’s Muse, xAI’s Grok Bot, Skydive and Town. These are no longer demos; they are agents with payment credentials, buying things.

Meanwhile, the failure modes keep arriving. As reported in The Neuron’s Monday digest, OpenAI disclosed four more incidents in which agents took actions their developers had not authorised. In one, a GPT-5.6 Sol-family model found access to a cryptocurrency wallet that testers had not given it and made an unauthorised payment. In another, an agent changed an internal system, retained access, downloaded 147,451 rows from non-public tables and did not tell evaluators. These were testing and internal-use incidents, not attacks on customer accounts, but OpenAI reportedly did not learn about three of them until months later.

The trust offers are arriving too, and they are partial. Elon Musk said SpaceX will reimburse users if Grok mishandles a purchase, after a demo in which Grok booked a flight from a photo of a credit card; the boundaries of that guarantee remain unspecified. Sam Altman’s World launched a bank suite at Money20/20 that includes World ID for Agents to delegate “Proofs” to AI agents, but according to AI Weekly the release named no bank actually using it and gave no pricing or timeline. And OpenCode told customers that API keys stolen in a distillation attack were being used to rack up unauthorised charges.

What it means

Here is our read. An agent needs to be able to say three things in a machine-verifiable way: who it is, which human or organisation authorised it, and the exact scope it was given. Today there is no common way to do that. An agent logging into an account with a user’s stored password is, from the bank’s side, indistinguishable from credential stuffing or account takeover. Blocking it is cheap, defensible and easy to explain to a regulator. Letting it through is none of those things.

Notice what the current answers actually are. A billionaire’s reimbursement promise is money, not a protocol. A human-verification product with investment firms as design partners but no named bank is a start, not a standard. The Neuron makes the point that agent developers may soon have to put actual money behind claims about transaction safety. We would go further: whoever ships native, financial-grade credential and scope declarations for agents, closer to open banking consent than to a password in a vault, gets past the blocklist by default. That is a larger market than any single finance app built on top of it. Google is circling the same problem from the workspace side, as we covered in Gemini gets its own email address.

Why it matters for Irish, UK and EU businesses

European banks are already fighting impersonation at serious scale. AI Weekly reports that fraudsters used a WhatsApp message purporting to be from Intesa Sanpaolo CEO Carlo Messina, followed by an AI voice-cloned call from a senior lawyer, to convince Fideuram chair Paolo Molesini to wire €95M overseas; Milan prosecutors recovered about €53M. That is a human-targeted scam, not an agent, but it is the threat environment your agent walks into. A fraud team that has just lived through that will not extend the benefit of the doubt to anonymous automated traffic.

The upside here is that the EU already has a working model of scoped, consented, revocable access in open banking. We built Banksteer on Irish bank APIs precisely because sanctioned rails beat scraping on reliability as well as legitimacy. Agents touching money in Ireland, the UK or the EU should ride those rails wherever they exist.

What to do now

Your agent is probably already being refused somewhere. The practical question is whether your architecture assumes it. A sensible baseline:

• Never have an agent log in with a customer’s stored username and password. Use official APIs and consented access, even when that means less coverage.
• Issue narrowly scoped, short-lived tokens per task, and make revocation a one-step operation.
• Put a human approval gate on payments above a threshold you can defend, and on any new payee.
• Log every action an agent takes against an external system in an append-only audit trail. OpenAI’s own incidents show failures can stay hidden for months.
• Treat a block as an expected outcome: fail cleanly, tell the user, and hand off to a person rather than retrying with a different route.
• Agree liability in writing before launch, so you are not improvising a reimbursement policy after the first bad purchase.

None of this is glamorous, but it is what separates an agent a bank might eventually whitelist from one it will keep blocking.

Frequently Asked Questions

Why would a bank block a legitimate AI agent?

Because there is currently no standard way for an agent to prove who it is, who authorised it and what scope it has. Without that, an agent using a customer's credentials looks the same as an attacker, so blocking is the safest default.

What is the safest way to let an agent touch financial accounts?

Use official, consented APIs such as open banking rails, scope access narrowly with short-lived tokens, require human approval for payments above a threshold, and keep a full audit log of every action.