This article is written by our partner, Cobase

ISO 20022 was supposed to unify banking. It probably won’t.

Few projects in modern banking have carried as much expectation as ISO 20022.

For years, it has been described as the future language of global finance, a common standard that would finally allow banks, payment systems, corporates, and financial institutions to communicate in a structured, consistent way. Richer data. Better interoperability. Fewer errors. Faster processing.

After decades of fragmented formats and incompatible messaging systems, ISO 20022 arrived with something close to utopian ambitions: the idea that banking might finally start speaking the same language.

And in one important sense, it is already changing the industry.

The migration is enormous in scale. SWIFT cross-border payments, domestic RTGS systems, clearing infrastructures, and banks across major markets are moving from older MT messaging formats toward ISO 20022 XML-based messages.

The technical benefits are real.

Legacy payment messages were notoriously constrained. Fields were short, often unstructured, and inconsistently interpreted. Critical information – addresses, remittance details, compliance data was frequently truncated as payments moved across systems. ISO 20022 introduces far richer and more structured data models, improving straight-through processing, compliance screening, and automation.

In theory, this should reduce fragmentation.

In practice, the picture is more complicated.

Because ISO 20022 does not standardise banking behaviour. It standardises messaging.

That distinction matters.

Two banks can both be fully ISO 20022 compliant and still process the same payment differently. One may require additional fields. Another may reject optional data that a third bank accepts. One market infrastructure may implement a specific version of a message type, while another introduces local usage guidelines layered on top of the global standard.

The industry has already developed multiple “flavours” of ISO 20022:

• CBPR+ for SWIFT cross-border payments
• SEPA usage guidelines in Europe
• domestic variants for markets like the UK, Switzerland, and the US
• bank-specific implementation rules on top of all of them

So while the syntax becomes more aligned, the operational reality remains fragmented.

In many ways, ISO 20022 is repeating a familiar pattern in banking: harmonisation at the framework level, divergence at the implementation level.

SEPA followed a similar trajectory. It standardised payment schemes across Europe, but banks still implemented formats differently. Corporates discovered that “ISO compliant” did not necessarily mean “interchangeable.”

The same dynamic is emerging again.

And then there is the migration itself.

One of the lesser-discussed realities of ISO 20022 is that it does not replace the old world overnight. For years, legacy MT formats and ISO 20022 messages have coexisted across the global payment ecosystem. Translation layers became necessary. Data moved between old and new standards, sometimes losing structure along the way.

Even after formal migration deadlines pass, coexistence does not truly disappear. Banks continue running legacy infrastructure internally. Corporate ERP systems remain unevenly upgraded. Some channels fully support enriched ISO data, while others still rely on reduced mappings for compatibility.

The result is not a clean reset, but another layer added onto an already layered system.

This is particularly visible for corporates.

For treasury teams, ISO 20022 is often presented as a simplification initiative. In reality, it frequently increases short-term complexity. Payment files need updating. ERP integrations require modification. Validation rules become stricter. Banks introduce their own migration timelines and interpretation guides. A format that works with one bank may still require adjustments for another.

What changes is not the disappearance of complexity, but its shape.

This is where orchestration becomes increasingly important.

Platforms like Cobase sit between corporates and the banking ecosystem, absorbing many of these differences. Instead of treasury teams managing each bank’s ISO implementation directly, the orchestration layer handles format conversion, message enrichment, validation, and routing centrally.

A single payment instruction may need to be transformed differently depending on whether it is sent via SWIFT CBPR+, SEPA, EBICS, or a proprietary bank API. Structured address requirements may differ by market. Optional ISO fields in one implementation may become mandatory in another.

From the corporate perspective, the goal is not to master every variation of ISO 20022.

It is to operate through a layer where those variations are managed automatically.

That is ultimately the paradox of ISO 20022.

It absolutely improves the global financial system. The richer data, standardised structures, and interoperability gains are significant. It reduces friction. It improves automation. It creates a more modern foundation for payments infrastructure.

But it does not eliminate the deeper forces that created fragmentation in the first place:

national regulation, local market practices, bank-specific implementations, legacy infrastructure, and competing commercial incentives.

ISO 20022 may unify the language of banking. It will not fully unify the system speaking it.

Also Read

• Bank Connectivity: Global expansion meets local banking reality
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Bank Connectivity: The myth of the global bank

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.

This article is written by our partner, Cobase

For companies expanding internationally, the operational challenge is rarely the expansion itself. Hiring entities can be established. Suppliers can be onboarded. Customers can be reached.

What becomes unexpectedly difficult is something more foundational: moving money locally.

From the outside, modern banking appears global. In practice, payments remain deeply domestic. Every country has its own infrastructure, conventions, and assumptions about how money should move. The further a company expands, the more it discovers that “international banking” is often just a thin layer sitting on top of highly local systems.

The differences begin with the payment rails themselves.

In Europe, SEPA created the impression of a unified market. Payments move quickly, account structures are standardised around IBANs, and cross-border euro payments are treated much like domestic ones. But step outside that environment and the assumptions start to break down.

In the United States, for example, there is no IBAN system. Payments move through ACH, wire networks, RTP, FedNow, card rails each with different rules, speeds, costs, and use cases. Routing depends on account numbers and ABA codes rather than internationally standardised identifiers. A European treasury team entering the US often discovers that concepts they assumed were universal simply are not.

Elsewhere, the fragmentation becomes even more pronounced.

In India, payments increasingly move through UPI and domestic instant payment infrastructure that evolved around local consumer and business behaviour. In Brazil, Pix transformed the speed and accessibility of payments almost overnight, but operates within a domestic ecosystem that foreign companies must adapt to. China relies on an entirely different architecture again, shaped by local regulation and platform dominance.

What emerges is not a global payment system, but a collection of national ecosystems connected imperfectly to one another.

For multinational companies, this creates an uncomfortable reality: global expansion often requires becoming locally native in financial operations.

That affects not just how payments are made, but which banks can realistically support them.

A bank may offer “global payments,” but local payment capabilities vary significantly by market. In some countries, foreign banks lack direct access to domestic clearing systems and rely on local correspondents. In others, domestic payment schemes are so dominant that local banking relationships become unavoidable.

This is one reason companies expanding internationally rarely reduce banking complexity over time. They accumulate it.

A company entering five new markets may end up adding:

• five new local banking relationships
• five different onboarding processes
• five sets of payments formats
• five separate operational models for approvals, reconciliation, and reporting.

Even seemingly simple concepts become localised.

Take IBANs.

Within Europe, IBANs were meant to standardise account identification and reduce friction across borders. In practice, they introduced another phenomenon entirely: IBAN discrimination.

Despite SEPA rules explicitly prohibiting it, companies and consumers still encounter situations where foreign IBANs are rejected for payroll, direct debits, or supplier payments not because the accounts are invalid, but because organisations continue to expect domestic bank accounts.

A German employer may refuse a Dutch IBAN for salary payments. A French utility provider may reject a non-French account for direct debit collection. Businesses expanding internationally quickly discover that legal harmonisation does not always translate into operational acceptance.

So even inside supposedly unified regions, localisation persists.

Then there is the issue of scale – not technological scale, but institutional scale.

As companies grow internationally, they often assume their relationship with banks will evolve proportionally. Instead, they encounter another layer of segmentation: the bank itself.

Banks do not treat all corporates equally. They organise clients into segments – commercial banking, mid-market, corporate banking, multinational coverage, financial institutions, each with different service levels, product access, pricing models, and internal priorities.

For a growing company, this can create strange transitions.

A business may be considered strategically important in one country but too small to receive meaningful support in another. A treasury setup that worked well at €50 million in revenue may become insufficient at €500 million, triggering migrations to different banking teams, platforms, and approval structures.

The experience changes not only because the company grows, but because the bank’s perception of the company changes with it.

At smaller scales, onboarding may be relatively quick and standardised. At larger scales, complexity increases: more compliance checks, more documentation, more internal approvals. Access to advanced liquidity structures or connectivity methods may only become available once a company reaches certain thresholds.

In other words, expanding globally does not just mean adapting to foreign banking systems.

It also means adapting to how banks categorise you within those systems.

Over time, many treasury teams realise that international expansion is less about building a single global banking model and more about managing controlled inconsistency at scale.

This is where orchestration increasingly becomes essential.

Because the challenge is no longer simply accessing banks. It is managing the differences between them, between countries, payment rails, regulations, formats, and even the internal structures of the banks themselves.

Platforms like Cobase sit in the middle of that complexity. Rather than forcing companies to adapt operationally to every local variation, they create a consistent layer across fragmented banking environments. Local payment rails, global banks, regional formats, SWIFT, EBICS, APIs—all become part of the same operational framework.

The underlying fragmentation remains. A payment in Brazil still behaves differently from one in Germany. A US banking setup still differs fundamentally from a European one.

But from the treasury perspective, those differences become manageable.

And for companies expanding globally, that distinction matters more than the promise of a perfectly unified system.

Because that system was never truly global to begin with.

Also Read

• Bank Connectivity: The myth of the global bank
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Treasury is where risk meets opportunity: Vincent’s perspective
• Cash visibility starts with the treasurer, not the system: Julia’s perspective

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.

This article is written by our partner, Cobase

For decades, large international banks have positioned themselves as gateways to the global financial system. Their pitch is straightforward: one partner, global reach, consistent service. For multinational corporates, the appeal is obvious – simplify banking by consolidating relationships.

But beneath the branding, the idea of a truly “global” bank starts to unravel.

The limitation is not ambition or scale. It is jurisdiction.

Banks do not operate across borders in the way technology companies or logistics networks do. They expand into countries, but once there, they become subject to local rules – rules that define, often in granular detail, what services they can provide, how they provide them, and to whom.

What emerges is less a single institution and more a network of locally regulated entities, loosely stitched together under a common name.

That distinction matters.

A corporate working with a global bank across Europe, Asia, and the Americas might expect a consistent experience. Instead, they encounter variation at almost every layer. A payment setup that works seamlessly in the Netherlands may require adjustments in the United States. A liquidity structure available in London may not be permitted in Mumbai. Even something as routine as onboarding can turn into a multi-country exercise, with separate documentation, timelines, and approval processes for each jurisdiction.

In some cases, the gaps are subtle. A bank may offer ISO 20022 payment formats globally, but local implementations differ. Files accepted in one country may fail in another, not because the standard changed, but because interpretation did. Error handling, cut-off times, and processing logic follow local conventions, not global ones.

In other cases, the limitations are more explicit.

Take liquidity management. In theory, a multinational corporate should be able to centralise cash across accounts worldwide, optimising funding and reducing idle balances. In practice, that depends heavily on where the cash sits. European markets allow relatively sophisticated pooling structures, including notional pooling across entities. Move into markets like China or India, and those structures quickly encounter restrictions. Capital controls, regulatory approvals, and tax considerations can prevent funds from being moved freely or at all.

The result is a familiar problem for treasury teams: cash that exists, but cannot be used.

Payments tell a similar story. While a global bank may offer local payment capabilities in dozens of countries, it does not always control the full chain. In markets where it lacks direct access to domestic clearing systems, it relies on local correspondent banks. For the corporate client, this dependency is largely invisible until something goes wrong. Delays, additional fees, and reconciliation issues emerge, often without clear transparency into where in the chain the problem occurred.

In certain regions, even data becomes fragmented. Regulatory regimes increasingly require financial data to be stored and processed locally. For global banks, this means that account information, transaction data, and reporting cannot always be fully centralised. A corporate attempting to build a real-time, global view of its cash position may find that some pieces simply cannot be integrated in the same way as others.

And then there are the markets where global banks are only partially present or absent altogether.

In parts of Africa, Southeast Asia, and Latin America, even the largest international banks rely on partnerships with domestic institutions. In these cases, the “global” relationship effectively stops at the border, and the corporate is pulled back into the very fragmentation it was trying to avoid.

None of this is accidental. It reflects the underlying structure of the financial system.

Banking is, at its core, a nationally regulated industry. Governments retain control over their financial systems for reasons that go beyond efficiency: monetary policy, financial stability, capital controls, and oversight. These priorities impose boundaries that even the largest banks cannot cross.

The consequence is a persistent gap between how corporates operate and how banks are structured. Corporates expand internationally and expect their infrastructure to scale with them. Banks expand internationally but remain constrained locally.

This is why even the most sophisticated multinationals rarely rely on a single banking partner. They build networks—combining global banks for reach, regional banks for depth, and local banks for access. Integration becomes their responsibility.

And that is where a different type of solution has started to emerge.

Rather than trying to replace banks or force uniformity where it cannot exist, platforms like Cobase sit above this fragmented landscape and act as an integration layer. They connect to multiple banks—global and local, across channels such as SWIFT, EBICS, APIs, and host-to-host, and standardise how corporates interact with them.

In that model, the complexity of dealing with multiple banking entities does not disappear, but it is absorbed. Payment formats are converted automatically to meet bank-specific requirements. Differences in file structures, validation rules, and communication protocols are handled centrally. Data coming back from banks—balances, transactions, statuses is normalised into a consistent format.

The effect is not that a corporate suddenly has a “global bank.”

It is that it gains a single, controlled interface across many banks.

This distinction is subtle, but important. The fragmentation remains at the infrastructure level where it is dictated by regulation and market structure, but it is no longer fully exposed at the operational level.

In that sense, the role of integration shifts. It moves away from trying to find the one bank that can do everything, toward building a layer that can manage many banks as if they were one.

The “global bank,” then, is less a reality than an abstraction.

What corporates increasingly build instead is their own version of it—on top of the system as it actually exists.

Also Read

• Bank Connectivity: What ISO 20022 really solves and what it doesn’t
• Bank Connectivity: Global expansion meets local banking reality
• Bank Connectivity: The long failure to standardise banking
• Perfecting the art of Bank Connectivity
• Treasury is where risk meets opportunity: Vincent’s perspective
• Cash visibility starts with the treasurer, not the system: Julia’s perspective
• Humans of Treasury: Earning credibility early in treasury: Ed’s perspective
• Humans of Treasury: Treasury isn’t just systems and numbers. It’s people.
• Verification of Payee – The Reality: Not Everyone is Ready
• Future-proofing your Financial System: Ensuring Scalability and Adaptability

---

Join our Treasury Community

Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.