ISO 20022 migration: what banks should be planning for now

For many banks, ISO 20022 felt like a deadline to survive. The coexistence period for cross-border payment instructions on the SWIFT network ended in November 2025, yet the real work of the migration is far from over.

Meeting the cross-border cut-over was necessary, but it was never the whole story. Domestic high-value and instant payment schemes are on their own timelines, internal systems still speak older formats, and many institutions crossed the line by translating messages rather than truly adopting the richer data ISO 20022 carries. The question now is not whether you are compliant, but whether you are getting the value the standard was designed to deliver.

Know where you actually are

Start with an honest inventory. List every payment flow that touches your bank (cross-border, domestic real-time gross settlement, instant payments, card settlement and internal transfers) and record, for each one, which format it uses at every hop. It is common to find that a message arrives in ISO 20022, is converted to a legacy format for the core banking system, and is converted back again on the way out. Each conversion is a place where data can be lost.

Data is the real migration

ISO 20022 is valuable because it is structured. Names, addresses, purposes and remittance information each have their own place, instead of being squeezed into free-text fields. That structure is what enables better sanctions screening, straight-through processing and richer information for customers. But it only helps if your systems capture and preserve it.

• Structured addresses: check that customer and counterparty addresses are held in structured form in your core and onboarding systems, not just in a single text line.
• Truncation: identify every point where a field is shortened to fit an older system. Truncated data is lost data.
• Reference data: review how you hold identifiers such as Legal Entity Identifiers and purpose codes, and who maintains them.

Do not let translation become permanent

Translating between legacy formats and ISO 20022 was a sensible way to meet the deadline. As a long-term architecture, it is a liability: every translation layer adds cost, latency and risk, and strips away the richer data that made the migration worthwhile. Make a plan, with dates, to move each internal system to native ISO 20022 handling, starting with the flows that carry the most volume or the most compliance risk.

Test end to end, not message by message

A message that validates against the schema can still fail in production. Real problems appear between systems: the switch accepts a message the core banking system cannot post, screening raises alerts on data it has never seen before, or reconciliation breaks because references no longer match. Testing should follow a payment from initiation to settlement and reconciliation, including rejections, returns and investigations, not just the happy path.

Prepare operations and screening teams

Richer data changes daily work. Sanctions screening sees more information, which can improve accuracy but may also change alert volumes. Investigations and exceptions teams need to read new message types confidently. Brief these teams early and give them examples drawn from your own traffic.

A practical next 90 days

1. Weeks 1 to 4: complete the payment-flow inventory and identify every translation and truncation point.
2. Weeks 5 to 8: prioritise flows by volume and risk, and agree a target date to remove each translation layer.
3. Weeks 9 to 12: build an end-to-end test set from real scenarios, and run it against your current setup to establish a baseline.

ISO 20022 rewards the banks that treat it as an opportunity to clean up their payment data and architecture. The deadline has passed; the advantage is still there to be taken.