From Fragmentation to Fault Line: Corporate Banking's Missing API Standard in the Agentic Era

Retail banking got its API standard a decade ago. Corporate banking never did — and in 2026 that omission has stopped being a nuisance and become a fault line. ISO 20022 gave the industry a common grammar; it never gave it a common, agent-ready surface. Now the caller has changed. It is no longer a developer with a quarter to burn on integration, but a model discovering tools at runtime and moving money inside policy bands. The ambiguity that corporate treasurers have quietly absorbed for twenty years is about to be handed to software that cannot absorb it — while the data layer beneath is being forced structured whether banks like it or not. This is what the missing direction costs, why agents make today's fragmentation unsafe rather than merely inefficient, and what a corporate banking API standard has to mandate before autonomous treasury can scale.

Executive Summary

• Corporate banking has the grammar, not the surface. ISO 20022 standardised the data; nobody standardised the API. That was survivable while a human integrator absorbed the ambiguity — a model at runtime cannot.
• The caller changed. MCP made tool discovery a runtime decision. An agent that was meant to abolish the M×N integration problem meets it again at the bank boundary, where each institution is a bespoke server with its own semantics.
• Fragmentation now moves money wrongly, at machine speed. One timeout, three banks, three contradictory truths — a duplicate at A, a stuck instruction at B, a silent failure at C. Idempotency and a deterministic error grammar become load-bearing.
• Wrapping each bank in an MCP server relocates the swamp. Forty servers, forty semantics, no shared non-functional floor — and a non-deterministic model with write access to payment rails, squarely a SR 11-7 / DORA / EU AI Act problem.
• Standardise your own surface, or become the commodity. The banks that publish an ISO 20022-native, agent-ready API now become the default counterparties for autonomous treasury; the rest rent their client relationship to whoever owns the adapter.

Two banking worlds, one of them standardised #

Look at retail and the picture is messy but navigable. Europe has UK Open Banking and the Berlin Group's NextGenPSD2, the latter adopted by more than three-quarters of European banks and treated in practice as a de facto standard. The United States has the Financial Data Exchange, now spanning more than sixty million consumer accounts. Australia has the Consumer Data Right. None of these is global, and none is likely to become global — but each is a real, versioned, machine-testable contract, and where the contracts run out, the aggregators (Plaid, Tink, TrueLayer, Salt Edge) absorb the difference behind a single interface. Retail fragmentation is a tax. It is not a wall.

Corporate and wholesale banking has no equivalent. A multinational treasury reaches its banks through host-to-host file pipes, a dozen bespoke portals, a treasury-management system, or an aggregator — usually all four at once. This is not a straw man: McKinsey's own transaction-banking research has catalogued the same legacy for years, describing how banks lean on host-to-host and SFTP file transfer, listing the well-known failure modes of file-based integration — bulky ERP formats that must be customised per corporate, an inability to handle conditional routing — and reporting that upwards of 85% of transaction-banking executives intend to invest in cash-management APIs. The appetite for APIs is not in doubt. What is missing is the common contract they point at.

Because the usual candidates are not it. ISO 20022 is regularly mistaken for the missing standard, but it is a data grammar, not an API contract: pain.001 tells you how to phrase a credit transfer, not which endpoint creates one, how it authenticates, how it paginates, or how it tells you it failed. BIAN gives the industry a shared semantic reference model, not an enforced interface. Swift's Payment Initiation and Instant Cash Reporting APIs are a genuine move towards standardisation, but they are network-centric and still emerging, not a universal surface. The Berlin Group's openFinance framework is reaching towards corporate use cases — account opening, trade finance, dynamic recurring payments — but it is European, early, and premium-by-agreement. Assemble all of it and you still do not have a binding, global corporate banking API standard. You have building materials and no blueprint.

Why the fragmentation survived — and why that is ending #

For twenty years this was tolerable, because the integrator was human and patient. A corporate onboarded a handful of banking connections over months, sometimes quarters. Each was a project: certificates exchanged, a penny test run, a mapping document argued over. The cost was real but paid once per relationship and amortised across years of subsequent payments. When a bank's API was under-specified — when a standard "left the rest to the implementing institution", as banks themselves complain it does — a human engineer read the portal, inferred the intent, and papered over the gap. Ambiguity was survivable because a person was there to resolve it.

It also survived for reasons less often said aloud. The plumbing underneath is genuinely hard to change: batch-settlement windows, overnight cycles and mainframe cores that were never designed to answer a real-time question. And fragmentation is not only an accident — it is, quietly, a form of lock-in. Every bespoke host-to-host pipe a treasurer builds is a switching cost that accrues to the incumbent. A bank that is difficult to integrate is, at the margin, a bank that is difficult to leave. None of this is conspiratorial; it is ordinary incentive. But it explains why an industry that has agreed on a data grammar has never agreed on a surface — and why the surface is the last unstandardised layer left. The reason it can no longer hold is that the layer beneath it is being forced structured on a deadline, and the layer above it has just acquired a new, impatient user.

The caller has changed #

That user arrived in eighteen months. The Model Context Protocol, which Anthropic open-sourced in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025 alongside Block and OpenAI, has become the default way AI systems reach tools and data. By early 2026 it was posting roughly ninety-seven million SDK downloads a month; by mid-year, on one directional industry read, about seventy-eight per cent of enterprise AI teams were running MCP-backed agents in production and more than a quarter of the Fortune 500 were operating MCP servers, secured through a standard OAuth 2.1 authorisation layer. It is routinely, and accurately, described as USB-C for AI: it collapses the M×N integration nightmare — every model wired by hand to every tool — into M+N. Its own summary of itself is the line that matters for banks: APIs are for programs; MCP is for agents. A REST API expects the caller to know in advance which endpoint to hit and with what parameters. An agent expects to discover the available tools at runtime and decide, itself, how and when to use them.

This is not hypothetical for treasury. The pattern is already consistent across corporate-and-investment-bank treasuries in 2026: an agent reads ISO 20022 cash data, calls a bounded set of tools, and rebalances liquidity inside policy bands, with SR 11-7, DORA and EU AI Act controls wrapped around it. The data grammar is ready for that. The API surface is not.

The mismatch, precisely #

Strip the agent down to what it actually needs from a banking counterparty and the list is short and unforgiving:

1. A machine-discoverable contract — an OpenAPI description, or a tool manifest, the agent can read at runtime rather than a PDF a human reads once.
2. One authentication model — a financial-grade OAuth2/mTLS profile (FAPI is the obvious anchor), not a different handshake per bank.
3. Idempotency as a guarantee — a unique instruction reference that makes a retried payment a no-op, because an agent will retry.
4. A deterministic error grammar — the same failure meaning the same thing everywhere, so the model can reason about it.
5. Semantic versioning and capability discovery — so an agent can tell what a counterparty can do this quarter without a human release note.
6. Structured ISO 20022 payloads, consent and entitlements, and a tamper-evident audit trail — the substance, the permission, and the evidence.

Set that against corporate banking as it exists and every line fractures into N dialects — one per bank. The agent that was supposed to abolish the M×N problem meets it again at the bank boundary, because each institution is, in effect, a bespoke server with its own grammar for "balance", its own notion of "payment status", its own auth dance and its own idea of what an error is. The protocol standardised the agent's side of the wire. Nobody standardised the bank's.

A failure mode, made concrete #

Make it specific, because this is where the abstraction bites. Picture a liquidity agent authorised to sweep cash across three banks to hold each account inside a target band. It fires three near-identical instructions and, as networks do, hits a timeout on each.

Bank A treats the timeout as unknown — safe to retry, so the agent retries, and the original instruction settles too: a duplicate payment. Bank B treats the same timeout as submitted — do not retry, but never surfaces a confirmation the agent can parse, so the instruction sits in limbo while the agent, seeing no success, escalates or reroutes: a stuck payment and a double-booked position. Bank C returns a cheerful HTTP 200 with a rejection buried in the payload body; the agent reads the status code, marks the sweep done, and moves on: a silent failure that only surfaces the next morning as a reconciliation break nobody can explain.

Three banks, one condition, three contradictory truths — duplicate funds out the door at A, a frozen instruction at B, a phantom success at C. A human treasurer would have phoned three relationship managers and sorted it out by lunch. The agent cannot phone anyone. This is exactly why "idempotency as a guarantee" and "a deterministic error grammar" are not architectural niceties: without them, the same fragmentation that merely cost human hours now moves real money incorrectly, at machine speed, across every counterparty at once.

Why "wrap every bank in an MCP server" is not the fix #

The reflexive answer is to give each bank an MCP server and be done. It does not hold, because it relocates the fragmentation rather than removing it. Forty banks become forty servers with forty semantics, forty auth flows and no shared meaning — and, critically, no shared non-functional floor: no common latency budget, no agreed availability tier, no comparable idempotency guarantee. The failure mode above survives the wrapper intact. Worse, the caller is now a non-deterministic model with write access to payment rails, which is not merely an integration question but a model-risk and operational-resilience one that lands squarely on SR 11-7, DORA and the EU AI Act. MCP's human-in-the-loop primitives — elicitation for confirmation, sampling for reasoning — are necessary and welcome, but a confirmation dialog is not a substitute for a counterparty that behaves predictably. You cannot govern at scale what you cannot describe uniformly. A thousand bespoke servers is not a standard; it is the same swamp with a JSON-RPC veneer.

Two futures, and a strategic choice #

Who resolves this determines who owns the corporate relationship for the next decade, and there are only two candidates.

In the first, banks standardise their own surfaces. They publish agent-ready APIs, keep the direct connection to the treasurer, and remain the counterparty the agent discovers and calls. In the second, the aggregators standardise it for them. A handful of platforms define the de facto agent contract, and banks become interchangeable endpoints behind it — reachable only through someone else's abstraction. This is not speculation; it is the retail story running forward one segment. McKinsey's own 2025 transaction-banking work describes treasury-management platforms such as Kyriba and GTreasury, and office-of-the-CFO platforms such as Bill.com, positioning themselves between clients and banks with a single, bank-agnostic view of position. It is precisely the layer that, in retail, quietly disappeared the long tail behind Plaid and Tink. The same research notes that corporate treasurers now hold their banks to the standards of their consumer apps, and will switch when onboarding, entitlements and API integration disappoint.

The strategic content of the choice is blunt. A bank that becomes an endpoint behind an aggregator's agent contract surrenders three things at once. Margin, as its services are commoditised and compared price-first through someone else's interface. Client ownership, as the relationship, the context and the switching cost migrate to the platform. And data and analytics power, as the flow it once saw end-to-end is now mediated by an intermediary that sees more of the client than the bank does. Standardising your own surface is not a technical hygiene project. It is the difference between being the counterparty and being the commodity.

What the standard has to mandate #

The direction that is missing is not exotic. Every component exists in the open already — ISO 20022 for data, Swift's Payment Initiation and Instant Cash Reporting APIs for reference operations, BIAN for semantics, the Berlin Group's openFinance for the consent-and-catalogue pattern, FAPI for financial-grade auth, MCP for tool exposure, A2A for agent-to-agent orchestration. What is absent is the act of assembling them into a binding contract for the corporate space — and the discipline to specify two floors, not one. The existing B2B-API literature, McKinsey's included, treats APIs largely as a growth and experience opportunity. It says little about determinism, runtime capability discovery, or standardised non-functionals — exactly the omission agents cannot tolerate. So the standard must be explicit about both what the interface is and how it behaves under governance.

The technical floor #

• An OpenAPI-first contract with a canonical MCP tool manifest generated from it — not hand-written beside it, so the tools an agent sees can never drift from the API the bank runs.
• FAPI-grade authentication and consent as the single handshake across the surface.
• Idempotency and a deterministic error taxonomy — stable codes, one meaning per failure, documented in the contract itself.
• ISO 20022-native payloads, structured and hybrid-address ready.
• Semantic versioning with runtime capability discovery — an agent can ask what this counterparty can do today, and get a machine answer.

The governance and resilience floor #

• Published, enforced non-functional SLOs — latency, availability, throughput, straight-through-processing and human-effort — expressed as real time-and-motion numbers, not marketing language.
• Entitlements, consent and a tamper-evident audit trail bound to the execution path, not floating in an out-of-band portal.
• Model-risk and operational-resilience controls aligned to SR 11-7, DORA and the EU AI Act, so an agent's calls are governed events with an owner, not exotic edge cases.

There is a hard lesson buried in the retail experience here. A standard a machine executes has to be more precise than one a human integrator can quietly repair; under-specification is no longer a soft cost paid in developer hours but a hard failure mode paid in mis-sent payments. It is telling that the industry's most authoritative harmonisation effort — the CPMI and PMPG's harmonised ISO 20022 data requirements, which payment systems worldwide are being urged to adopt by end-2027 under the G20 cross-border payments programme, to fight exactly this fragmentation — is, by its own description, neither a regulation nor an API standard. It harmonises the data. The interface is still nobody's job.

A target picture #

The build is less daunting than the diagnosis, because it is three layers, not a programme. A canonical corporate banking API exposes payments and cash reporting over REST and OpenAPI, with ISO 20022-native payloads and FAPI-grade auth — one contract, one grammar, one handshake. An MCP bridge sits above it and generates the agent-facing tool manifest directly from that OpenAPI contract, so discovery, schemas and permissions are derived from the surface rather than maintained in parallel with it. And a policy and resilience layer wraps every agent call with the controls that make autonomy safe: transaction and counterparty limits, segmentation, human-in-the-loop triggers (elicitation on high-risk actions), live SLO monitoring and a hard kill-switch. No diagrams are required to grasp the point — the standard is not a new rail, it is a disciplined arrangement of rails that already exist, with the agent path and the governance path built in from the first commit rather than bolted on after the incident.

What credible banks do in the next 24 months #

If you accept that the caller has changed, the work is concrete and breaks into five tracks.

1. Publish an ISO 20022-native, OpenAPI-first surface. Take one high-value corridor — typically cross-border payments and cash reporting — and expose it through a single, versioned OpenAPI definition with ISO 20022 payloads, aligned to your existing CBPR+ schemas rather than a fifth invented grammar. Make it public to clients and internal agents, with a sandbox, and treat changes as product releases. Year-one success is not full coverage; it is proving one corridor can be made agent-addressable end-to-end.
2. Standardise authentication and idempotency across it. Adopt one FAPI-grade profile as the sole handshake, mandate idempotency keys on every write, and make "retry the same instruction" a documented guarantee in the contract — turning "agents will retry" from a risk into a safe assumption.
3. Define a deterministic error grammar and capability discovery. Give every failure a stable code and consistent semantics, add semantic versioning, and expose a capability catalogue an agent can query at runtime, with explicit flags for partial support, deprecation and "not yet available".
4. Attach entitlements, consent and audit to the same surface. Move consent and approval flows onto the API path, emit a tamper-evident trail for every agent-initiated instruction — who, what, when, under which policy band — and align it explicitly with SR 11-7, DORA and the EU AI Act so the second line can sign it off.
5. Publish non-functional floors, then run a supervised agent pilot. Commit to latency, availability, throughput and STP targets for the corridor and instrument them; then stand up a supervised liquidity or cash-sweeping agent that uses only this surface, with hard limits, human-in-the-loop checkpoints and full audit, for six to twelve months. This is the forcing function you control yourself — it proves an agent can move money safely inside policy bands when the surface is predictable, and it tells you quickly where your standard is still aspiration rather than fact.

The forcing function #

The industry has just proved it can move when something forces it. Swift's structured-address cut-over of November 2026 — after which unstructured addresses in cross-border payments are simply rejected, with no contingency conversion — has dragged a reluctant market towards structured ISO 20022 data on a fixed date, reinforced by the CPMI's end-2027 push for harmonised data requirements across the G20 payments programme. Notice what both efforts standardise: the data, not the interface. The grammar is being forced clean. The surface has been left to each bank's discretion — which is precisely the discretion agents cannot work with. For an agent, that means the payloads will finally be consistent while the behaviour behind them remains divergent — an inversion of what a machine actually needs, which is predictable behaviour first and clean data second.

So this is the unforced error to avoid: waiting for a global committee to bless a corporate banking API standard before acting. The banks that publish an ISO 20022-native, agent-ready surface now — an OpenAPI contract, an MCP manifest generated from it, financial-grade auth, and non-functional floors they will actually stand behind — will become the default counterparties for autonomous treasury. Their tools will be the ones the agents can discover, trust and call without a human in the middle. The banks that wait will be reachable only through an aggregator's abstraction, renting their own client relationship to whoever owns the adapter.

Grammar without direction is not a standard. ISO 20022 told corporate banking how to speak. It never told it where to go. The agents have arrived, fluent and impatient, and the map still is not there. Drawing it is now the most consequential piece of infrastructure work in transaction banking — and, for once, the deadline is being set not by a regulator but by the machines already waiting at the interface.

Frequently Asked Questions #

Isn't ISO 20022 the missing standard? No. ISO 20022 is a data grammar, not an API contract. pain.001 tells a system how to phrase a credit transfer; it does not say which endpoint creates one, how it authenticates, how it paginates, or how it reports failure. The grammar is ready for agents. The surface — the machine-discoverable, uniformly-behaving interface an agent actually calls — is not.

Why not just wrap every bank in an MCP server? Because it relocates the fragmentation instead of removing it. Forty banks become forty servers with forty semantics, forty auth flows and — critically — no shared non-functional floor: no common latency budget, no agreed availability tier, no comparable idempotency guarantee. The caller is now a non-deterministic model with write access to payment rails, which is a model-risk and operational-resilience problem under SR 11-7, DORA and the EU AI Act. A thousand bespoke servers is not a standard.

What is the single most useful first move for a bank? Publish one ISO 20022-native, OpenAPI-first corridor — typically cross-border payments and cash reporting — with a FAPI-grade handshake, idempotency as a documented guarantee, and a deterministic error grammar. Then run a supervised agent pilot against only that surface, with hard limits, human-in-the-loop checkpoints and full audit. Proving one corridor end-to-end beats a roadmap that covers everything and mandates nothing.

Who resolves this if banks don't? The aggregators. A handful of treasury and office-of-the-CFO platforms will define the de facto agent contract, and banks become interchangeable endpoints behind it — surrendering margin, client ownership and end-to-end data at once. It is the retail story, where Plaid and Tink absorbed the long tail, running forward one segment into corporate banking.

References #

• Model Context Protocol — official documentation ⧉. [MCP open-sourced November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025 alongside Block and OpenAI; the runtime tool-discovery layer the analysis builds on. Adoption figures in the text are directional industry reads and flagged as such.]
• Berlin Group — NextGenPSD2 and openFinance ⧉. [The de facto European retail API standard and its reach toward corporate use cases — cited for the consent-and-catalogue pattern and the retail-vs-corporate contrast.]
• Financial Data Exchange (FDX) ⧉. [The US retail data-sharing standard, cited for the scale of standardised retail contracts against which corporate banking has no equivalent.]
• McKinsey & Company — Financial Services insights ⧉. [Transaction-banking API research: host-to-host / SFTP legacy, the ~85% cash-management-API investment intent, and treasury-platform intermediation. Cited for the market diagnosis; the framing and conclusions here are the author's own.]
• Bank for International Settlements (CPMI) — Harmonised ISO 20022 data requirements ⧉. [The end-2027 push to harmonise payment data — by its own description neither a regulation nor an API standard — cited for the "grammar without a surface" point.]
• Swift — ISO 20022 for financial institutions ⧉. [CBPR+ and the November 2026 structured-address milestone; Payment Initiation and Instant Cash Reporting APIs cited as reference operations, not a universal surface.]

Last reviewed July 2026. Original analysis; sources are cited, not reproduced. Adoption and market figures are directional industry reads — verify against primary sources before republication. Licensed under CC-BY-4.0.

Last reviewed 2026-07-08.