Category: Regulations and Standards

ISO 20022

Simply put

ISO 20022 is an open global standard for exchanging financial information electronically between financial institutions. It defines a consistent, structured way to carry richer data across payments and other financial activities. The goal is to make financial messages more detailed and uniform than older messaging formats.

Formal definition

ISO 20022 is a multi-part International Standard prepared by ISO Technical Committee TC68 (Financial Services) that establishes a common platform for developing financial messages and describes a metadata repository containing descriptions of message components. It provides consistent, structured data intended for electronic data interchange between financial institutions across business areas including payments, securities, trade services, cards, and foreign exchange. It is implemented in modern payment infrastructures; for example, the FedNow Service uses the ISO 20022 messaging standard. Note that ISO 20022 governs financial messaging and is separate from the PCI standards; whether and how ISO 20022 messages carry cardholder data has implications that depend on implementation and must be assessed against the applicable PCI DSS requirements.

Why it matters

ISO 20022 matters because it establishes a common, structured foundation for exchanging financial information across institutions and business areas, including payments, securities, trade services, cards, and foreign exchange. Older messaging formats often carried limited or inconsistently structured data, which complicated automation, reconciliation, and analysis. By providing consistent, rich, and structured data, ISO 20022 is intended to make financial messages more detailed and uniform, which can help institutions process transactions and interpret message content more reliably.

For security and compliance teams, the significance lies in how the standard is implemented rather than in the standard itself. ISO 20022 governs financial messaging and is separate from the PCI standards. Whether and how a given ISO 20022 implementation carries cardholder data has direct implications for PCI DSS scope, and those implications depend on the specific implementation. Richer, more structured message data can be an operational advantage, but it also means teams must understand exactly what data fields are populated and transmitted so that any cardholder data is handled under appropriate controls.

The standard is used in modern payment infrastructures; for example, the FedNow Service uses the ISO 20022 messaging standard. As such implementations expand across business areas, organizations that interact with these systems should assess how message content maps to their existing data-handling and compliance obligations rather than assuming a messaging-format change is compliance-neutral.

Who it's relevant to

Payment processors and financial institutions

Processors and banks that exchange financial information electronically use ISO 20022 to send and receive consistent, structured messages across business areas. They are responsible for mapping legacy formats to ISO 20022 message definitions and for understanding which fields their implementation populates, particularly where message content may include cardholder data.

Compliance officers and PCI DSS assessors

Because ISO 20022 is separate from the PCI standards, compliance teams need to determine whether a given implementation causes ISO 20022 messages to carry cardholder data, and if so, how that affects PCI DSS scope and required controls. Scope conclusions should be validated against the current published PCI DSS requirements rather than inferred from the messaging format alone.

Security engineers and integration teams

Engineers building or connecting to infrastructures that use ISO 20022, such as the FedNow Service, work with the standard's structured message definitions and metadata repository. They should confirm exactly what data each message component transmits so that any sensitive data is protected under appropriate controls during transmission and storage.

Fraud analysts and risk teams

The richer, more structured data available in ISO 20022 messages may provide additional context that supports transaction analysis. Analysts should treat the availability of more detailed fields as implementation-dependent and should not assume any particular data element is present or reliable without confirming what a given system actually populates.

Inside ISO 20022

Message Format Standard

ISO 20022 is an international standard that defines a common methodology and syntax for financial messaging across payments, securities, trade services, cards, and foreign exchange. It is a standard for structuring and exchanging electronic messages, not a payment security control in itself.

Data Dictionary and Business Model

The standard provides a repository of reusable business concepts and data components, along with a business process model, so that message elements carry consistent, well-defined meanings across participants and systems.

XML and ASN.1 Syntax

ISO 20022 messages are commonly expressed in XML (and can use ASN.1), giving structured, richly typed fields that can convey more granular remittance and party information than many legacy formats.

Message Definitions

Individual message types are identified by structured names (for example, message identifiers grouped by business area) covering functions such as customer credit transfers, payment status reports, and account reporting.

Structured Remittance and Party Data

The format supports detailed originator, beneficiary, and remittance data. Where such messages carry payment card data, the same distinction applies as elsewhere: cardholder data may be handled under defined controls, while sensitive authentication data must not be stored after authorization.

Common questions

Answers to the questions practitioners most commonly ask about ISO 20022.

Does adopting ISO 20022 by itself improve payment security or reduce fraud?

No. ISO 20022 is a messaging standard that defines a common syntax and richer data model for financial messages; it is not a security control and does not by itself prevent or reduce fraud. The additional structured data it can carry may help support fraud analytics and reconciliation, but any security or fraud-mitigation benefit depends on how implementers use that data alongside separate controls. ISO 20022 is distinct from PCI DSS and other PCI standards, which govern the protection of cardholder data and sensitive authentication data.

Is ISO 20022 the same thing as PCI DSS or a payment card security standard?

No. ISO 20022 is a standard for the structure and format of financial messages, while PCI DSS is a security standard governing the protection of cardholder data and sensitive authentication data. They address different concerns and are maintained by different bodies. Using ISO 20022 messaging does not satisfy PCI DSS obligations, and where messages carry account or cardholder data, the applicable PCI standards and controls still apply according to your implementation and validation.

How should we handle cardholder data or sensitive authentication data that may appear in ISO 20022 message fields?

Treat any account data within message fields according to the applicable data-protection requirements rather than the messaging format alone. Cardholder data such as PAN may be stored only under defined controls, while sensitive authentication data such as full track data, card verification values, and PINs must not be stored after authorization even when encrypted. Applying controls such as tokenization, truncation, or masking to message content changes data handling differently, and the effect on scope depends on implementation and validation, not on the ISO 20022 label.

Does the richer data model in ISO 20022 expand the scope of systems that handle account data?

It can. Because ISO 20022 messages can carry more structured and detailed information, systems that transmit, process, or store those messages may come into scope if the messages contain account data. You should map data flows to identify where PAN or other account data traverses ISO 20022 messages, then apply appropriate controls. Whether a given system is in scope depends on the specific data it handles and how that handling is validated against the applicable standard.

How do we reconcile ISO 20022 migration timelines with our compliance obligations?

ISO 20022 adoption timelines are set by payment systems, market infrastructures, and network operators and can vary by region and scheme, so confirm the relevant schedules with the operators you connect to. Compliance obligations for protecting account data continue to apply throughout any migration, and you should confirm requirements against the current published version of the applicable standard rather than assuming fixed requirement numbers or dates.

What should be included in testing when we implement ISO 20022 messaging in a payment environment?

Testing should verify not only correct message structure and interoperability with counterparties but also that any account data within messages is handled in line with applicable controls. This includes confirming that sensitive authentication data is not retained after authorization and that any tokenization, truncation, or masking behaves as intended in message content. Validate data handling against your documented data flows and the current applicable standard, and treat message format conformance and data-protection validation as separate but complementary activities.

Common misconceptions

ISO 20022 is a security standard that protects payment data.

ISO 20022 is a messaging standard defining how financial data is structured and exchanged; it is not a security or compliance framework. Protection of any cardholder data conveyed within these messages is governed by controls validated against the applicable PCI standards, such as PCI DSS, and confirmed against the current published version rather than assumed from the message format alone.

Adopting ISO 20022 automatically brings a system into PCI DSS scope, or automatically removes it from scope.

Scope depends on whether account data is stored, processed, or transmitted and on the controls and validation applied, not on the message format label. If ISO 20022 messages carry primary account numbers or other cardholder data, those data flows should be assessed for scope like any other; using tokenization, truncation, masking, or encryption affects scope only based on implementation and validation.

ISO 20022 and formats like PA-DSS or the PCI Software Security Framework are the same kind of thing.

ISO 20022 is a financial messaging standard maintained separately from the PCI standards. PCI DSS, PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS govern distinct security and compliance requirements; the applicable standard for a given control should be named specifically rather than attributed to the messaging format.

Best practices

Map every ISO 20022 message flow that may carry account data, and determine where cardholder data is stored, processed, or transmitted to assess PCI DSS scope against the current published version of the standard.

Ensure that sensitive authentication data such as full track data, card verification values, and PIN blocks is never persisted in ISO 20022 messages or downstream stores after authorization, even in encrypted form.

Apply appropriate data-reduction controls to any PAN in message payloads, and validate that the chosen approach, whether tokenization, truncation, masking, encryption, or hashing, actually achieves the intended scope and protection rather than relying on the label.

Confirm which specific standard governs a given control, and do not treat the ISO 20022 format as a substitute for PCI DSS, PCI P2PE, PCI PIN, or other applicable requirements.

Validate structured remittance and party fields for data minimization so that message enrichment does not introduce unnecessary sensitive data into scope.

Coordinate ISO 20022 migration with security, compliance, and fraud teams so that changes to message structure are reflected in data-flow diagrams, monitoring, and scope documentation.