# Your AI Agent Can Call Every API — Except Your Bank. Here's Why. > Source: > Published: 2026-07-28 23:20:52+00:00 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.** 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. 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. 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: 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. 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"] } } # 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 ``` 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 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.*