We're hiring — join the team.
Payments

ISO 20022 without the fire drill: a co-existence approach to migration

ISO 20022 is not just a format change — it is a data upgrade for the entire payment chain. A staged co-existence strategy lets banks migrate without breaking what already works.

CodeStakes Payments Practice9 min read

Part of our work in Payments & Transaction Services

Standardized ISO 20022 payment messaging flowing through a bank's systems

ISO 20022 is often described as a messaging standard, but that undersells it. It is a shift from terse, positional payment messages to richly structured, data-rich ones. Where a legacy SWIFT MT message squeezed remittance information into cramped free-text fields, an ISO 20022 MX message carries structured parties, purpose codes, regulatory data, and remittance detail that downstream systems can actually parse and act on. For banks, that richer data is the whole point — better reconciliation, sharper sanctions screening, and analytics that were never possible before.

The difficulty is that this richer data has to flow through systems that were built for the old world. Core banking platforms, sanctions engines, reconciliation tools, and reporting pipelines were all designed around MT-shaped data. A big-bang switch to MX would mean upgrading every one of those systems on the same weekend — an operational risk no bank with uptime obligations should accept. The pragmatic path is co-existence: running MT and MX in parallel and translating between them at well-defined boundaries while each downstream system migrates on its own timeline.

Co-existence depends on a robust transformation layer. We build automated MT-to-MX and MX-to-MT mapping that preserves data fidelity in both directions and, critically, validates against the network's usage guidelines rather than just the base schema. The hard cases are the ones that betray naive mappings: an MX message may carry structured data that has no clean home in an MT message, so truncation rules must be deliberate, logged, and reversible where possible. Getting this wrong shows up later as failed reconciliations and compliance gaps, so the transformation layer is where the engineering rigor has to concentrate.

Data enrichment is the opportunity hiding inside the obligation. Because MX messages carry structured purpose codes, legal entity identifiers, and properly separated party information, the migration is a chance to clean up data quality that legacy formats let banks ignore. Validation at the point of transformation catches malformed or missing data early, rather than letting it propagate into settlement and reporting. Banks that treat the migration as a data-quality program, not just a format swap, get far more value from the same effort.

Sequencing the migration matters as much as the transformation engine. We typically start by making inbound MX messages safe — translating them to MT for systems that are not yet ready — so the bank can receive the new format the moment the network requires it. Outbound MX generation follows once core systems can supply the richer data natively. Throughout, observability is essential: every transformed message should be traceable end to end, with clear visibility into what was enriched, what was truncated, and why.

Sanctions and compliance teams deserve special attention during the transition. The structured parties and richer narrative fields in MX messages change what screening engines see, which can shift both true-positive and false-positive rates. Migrating screening rules in lockstep with the message format — and testing them against realistic message samples — prevents the unwelcome surprise of either missed hits or an alert backlog that overwhelms investigators on go-live day.

The deadlines here are externally imposed and unforgiving. Network mandates set the dates, and a bank that is not ready risks rejected payments and regulatory exposure. But the deadline is not a reason to rush a risky cutover. A staged co-existence approach lets institutions meet the mandate's hard requirements first — receiving and acknowledging MX traffic — while modernizing the deeper systems methodically behind that safe boundary.

Done this way, ISO 20022 migration stops being a fire drill and becomes a foundation. The same transformation and validation infrastructure that carries a bank through co-existence becomes permanent payment-data plumbing: better reconciliation, cleaner compliance, and a platform ready for the next wave of real-time and cross-border payment innovation rather than perpetually catching up to it.

  • ISO 20022
  • SWIFT MT/MX
  • Payments modernization
  • Compliance

Part of our work in Payments & Transaction Services

Want to talk through a challenge like this?

Start a conversation