ISO 20022 – Le format n’est PAS le message
AVERTISSEMENT : Les articles reflètent les intérêts et les opinions de leur auteur et ne sauraient constituer des déclarations ou des prises de position officielles de Paiements Canada.
Résumé1
La norme ISO 20022 est le fruit de plusieurs années de travail à l’échelle mondiale pour uniformiser la langue des services financiers, quels que soient le territoire et les spécialités régionales.
Ce document de réflexion porte sur certains des problèmes que pose la mise en œuvre d’interfaces basées sur la norme ISO 20022 et propose diverses approches de concertation sectorielle pour les résoudre. L’évolution des technologies ayant définitivement pris le pas sur l’élaboration de normes, il faut élaborer un modèle pour que le secteur puisse appliquer les nouvelles technologies sans devoir attendre les organismes de normalisation de l’ISO, car ils peuvent prendre des années pour concevoir des formats de messages condamnés à la désuétude dès leur publication. Sur le plan technique, il faut suffisamment de souplesse pour que l’application de normes, comme les API, puisse se faire rapidement dans de nouveaux formats, dans la mesure où l’on peut remonter aux exemples publiés par l’ISO.
La suite de cet article est en anglais seulement.
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.
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.
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.
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.
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.
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.
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/
