ISO 20022 migration: what changes in a payment message.

What the standard actually is

ISO 20022 is a standard for financial messaging. It provides a shared data dictionary and a method for defining messages, and market infrastructures, schemes and communities then publish their own usage guidelines that constrain it. That layering matters more than anything else in a migration: the standard says what may be sent, and the scheme says what must be, so a message can be valid against the standard and rejected by the scheme.

The standard itself imposes no obligation on anyone. What obliges a firm is a scheme rulebook, a market infrastructure mandate or a counterparty requirement. Establish which of those applies before scoping anything, because each has its own variant, its own timetable and its own validation.

Structured data replaces free text

Legacy payment formats carried a great deal of meaning in fixed-length free-text lines. Operations teams learned local conventions for what went where, and those conventions were rarely documented. The new messages replace most of that with named, typed elements.

The migration difficulty follows directly. Populating a structured element requires knowing which piece of the old free text meant what — and for a long tail of payments, nobody does. Discovering that is the first substantive workstream, and it is an analysis task rather than an engineering one.

Parties and addresses

Parties — debtor, creditor, their agents, ultimate parties and any intermediaries — each have their own structured blocks, with identification separated from name and address. Addresses move from unstructured lines to named components: street, building, postcode, town, country subdivision, country.

Two consequences recur. Existing customer records frequently cannot be decomposed into structured components reliably, particularly where they were captured as a single block. And schemes increasingly expect structured or hybrid addresses rather than unstructured ones, so the decomposition is not optional indefinitely. This is customer data remediation, and it belongs on the critical path rather than in the backlog.

Remittance information

Remittance information can be structured — referenced documents, amounts, creditor reference — or unstructured, and the value of the migration to a corporate is almost entirely in the structured form, because it is what allows automatic reconciliation of a receipt against an invoice.

The trap is that structured remittance is optional under the standard and constrained differently by each scheme. A migration that maps everything into the unstructured element passes validation, satisfies the mandate, and delivers none of the benefit that justified the programme.

References that must survive

• End-to-end identifier — assigned by the originating party and intended to travel unchanged the whole way to the account statement.
• Transaction identifier — assigned by the sending institution for the interbank leg.
• Message identifier — identifies the message itself rather than the payment.
• Unique end-to-end reference — used in cross-border messaging to track a payment across institutions.

Each has to survive every internal system boundary and every format transformation. The commonest defect in a migration is a reference regenerated at an internal hop, which silently breaks the tracking the standard exists to provide. Test this explicitly, end to end, rather than assuming it.

Coexistence and truncation

Migrations run with legacy and new formats in parallel, which means messages are translated between them. Translation from a richer format to a poorer one truncates: a structured address becomes lines, extended remittance data is dropped, and characters outside the legacy set are substituted. Translation back does not restore what was lost.

Three rules keep this survivable. Know which of your flows are translated and which are native, because the risk lives entirely in the first group. Never treat a round trip as lossless. And log what was truncated, so a payment investigation can reconstruct what the originator actually sent.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.