The Challenge
Currently, cross-border payments operate on fragmented standards, subject to local practices and their variants. These often different and inconsistent messaging standards make it difficult for Financial Market Infrastructures (FMIs), Financial Institutions (FIs), machines, and ecosystems to communicate with one another in a common language. This can lead to inefficiencies in payments processing and poses a potential barrier to data automation capabilities, especially on an international scale. Globalization has highlighted the need for interoperability. The industry migration to ISO 20022 seeks to address these challenges by creating a standard to which all market participants will adhere.
The Benefits
ISO 20022 is a global and open financial messaging standard for financial institutions set by the International Organization for Standardization (ISO), an independent, non-governmental standard-setting body. ISO 20022 is a language based on a business dictionary that unifies many existing, fragmented standards. ISO 20022 incorporates a large amount of highly structured data that will provide huge benefits for all market participants. The enriched data sets will promote end-to-end automation through the transaction life cycle and increase machine-readability - enabling faster processing, greater openness, visibility, and interoperability across different regions and FMIs.
ISO 20022 Migration Timeline
Clearing systems and FMIs around the globe are moving to the ISO 20022 standard and reporting messages across the SWIFT network will move from MT format to MX format. During this coexistence period, both formats will be accepted and supported on the SWIFT network, until 2025 when ISO 20022 will become the sole globally recognized standard.
ISO 20022 is a standard for exchanging electronic messages Uses XML syntax and offers structured, rich data This format is already used by many real-time, low-value, and high-value clearing systems around the world Offers richer references and improved remittance information. Work on implementing ISO 20022 is well underway in the APAC region (see Figures 1 and 2). Japan’s central bank, for example, has redesigned its real-time inter-banking. For example, in 2014, two new ISO 20022 messages were established to carry remittance. SWIFT, for example, is doing a “migration” approach, where there will be a coexistence of both FIN and ISO 20022, but should a Financial Institution & Intermediary send an ISO 20022 message, then one must be able to receive and pass that ISO 20022 along on any redirected message.
SWIFT plans to begin their migration in November 2022, to allow their migration efforts and development to coincide with other strategic initiatives.* The end date to enable full ISO 20022 for cross-border payments is still November 2025 and their full commitment to move the SWIFT community to ISO 20022 remains strong.
Preparing for the Migration
Clients will need to ensure that they understand the details and implications of ISO 20022, are developing their own migration plans and are considering their internal systems’ readiness to support the move to this new standard. For more information, please visit the SWIFT website or view Citi’s material below.
Citi’s Commitment to You
Citi remains committed to pushing forward and executing on our ISO 20022 strategy around the world. Citi will also continue to support and guide our clients through this period of transformation. We will support ISO 20022 payments and partner testing, consult clients on country specific nuances and requirements, and keep you aprised on the CBPR+/ISO standards as well as all Market Infrastructure migration timelines, as they evolve. We remain committed to continued sharing of thought leadership and guidance on how clients can prepare their systems and people for this migration, while remaining compliant.
Please reach out to your Citi Representative to discuss the impact of the ISO 20022 migration on your Citi services.
*SWIFT has announced a delay in their ISO 20022 migration timeline to now begin in November 2022.
DISCLAIMER: Articles are written to reflect the interests and views of the author(s), and are not intended as an official Payments Canada statement or position. Furthermore, all commentary will be moderated and reviewed before posting and will be subject to standard community rules and guidelines.
Summary1
ISO 20022 is the culmination of years of effort around the world to get everyone talking the same language in financial services regardless of their jurisdiction or local specialties.
In this thought piece, we provide a look at some of the issues that integrators are having with the real-world implementations of ISO 20022-based interfaces and suggest how the industry can work together to solve them. We’ve reached a cross-road where the pace of technology outstrips the pace of standards development, and we need a model that will help the industry move forward with the technology implementations and not need to rely on the standards bodies within ISO to spend years creating message formats that are obsolete by the time they are published. Technical implementations of the standard for things like APIs need the flexibility for industry to quickly set messages in new formats if they can be shown to trace back to the ISO published examples.
The big challenge in bringing together the global financial ecosystem is that we use a variety of terms across different financial jurisdictions to reference the same thing and because of this, the thousands of data models embedded in millions of financial systems do not align easily. This was the genesis of the ISO 20022 standard that created a globally standardized set of data terminology2 and definitions. The standard then goes a step further by using those data definitions to describe sets of messages that can be used for moving data between entities in the financial system. This empowers the participants in the financial ecosystem to map their data consistently to this global data definition.
As an example, the ISO 20022 standard defines the term of ‘Debtor’ as a person, company or organization that is initiating a payment. So, for any usage of synonyms like payor, buyer, originator, payment initiator, ordering party buyer, etc. the global reference term is now ‘Debtor’. Now, regardless of the local synonym being used, any jurisdiction can easily understand what a ‘Debtor’ is and how it maps to their own local data model.
The messages defined in ISO 20022 are meant to simply define the set or subset of data items that could be included to complete a specific operation between two financial systems or two different entities within a financial ecosystem. Each jurisdiction can define its own domestic schemas of the data elements that are either required, optional or excluded from these messages. But, so long as you are assembling the required data into a message and those data elements can be correlated back to the ISO 20022 data taxonomy then it can be used successfully in any context.
The important thing to remember here is that these messages are purely transient. All of the systems in the financial industry have been designed to store data - not messages. While the data persists for decades, the messages only persist for seconds. When something like a credit transfer operation needs to be completed between two systems, the debtor assembles and sends a pacs.008 credit transfer message based on the agreed ISO 20022-based schema. That message is received by the creditor and immediately dissolved and dispersed into the internal data models based on its relation to the ISO 20022 data taxonomy per the following diagram:
At its core, ISO 20022 is meant to do just that: let the wide variety of data models across the global industry share data over different payment networks using a common message. ISO has provided the examples of these messages and the data to be included using both ASN.1 and XML schemas. While being bulky and verbose in format, these schemas provide an easy model that humans can read and understand. The problem with these example message schemas is that they cannot be utilized so easily by modern interfaces like APIs that prefer message format schemas based on JSON or other more compact schemas.
Iso 20022 Java Example
There is no requirement by ISO to utilize the XML message schemas that have been provided as examples for the actual messages to be created, in the actual message exchange between entities. Firstly, XML is not an ISO standard itself. It is a message format created by the W3C3. The same is true of the ASN.1 message schema examples that have been created – this message notation format is maintained by the ITU4. We need to be clear that while these are available message formats – these formats are not standards nor are they considered to be standards by anyone. Secondly, as long as the data contained within the message makes it clear which message it is and the recipient of the message can still extract the data elements and understand how that data maps from the ISO 20022 data dictionary to their internal data model consistently, then it should be considered a valid message format.
Iso 20022 Example Message
The XML and ASN.1 message schemas should provide the industry purely with a reference point for the content of any given message in each set of messages. Domestic and international markets can then freely work together to generate their own message schemas in alternate formats. As long as equivalent message formats whether they are created in JSON, BSON, Protocol Buffers, CDR, Bencode, or any other desired message format can be traced back to the ISO published XML schema example, it can be considered a success.
Iso 20022 Format Example
The industry has already generated several comments on the incompatibility of XML with modern API delivery mechanisms for ISO 20022 interfaces5. It is well known that there is a disconnect between the velocity of technology and the velocity of standards. While ASN.1 and XML-based messages are useless for delivering a high-volume real-time payments rail, the time it will take for the ISO standards body to define, agree to, and publish a third set of message schemas for a format like JSON, the tech industry will have already moved on from JSON to another schema format.
Iso 20022 Example C#
XML gives enough of a human-readable definition for reviewing and agreeing on the Mandatory/Optional/Excluded fields that we should be able to generate more machine-readable formats like JSON or Protocol Buffers schemas without requiring the ISO to have to publish new examples in every format that exists. Otherwise, ISO will get bogged down in generating nothing but message schemas and not progress the ISO 20022 standard. The ISO’s published XML schema can stand as the reference schema and allow the industry to define and agree upon alternate message format schemas as long as there is a published traceability of the data back to the original ISO 20022 data taxonomy. As long as the data content of a given message is consistent between those schemas and the relation between those schemas can be defined and correlated back to the original XML examples, then the solution will be whole.
Iso 20022 Sample File
Author
As a Principal Technology Architect at Payments Canada, Craig is responsible for providing technical expertise and oversight in support of our payments modernization initiatives. His interests include Blockchain DLT, Digital Identity, monetary policy, cryptocurrencies and financial services standards. Prior to joining Payments Canada, Craig worked in the private and public sectors as a senior technical consultant on diverse large-scale systems integration projects.
Iso 20022 Example Xml
1 The views presented in this paper are those of the authors and do not necessarily reflect the views of Payments Canada.
2 ISO 20022 Data Dictionary reference model https://www.iso20022.org/understanding_the_data_dictionary.page
3 World Wide Web Consortium (W3C) XML description https://www.w3.org/standards/xml/core
4 International Telecommunication Union (ITU) ASN.1 message notation https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
5 ACI’s Ramsey: APIs and ISO20022 are completely incompatible https://www.bobsguide.com/guide/news/2019/Apr/4/acis-ramsey-apis-and-iso20022-are-completely-incompatible/