For an industry built on numbers, banking has always struggled with something more basic: speaking the same language.
Ask any treasury team trying to connect to banks globally and you’ll hear a familiar frustration. The expectation is simple - money is digital, banks are global, so connectivity should be straightforward. In reality, it rarely is. What looks like a plumbing issue is something deeper: a system that was never designed to be unified in the first place.
Modern banking didn’t emerge as a coordinated network. It grew in fragments. National systems were built to serve domestic economies, shaped by local regulation, infrastructure, and political priorities. Payment schemes evolved independently. Messaging formats were defined in isolation. Even basic concepts like how to confirm a payment or report a balance took different forms depending on where you looked.
The result is not just variation, but incompatibility.
SWIFT is often held up as the closest thing to a global standard. And in one sense, it is. It created a common messaging layer that banks across the world could use. But it never standardised what happens after the message is sent. Two banks can receive the same SWIFT instruction and process it in entirely different ways - different cut-off times, different validations, different interpretations.
This is where the idea of “bank connectivity” begins to unravel. The challenge is not just reaching a bank, but dealing with how each bank behaves once you do.
Over the years, the industry has made repeated attempts to smooth this out. None have fully succeeded. Not because the technology wasn’t good enough, but because the incentives never aligned. Banks compete. Regulators don’t coordinate globally. And legacy systems - often decades old - continue to run critical infrastructure that no one is willing to replace lightly.
The expectation of a unified system persists. But it’s built on a false premise.
Banking isn’t fragmented because something went wrong. It’s fragmented because that’s how it was built.
The API promise, and its limits
Few ideas in banking have generated as much optimism in recent years as APIs.
They arrived with the promise of simplicity. Clean, modern interfaces. Real-time data. Standardised access. Compared to the heavy, file-based integrations of the past, APIs looked like a reset moment, a chance to finally make bank connectivity behave like the rest of the digital world.
And in some ways, they delivered.
Large banks began exposing endpoints for payments and reporting. Developers could interact with bank systems without navigating layers of legacy protocols. In controlled environments, things worked exactly as advertised.
But step outside those environments, and the picture changes.
APIs in banking are not a single standard. They are dozens, sometimes hundreds, of individual implementations. Each bank defines its own structure, its own authentication methods, its own limits. Even when two banks claim to follow the same framework, the differences show up quickly - in edge cases, in error handling, in performance under load.
The regulatory push behind open banking added momentum, but also confusion. PSD2 created a baseline, but it was never designed for corporate treasury. It focused on retail use cases, with limited scope for bulk payments, complex approval flows, or multi-entity structures. For large organisations, it solved a small part of a much bigger problem.
Meanwhile, neo-banks and aggregators entered the picture, offering simplified access and faster onboarding. They improved the experience at the edges, particularly for account opening and basic transactions. But they didn’t remove the need to engage with traditional banks. In many cases, they simply added another layer to manage.
The result is a familiar pattern in financial infrastructure. New technology doesn’t replace the old - it accumulates around it.
APIs didn’t eliminate fragmentation. They made it more dynamic.
Inside the hidden work of making banks “just work”
From the outside, bank connectivity looks deceptively simple. Payments go out, balances come in, and everything appears to move through a single system.
What’s less visible is the machinery underneath.
For companies operating across multiple countries, connectivity is not one connection, it’s dozens. Each bank brings its own requirements. File formats differ. Security models vary. Some require certificates, others tokens. One bank processes payments in batches, another in real time. Cut-off times shift by region, sometimes by product.
Even within the same bank, behaviour can change depending on the channel used. An API might support one set of payment types, while host-to-host supports another. Documentation doesn’t always reflect reality. Test environments behave differently from production. Exceptions are handled inconsistently.
None of this is unusual. It’s the normal state of the system.
This is why, despite all the talk of innovation, older methods remain firmly in place. Host-to-host connectivity - direct, file-based integration - continues to handle a large share of corporate payments. It’s not elegant, but it’s predictable. It does what it’s supposed to do, at scale, without surprises.
In certain markets, local standards dominate. EBICS, for example, is deeply embedded in parts of Europe. It works not because it’s globally relevant, but because it reflects the specific needs of those markets. In those contexts, it often outperforms more “modern” approaches simply by being consistent.
And then there’s SWIFT, still acting as the global fallback. When no direct connection is available, SWIFT is usually there. Not perfect, not always efficient, but broadly accepted.
Put all of this together, and a pattern emerges. There is no single best way to connect to banks. There is only a set of trade-offs.
The real work is not choosing one method, but managing all of them at once, and making them behave as if they were one.
That work increasingly sits in a layer most corporates never set out to build, but inevitably do: an orchestration layer that absorbs differences between banks, channels, and formats, and presents something coherent on top.
This is where platforms like Cobase operate.
Rather than trying to standardise banks themselves, Cobase standardises the interaction with them. It connects across SWIFT, EBICS, APIs, and host-to-host channels, translating between formats, normalising data, and embedding bank-specific behaviour into a central system. A payment instruction created once can be converted automatically into whatever each bank requires. Data coming back - balances, statuses, confirmations - is aligned into a consistent structure.
The complexity doesn’t disappear. It is relocated.
Instead of sitting in day-to-day treasury operations spread across teams, spreadsheets, and manual fixes, it is contained within a controlled layer designed to handle it.
Because in the end, the hardest part of bank connectivity is not building connections.
It’s making them invisible.
