DEV Community

John Frandsen
John Frandsen

Posted on

Your AI Agent Can Call Every API — Except Your Bank. Here's Why.

#mcpaiapisopensource

Every API you'd want an agent to call has a clean path: an API key, an OAuth dance, maybe a scoped token. Your LLM can read your calendar, file your issues, query your database. Then it hits your bank — and the door slams.

It's not that bank APIs don't exist. PSD2 forced EU banks to publish them. It's that the authentication layer is built for institutions, not agents. Getting onto a bank's API as a third party requires an eIDAS QWAC + eSEAL certificate — a Qualified Website Authentication Certificate and a Qualified Electronic Seal, issued by a QTSP after a weeks-long onboarding that runs €2,000–€10,000 per year.

No agent framework ships a tool that can produce a Qualified Seal. No indie dev spinning up an MCP server on a Friday night is going to file for one. So the agent wave, which is consuming every other API surface, bounces off banking entirely.

The aggregator vacuum, explained

This is the actual reason the open-banking landscape is dominated by aggregators — Yapily, TrueLayer, Tink, Plaid. It's not that they have better technology. It's that they're the only entities willing and able to absorb the certificate tax.

They buy the eIDAS certs. They handle the regulatory registration as Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). They maintain the per-bank connector sprawl (every bank implements the Berlin Group NextGenPSD2 standard slightly differently). Then they sell you a single REST key on top.

It's a perfectly rational business. But it has a side effect: it makes bank data the only major API category where you cannot talk directly to the source without a six-figure compliance posture. For agents, that's a problem.

Why MCP makes this acute

Model Context Protocol (MCP) servers are how tools get into agent runtimes this year. The pattern is clean — a server exposes a handful of tools, an agent discovers and calls them. For most domains this is trivial: wrap a REST API, return JSON, done.

For banking it breaks at the first step, because the wrapper needs a client certificate to even complete the TLS handshake with the bank. That's not a config value you paste in — it's a credential bound to a legal entity that has passed regulatory vetting. An MCP server you'd publish to a registry can't carry one. So today, the realistic "bank MCP server" is one that talks to an aggregator, not to banks.

I think that's the wrong default. The interesting design question for agent-native banking is whether we can get read access to one's own account data without forcing the agent stack through an intermediary. That requires a tier of access that doesn't exist in the PSD2 rulebook as written, but which several adjacent trends are pulling toward.

What a certificate-free read tier would unlock

PSD2 already distinguishes AIS (read) from PIS (write). The certificate burden exists for both, but the risk profiles are wildly different: a consented, read-only view of your own balances and transactions is not the same as initiating a payment. Yet both sit behind the same eIDAS wall.

A practical, agent-friendly pattern is starting to emerge at the edges:

  1. Sandbox-first, cert-free. Several bank developer portals and aggregator sandboxes expose test data with only an API key. An MCP server can ship against these today, giving agents real-shaped data to develop against without any compliance posture. This is where most agent/banking experimentation will live for the next year.
  2. AISP-lite / hosted-agent consent. Instead of every agent operator registering as an AISP, an entity holds the AISP license and grants scoped, consent-bound read tokens to agent processes — not to end companies. The agent runs against your consented accounts; it never holds the certificate. This is structurally what aggregators do, but with the boundary drawn so that the agent is the consumer, not the company.
  3. Certificate-free production read tiers. The genuinely useful (and genuinely hard) version: a bank-data API that gives consented read access with API-key auth, with the certificate burden absorbed by the API provider rather than pushed onto every integrator. This is what I've been building toward with open-banking.io — a certificate-free read tier so that the smallest integrator, or a single MCP server, can reach bank data without the eIDAS tax.

The third option is the one that matters for agents. If accessing your own transaction history requires you to first become a regulated financial institution, agent-native personal finance is a non-starter.

A sketch of what the agent side looks like

To make this concrete, here's the shape of an MCP tool that reads account data through a certificate-free tier — no client cert, no eIDAS, just a key and user consent:

// An MCP "list_transactions" tool definition
{
  "name": "list_transactions",
  "description": "List recent transactions for a consented bank account.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_id": { "type": "string" },
      "since": { "type": "string", "format": "date" },
      "limit": { "type": "integer", "default": 50 }
    },
    "required": ["account_id"]
  }
}
Enter fullscreen mode Exit fullscreen mode 
# The server-side handler — note: no mTLS, no client certificate
async def list_transactions(account_id: str, since: str, limit: int = 50):
    resp = await client.get(
        f"https://api.example-bankdata.io/v1/accounts/{account_id}/transactions",
        params={"since": since, "limit": limit},
        headers={"X-API-Key": os.environ["OBI_KEY"]},
    )
    resp.raise_for_status()
    return normalize_for_agent(resp.json())  # flatten to agent-friendly JSON
Enter fullscreen mode Exit fullscreen mode

The hard part isn't this code — it's trivial. The hard part is everything upstream: the consent flow, the bank connectors, the regulatory absorption that lets the integrator skip eIDAS entirely. That's the layer worth building if you want agents to actually reach banking data.

The takeaway

The reason your agent can read your GitHub but not your bank statement isn't a missing integration. It's a regulatory design choice — the certificate tax — that funnels all third-party bank access through a handful of intermediaries. As the MCP ecosystem keeps eating every other API surface, banking is going to be the conspicuous holdout unless we build read tiers that don't require every integrator to become a regulated institution.

Certificate-free, consent-bound, read-first access is the unlock. If you're building agent tooling and you've bounced off banking, that's the gap worth closing.

I maintain open-banking.io, a certificate-free open banking API. The views on PSD2/eIDAS here are my own; the agent-native banking question is one I think about daily.

Top comments (0)