ISO 20022 Explained: The New Standard for Payment Messaging

What ISO 20022 Actually Is

ISO 20022 defines both a methodology for building financial message standards and a library of message definitions. Unlike legacy formats such as SWIFT MT or Bacs Standard 18, ISO 20022 messages are built on a data dictionary of precisely defined elements. Each field has a known type, length and semantic meaning, which makes it possible for systems to parse, validate and act on message content without human intervention.

The standard organises messages into named families based on business function. The prefix tells you the domain: pacs messages handle payments clearing and settlement between financial institutions; pain messages cover payment initiation by customers; camt messages carry cash management and account reporting data. Each message within a family has a numeric identifier and version, so pacs.008.001.10 is version 10 of the financial institution credit transfer message.

Messages are written in XML and validated against published schemas. The richer structure means a remittance line that previously carried 140 free-text characters can now carry structured invoice references, debtor names, legal entity identifiers (LEIs), purpose codes and fully parsed postal addresses, each in a dedicated field that downstream systems can read programmatically.

Common ISO 20022 Message Types

The table below covers the message types UK payment firms encounter most often. These appear in CHAPS, SWIFT cross-border flows and, increasingly, in connections to Pay.UK infrastructure.

Key Migration Milestones: UK and Global

The migration to ISO 20022 has unfolded in phases across domestic and cross-border networks. UK firms need to track obligations across both the Bank of England's CHAPS regime and SWIFT's CBPR+ programme for correspondent banking.

What Richer Data Means in Practice

The commercial case for ISO 20022 rests on the quality and structure of the data it carries, not just on technical modernisation. Several fields are directly relevant to compliance and operations at a UK payment firm.

Structured names and addresses replace free-text strings with parsed fields: given name, family name, street name, building number, post code, town, country. This matters for sanctions screening. A sanctions filter matching against a structured address field is far more accurate than one searching a 35-character free-text blob that might contain a name, a street and a country code collapsed together.

Purpose codes are standardised two to four character codes that describe the economic reason for a payment. Examples include SALA for salary, BEXP for business expenses and PROP for property-related payments. Purpose codes feed directly into transaction monitoring models and enable automated categorisation for reconciliation.

Legal Entity Identifiers are 20-character alphanumeric codes issued by GLEIF-accredited bodies that uniquely identify legal entities. The Bank of England now requires LEIs on certain CHAPS interbank messages. For a compliance team, LEIs reduce the ambiguity in counterparty identification that free-text names introduce.

Remittance information in ISO 20022 can carry structured invoice references, creditor references and payment purposes in dedicated fields rather than embedded in a narrative line. This supports automated reconciliation on the beneficiary side and reduces the manual exception-handling workload in accounts receivable teams.

What This Means for Your Payment Firm

For payment institutions, e-money firms and fintechs connecting to UK payment schemes, ISO 20022 migration creates work across several domains.

Systems and connectivity: if you connect directly to CHAPS as a Direct Participant, or to SWIFT for correspondent banking, your messaging layer must produce and consume ISO 20022 MX messages. If you connect indirectly through a sponsor bank or payment service provider, you need to confirm with that provider how ISO 20022 fields are passed through to you and whether any truncation or translation is occurring.

Sanctions and AML screening: your transaction monitoring and sanctions screening tools must be capable of reading structured ISO 20022 fields. Many legacy screening systems were built to parse MT field offsets. A system that pulls the beneficiary name from a fixed character position in an MT103 will not work correctly against a pacs.008 XML message. This is a real risk that regulators and auditors are beginning to focus on.

Data quality obligations: the Bank of England has signalled that it will monitor compliance with mandatory enhanced data requirements and follow up with Direct Participants where data quality falls short. From November 2026, malformed or unstructured addresses in CHAPS messages will result in outright rejection. Firms need data quality controls upstream, at the point of payment initiation, not only at the point of transmission.

Reconciliation and reporting: the structured remittance data in camt.053 statements replaces the narrative-heavy MT940. Treasury and finance teams that rely on bank statement feeds for automated reconciliation will need to update their import mappings and parsing logic.

LEI maintenance: if your firm is required to include LEIs in CHAPS interbank messages, you need an active, annually renewed LEI and a process for validating counterparty LEIs at the point of payment setup. Lapsed LEIs will create compliance failures.

Migration Challenges

The industry is broadly compliant on the headline migration deadlines, but several practical challenges remain common.

Data truncation in correspondent chains is a persistent problem. A payment that originates in ISO 20022 MX format may pass through an intermediary bank that translates it to MT for a legacy internal system and back to MX for onward routing. Each translation risks losing structured fields that cannot be represented in the older format. SWIFT has published mapping guidelines, but translation is lossy by design.

Legacy core banking systems at smaller institutions often do not produce structured addresses natively. Populating ISO 20022 address fields accurately requires changes to customer onboarding data capture, not only to the payment message assembly layer. Firms that collected addresses as a single free-text field face a significant data remediation exercise.

Testing across the full payment chain is complex. A firm can validate its own message output against the published schema, but end-to-end testing requires cooperation from correspondent banks, payment scheme operators and beneficiary institutions. The Bank of England has provided testing environments and a detailed ISO 20022 Handbook, but multi-party testing coordination remains a practical bottleneck for smaller firms.

Staff awareness is often underestimated. Operations, compliance and technology teams each interact with payment messages differently. Ensuring that compliance teams understand what Purpose Codes and LEIs are and why a missing LEI on a pacs.009 is a regulatory failure, not just a technical error, requires targeted training.

Conclusion

ISO 20022 is already live in CHAPS and mandatory on SWIFT for cross-border payments. The migration is not a future event to monitor: it is a current operational and compliance obligation. The Bank of England has a published schedule of mandatory data requirements running through to November 2027, and firms that treat this as a back-office IT project rather than a cross-functional programme risk data quality failures, rejected payments and regulatory scrutiny.

The upside is real. Structured, rich payment data reduces false positives in sanctions screening, enables automated reconciliation, improves fraud detection and creates the foundation for the value-added payment services the UK National Payments Vision expects the industry to build. Firms that invest in clean data pipelines and ISO 20022-native processing now will be better placed to compete as the UK retail infrastructure also transitions to the standard.

Frequently asked questions