ISO 20022 is often described as “the new message format for payments”. That is true, but it undersells what the migration really involves. For Norwegian banks, payment institutions and other financial players, this is less about swapping one format for another and more about dealing with substantially richer data across the entire payment chain – with everything that demands of systems, data quality and testing.
From sparse fields to structured data
The old payment messages, such as the MT formats in the SWIFT world, were created in an era when every byte cost something. The result is messages with short, partly free-text fields where a great deal of information is crammed together or simply lost. It works, but it makes payments hard to automate, reconcile and control without manual effort.
ISO 20022 turns this around. The standard is XML-based and structured, with clearly separated fields for sender, recipient, intermediaries, purpose and references. There is room for far more information, and that information is structured so machines can actually use it. For payments across borders and infrastructures this is a genuine step up: better traceability, more precise reconciliation, and a stronger basis for both compliance and analysis.
It is precisely this richness that makes the migration demanding. More structure means more to populate correctly, more to validate, and more ways for things to go wrong if the data does not hold up.
The practical challenges
The first challenge is data quality. ISO 20022 has fields that expect structured, correct information – proper address data on payer and payee, for instance. Many internal systems have never been forced to keep such data clean. When the format suddenly requires it, weaknesses in the data foundation that have been hidden for years come to the surface. This is not a format problem; it is a data quality problem that the format merely makes visible.
The second is mapping. Few organisations replace every system at once. In practice, data has to be translated between old and new formats, often in both directions. When you map from a rich ISO 20022 message down to a legacy format with fewer fields, you lose information. You then have to know what can be dropped, what must be preserved, and how to keep important data from vanishing in the conversion. This is detail work where domain understanding matters more than the choice of technology.
The third is coexistence. The transition periods are long, and you should expect to handle both formats simultaneously for some time – internally, towards counterparties, and towards infrastructure that migrates at different speeds. Solutions therefore have to be built to live in a hybrid reality, not for a clean end state several years out.
The fourth is testing. Structured messages bring more combinations, more validation rules and more edge cases. Thorough testing against realistic data – including the ugly cases from production – is what separates a migration that holds up from one that generates errors and rejected payments after go-live.
What you should prepare
Start with the data, not the format. Map out where the structured fields ISO 20022 expects actually come from in your systems, and be honest about the quality. Often this is where the real work lies, and it is work that takes time.
Treat mapping and coexistence as first-class parts of the solution, not as temporary joints. They will be around for a long while, and they deserve the same architecture and testing discipline as everything else. Build in validation early, so bad data is stopped before it reaches a counterparty, not after.
And see the migration as an opportunity, not just an obligation. The richer data ISO 20022 brings is the same foundation that good transaction monitoring, regulatory reporting and analysis rest on. A migration done properly strengthens the data foundation in areas well beyond payments themselves.
ISO 20022 is, in the end, a data foundation project disguised as a format change. Those who succeed are the ones who treat it that way – with patience for the data, respect for the details, and a plan that survives the long transition periods reality actually presents.