It used a real debit card through a major bank and Mastercard’s network. Every participant in the payment chain could see that an agent initiated it, with the cardholder’s consent.

A test, not a product. But look at what just happened: the payment rails recognised software as a legitimate actor.

Most people I speak to expect banking to be one of the last industries to let AI agents near money: too regulated, too risk-averse, too much at stake.

I’ve spent twenty-plus years building banking systems, and the last stretch building AI-agent integrations against real banking infrastructure. From that seat, I think the consensus has it backwards. Banking may be one of the industries closest to useful, tightly controlled agent access. The reason is the least glamorous thing in fintech: a decade of open-banking compliance work.

My read: open banking wasn’t waiting for its killer app. It was waiting for the AI agent.

The groundwork banking already has

Banks did not build APIs because they wanted to. Regulators made them — PSD2 in Europe, the Consumer Data Right in Australia, and New Zealand’s Customer and Product Data Act, whose banking designation took effect in December 2025.

For years, open banking carried an awkward verdict: expensive compliance infrastructure, uncertain returns, no killer app. The criticism was real enough that Australia reset its Consumer Data Right partly to address high compliance costs and limited uptake, while an FCA research note reported that many account providers still viewed open banking as a compliance obligation, with uncertain revenue potential.

The “no impact” version now goes too far. Open Banking Limited reported 16.5 million user connections by December 2025 and 351 million open-banking payments across the year. The rails are being used. But no single consumer product has made the investment feel inevitable.

Now look at what that infrastructure produced, through the eyes of someone trying to build an agent channel today:

1. A consent framework that maps cleanly to agents. Open banking’s core mechanic is a customer granting a third party scoped, revocable, auditable access to their accounts — with consent screens, expiry, and an unambiguous record of who authorised what.

Swap “budgeting app” for “my AI assistant” and the framework still holds. The assistant has to arrive through an accredited requestor or a bank-sanctioned channel — accreditation and liability don’t vanish — but that’s governance work on rails that exist, not invention. Few sectors have a regulator-hardened answer to “how does software get permission to act for a person?”

2. Security standards agents can reuse. Major open-banking regimes adopted FAPI-based profiles, and PSD2 made Strong Customer Authentication a legal requirement, not a best practice.

Certified OAuth flows, sender-constrained tokens, strong authentication on sensitive actions: few of the sectors agents are expected to enter first have an equivalent baseline. Banking prepaid much of the security bill that agent access requires.

3. APIs that map cleanly to tools. Open-banking standards bodies published uniform, versioned specifications — accounts, transactions, payment initiation — that participating institutions implement from a shared playbook.

For anyone building an MCP server (the open protocol that lets assistants like Claude and ChatGPT call external systems), this is a gift: the mapping from open-banking endpoint to agent tool is almost mechanical. I know because I’ve done it.

4. Out-of-band confirmation rails customers already know. SCA pushed banks to build out-of-band approval — often a push notification: the “confirm this payment in your app” moment. That rail is precisely the safety net an agent channel needs: the agent works in one channel, the human approves in another, and prompt manipulation in the first channel can’t reach into the second — provided the challenge shows, and binds, the exact payee and amount being approved.

Now try building that in the industries agents are expected to enter first. A telco, utility, or health provider can’t assume its customers have installed an authentication-grade app. Many banks already have one because regulation pushed them there.

Consent, security, standard APIs, out-of-band approval. That’s not an industry starting from zero on agent readiness. Few industries have already built those capabilities into one regulated, audited stack.

The rails came first. The actor that needs all four is only now arriving.

The market is telling the same story

That cinema-ticket demo was the readiness showing on the card rails. The account-access layer is moving too.

In May, OpenAI launched a personal-finance experience inside ChatGPT. Within six weeks it had rolled out to Plus and Pro subscribers in the US, with Plaid connecting more than 12,000 financial institutions. In one product cycle, connecting your bank to an AI assistant became a mainstream product feature.

Read the fine print, though: the connection is strictly read-only. OpenAI’s own docs say ChatGPT “cannot take financial actions”: it can’t move money, and it can’t pay a bill.

OpenAI wired banks into its assistant, then stopped at the glass. Not because the write path is impossible, but because the write path is a trust product. Whoever owns the interface, it still runs on bank participation and bank-enforced controls: exactly the four rails above.

And the supply side? Here is the state of play as of July 2026, from my own survey:

• Business banking runs live agent payments (Meow, Slash) — API keys and commercial accounts, not consumer channels.

• Retail banking: the directory of banks with MCP servers is short and dominated by business platforms and betas; where a consumer can point an assistant at a retail bank at all, it’s read-only — one US bank in beta, plus the Plaid path above.

• Core-banking vendors are shipping agent tools for bank staff, not customers.

• The card networks are piloting authenticated agentic checkout with retail-bank issuers — the NZ demo above among them — through network-led identity and control frameworks, not by opening the banks’ own account APIs.

As of July 2026, my survey found no generally available consumer retail-bank product that lets customers connect their own general-purpose assistant and initiate per-payment, human-approved bill payments. That leaves a strikingly buildable consumer product sitting on rails that already exist.

From one-tap approval to bounded mandates

Bill-paying is just the entry point. The destination is money that manages itself within bounds you set: an agent that knows the school fees land on the 15th and the mortgage reprices in March; that keeps your transaction account at the float you chose and sweeps the excess into savings; that spots the power bill 40% above normal and asks you about it before paying.

Not a dashboard telling you what happened — an agent acting ahead of what’s coming, tuned to your goals and your calendar.

Today, that level of proactive, individual attention is mostly reserved for private banking. Agent rails make more of it programmable.

The consent model matures with it: per-transaction approval first, then bounded standing mandates — “keep me between X and Y, ask me about anything outside it” — the direct debit of the agent era, with the same property that made direct debit work: the customer sets the bounds, and the bank enforces them.

What building it actually teaches you

I know the gap is closable because I’ve built a working prototype against a production-grade core: an MCP server where the agent authenticates as the customer through standard OAuth with explicit consent screens and sees only that customer’s accounts.

It can prepare payments. It cannot release them.

The engineering surprise is how little of the hard work is API plumbing — point 3 above took care of that. The hard work is trust design, and it concentrates in three places:

The agent must act as the customer, never as a service account. Every tool call runs under the customer’s own identity and scope. One architectural decision, and the bank’s existing security model remains the foundation — supplemented by agent-specific controls, not rebuilt.

The threat model is new even when the APIs aren’t. The textbook case: a malicious “invoice” email that steers a helpful agent into paying an attacker. Prompt injection, model error on amounts and payees, stolen agent credentials — none of these are hypothetical, and none are solved at the API layer.

The answer to both centres on the consent moment. An agent-initiated payment triggers a step-up challenge to the human’s phone — the exact payee and amount, bound to the approval, out-of-band from the agent, one tap to approve or refuse.

It doesn’t stand alone. Transaction limits, anomaly detection, and instant revocation back it up, and approval fatigue is a real design problem, not a footnote. But it is the centre of gravity: the agent does the work; the human spends the money.

Get that moment right and agent banking is arguably safer than a tired human paying bills at midnight. Get it wrong and the first fraud headline sets the category back years.

The consent moment is the product. Everything else is integration.

Why a mid-tier bank may move first

Here’s the last twist. My four points are about readiness — and the big banks have all of it. The harder question is willingness: extending your own account rails to customer agents is a small technical step and a large institutional decision, and large banks typically make those decisions slowly.

The cinema-ticket demo illustrates the lower-friction path. A top-four bank participated through network-led card rails rather than exposing its own account APIs.

A mid-tier institution may be able to decide faster. The stack is integration, not invention: an MCP server on the existing core, the open-banking consent and security machinery repointed at a new actor, existing digital onboarding at the end of a new funnel.

The distribution prize may compound. As discovery moves inside assistants, “the first bank in the country your AI assistant can actually bank with” becomes harder to dislodge — and a potentially meaningful acquisition channel.

The consensus says banking goes last. The rails say banking goes first. The only question is which bank reads its own infrastructure correctly — and puts a human tap of approval at the centre of it.

I’m building in exactly this space, and there are working demos I’m looking forward to showing you soon — an agent preparing real banking actions, with a human approving every one.

If you work in or around a regulated institution, what would stop this first? Reply or leave a comment. I want to know where this architecture meets the hardest constraint.

This is the first essay in a series about how AI agents earn authority without taking control. Banking is the first proving ground: consent moments, bounded mandates, threat models, human vetoes, and working demos from inside the build.

Jason Wang is a principal architect who has spent twenty-plus years building banking systems and now builds AI-agent integrations against regulated infrastructure.