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.
