WHAT IS ISO 20022?

The future of financial messaging has arrived

The International Standards Organization (ISO), a worldwide federation of National Standards Bodies, developed the International Standard ISO 20022, or “ISO 20022” in 2004.

The ISO 20022 standard is not just another message syntax like SWIFT FIN or FPML. It is not designed to take the place of existing incumbent messaging standards and syntaxes. Rather, it is a method for developing standards, and a framework by which message syntaxes can be made to co-exist.  Formally speaking, ISO 20022 is a multi-part standard including a well-defined modeling methodology and a central repository.

The ISO 20022 Repository itself comprises a Business Process Catalog and a Data Dictionary. The message definitions are available as XML schema, and messages that can be combined together to support a specific business process are grouped into message sets. Each message set has an overarching set of documentation called the Message Definition Report, or MDR.  Currently there are 25 message sets in the ISO 20022 Repository.

The most important point, and source of confusion, is that ISO 20022 is both a model (ISO 20022 the model) and a set of XML (ISO 20022 XML) messages.

The ISO Technical Committee 68 (TC68, the ISO Technical Committee for Financial Services) has responsibility for the ISO 20022 standard. The ISO 20022 approval and registration process involves three registration bodies: Registration Management Group (RMG) Registration Authority (RA) Standards Evaluation Groups (SEGs) The RA and SEGs work together to validate and process the registration requests under the supervision of the RMG. The appointed ISO 20022 RA is SWIFT, but it is worth noting that while some SWIFT services do implement the ISO 20022 Standards, ISO 20022 is not a SWIFT standard.

The base ISO 20022 standards methodology provides for variants based on usage by services utilities such as SWIFT as well as for use by other utilities and market participants. These utilities and industry bodies who develop ISO 20022 implementations can submit them to ISO as candidates to be incorporated into the standard catalogues via the ISO 20022 registration process. The submission by Continuous Linked Settlement [CLS] of the Treasury [trea] message standards is an example.

In 2004, ownership of the standard moved from ISO TC68/SC4 (Securities and Related Financial Instruments sub-committee) to TC68 as the scope of the standard was broadened to include payments, treasury, and other areas of financial services. TC68 created WG4 (Working Group Four) to revise and manage ISO 20022. 

From a modeling perspective, Enterprise Data Management teams and Information Architects are embracing ISO 20022 for B2B data exchange as it provides a single standardization approach using a well-defined methodology, process and repository.

From a coverage perspective the standard includes ISO 20022-based models and ISO 20022 XML messages that support the institutional trade life cycle for securities, payments, treasury and the cards business.  There are currently over 300 messages in the repository, and more than 60 initiatives around the world that are leveraging the ISO 20022 standard messages.

The world of financial services organizations is about highly reliable, fast, auditable and seamlessly processable intra and inter-firm communications of instructions to enable business transactions. Historically these movements (or messages) evolved into standard formats based on national or regional boundaries, market participant initiatives, or standards mandated by specific industry utilities such as SWIFT. These message standards developed around silos of automation based on market practice or geographical locations, and the message standards were not compatible, i.e. each has their own schema and semantics.

By leveraging a common language, or reference data model such as ISO 20022, firms can vastly improve the quality of information sent between payments, securities and internal systems. Business transactions based on the ISO 20022 standard increase the reach of firms to more customers in more locations with less concern for national boundaries and local legacy standards. This is about differentiation and survival in a larger much more competitive and standardized global market. ISO 20022 will also force consolidation in transaction flows and proprietary implementations will no longer be sustainable or acceptable. This was an objective of the European Union SEPA initiative and consolidation pressure in the EURO payments landscape is already evident.

By using the ISO 20022 standard, firms can build and deploy canonical data models, such as the data model used to map data sources in a bank, leading to improved data quality and accurate information exchange.

There are many industry initiatives that are driving ISO 20022 adoption worldwide:

  • The Single European Payments Area (SEPA) and the European Payments Services Directive (PSD) are mandating the use of new ISO 20022 SEPA messages for payments which puts increased pressure on existing bespoke systems that typically use legacy ACH and SWIFT MT data formats. SEPA credit transfer and SEPA direct debits were introduced in 2008 and 2009 respectively, with a migration end-date regulation of February 1, 2014 for the Euro area.
  • The DTCC Corporate Actions Reengineering initiative requires firms to update their corporate actions business processes and related technologies to use ISO 20022 XML messages with the goal of retiring legacy systems on or before 2015.
  • JASDEC ISO 20022 - The Japan Securities Depository Center (JASDEC) has adopted ISO 20022 with plans to start using the ISO 20022 XML messages in 2014 and a goal to terminate customized and proprietary message formats by 2019.


In order to address messaging compatibility challenges between firms, the International Standards Organization [ISO], a worldwide federation of National Standards Bodies, developed the International Standard ISO 20022 – UNIversal Financial Industry message scheme (also known as ISO 20022/UNIFI, now abbreviated to ISO 20022).

The origins of ISO 20022 XML can be traced back to the late 1990’s when XML first exploded onto the scene.  There was an early push to create an XML version of the ISO 15022 standard, known as 15022ML and focused on Securities.  Soon after that the scope was widened to include Payments, and other business areas.  And, finally, in 2004 the first edition of the ISO 20022 standard was released.

In May 2013, ISO released ISO 20022:2013, an update to the ISO 20022 standard. As part of this release the ISO 20022 Repository is now downloadable from www.iso20022.org, free-of-use and distribution.

The full and current ISO 20022 XML message catalogue is available online at www.iso20022.org.  The naming conventions for the ISO 20022 messages are based on a format of: xxxx.aaa.bbb.cc


  • xxxx - 4 char business area; e.g. pacs
  • aaa - 3 digit message type; e.g. 008
  • bbb - 3 digit variant number; e.g. 001
  • cc - 2 digit version number; e.g 01

Business areas xxxx include the following designations that correlate with business areas:

  • Cash Management – camt
  • Payment Clearing and Settlement – pacs
  • Payment Initiation – pain
  • Reference Data – reda
  • Securities Management – semt
  • Securities Settlement – sese
  • Securities Trade – setr
  • Trade Services – tsrv
  • Treasury – trea

So the relevant business domain is identifiable within the message type designation, and those who work in financial services messaging have a new set of terminology to learn.


Payments were the first messages implemented on the SWIFT network back in 1977, [MT100] and are leading the way in ISO 20022 adoption.

The ISO 20022 pacs and pain standards form the basis for the Single European Payment Area [SEPA] payment messages. The European Payment Council [EPC] has developed a set of ISO 20022 SEPA implementation guidelines that define the proper use of the ISO 20022 message standards. Further, the EPC has decided to make the ISO 20022 SEPA standard compulsory in the bank-to-bank domain [pacs], while for the customer-to-bank domain [pain] the EPC just recommends their usage.

For the purpose of this question we will focus specifically on just the ISO 20022 SEPA specialization usage, not the overall SEPA project.

The initial industry implementation focus is on the legally SEPA mandatory pacs messages. The EPC issued two variant schemas for each of the pacs messages, being the 002 and 003, where the standard naming convention is consistent with that used above.

So by way of example for an Interbank Payment we have:

  • pacs.008.001.01.xsd - ISO 20022 (Financial Institution to Financial Institution Customer Credit Transfer)
  • pacs.008.002.02.xsd – ISO 20022 SEPA Mandatory
  • pacs.008.003.02.xsd - SEPA AOS (where AOS stands for Additional Optional Services which allow additional elements to be used but which do not compromise the base SEPA restrictions. These can then be used by individual banks or providers to offer value added services to communities of banks.)

As you can see from this ISO 20022 SEPA example, the standards are extensible by design. This is common in other standards such as FIX and FpML, where these standards provide extension points for adding both additional processes and new products while using the core standards as the foundation. This does create new meta-data management challenges as specialized dialects proliferate based on market or usage specializations, and this creates a shift in the technical approach to integration projects to be much more focused on application level data services and meta-data based integration technologies.

At the same time that the ISO 20022 initiative has been evolving, so have XML-based technologies. The attraction is that XML presents at least a common mechanism to express the message syntax, while application and integration development technologies support XML out of the box. But using ISO 20022 standards and XML technologies out-of-the-box is not as simple as it sounds.

The ISO 20022 standard also includes semantic validation rules – these are business rules that specify logical relationships between sets of data elements. A simple example may be that trade date should be on or before settlement date. These rules are designed as part of the standard to ensure that the messages are well formed from a business perspective and straight-through-processable. They are not implementable in XML and require some overlay validation logic implementation. And just as the base XML standard is extensible, so are the validation rules.

For example in the EPC/SEPA variant Direct Debit [DD] messages there is a rule that needs to be applied to every Identifier of Creditor element called the AT02 which is rather like an IBAN check and requires data manipulation and Modulus 97-10 calculation and checking.

Most firms now realize that ISO 20022-based standards adoption has reached critical mass. It is not optional and all firms need a coherent plan for how they will support both legacy standards and new standards during the transition period. One option is to simply trust that their vendor suppliers have the answers. If this is the case, firms should be sure to ask them for their product roadmap.

Alternatively, and more advisedly, the firm should have an architectural roadmap that capitalizes on reusing ISO 20022 messaging and integration services. They should look to use standards-based integration technologies that support the legacy and the new XML-based emerging standards, and solutions that provide platform-neutral deployment technologies to use with existing computing infrastructure.

Adoption of ISO 20022 standards will not be a big-bang approach. It is more likely to be a market-driven migration to a common language.

With the release of ISO 20022:13, it is expected that software tool vendors will begin adopting this standard.  Ideally products should enable you to:

  • Browse, navigate, search and extend the ISO 20022 Repository (Business Process Catalog and Data Dictionary)
  • Create ISO 20022-based canonical models
  • Create ISO 20022-compliant schemas
  • Quickly map internal and external data structures to the ISO 20022 model.
  • Graphically compare models and manage versions
  • Provide timely updates as the underlying ISO 20022 model changes