Unraveling ISO 20022
The Universal Language of Financial Communication
Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace
As we move forward to unfold our series on real-time payment schemes, it's essential we first demystify the bedrock messaging standard that underpins these infrastructures. In this feature, we're going to take you on a deep dive into ISO 20022, setting the stage for a comprehensive exploration of real-time payments in our forthcoming series.
The modern financial ecosystem is teeming with complex processes and protocols that are essential for facilitating seamless transactions across borders. Among these protocols, ISO 20022 stands out as a global standard for electronic data interchange (EDI) between financial institutions. This comprehensive article delves into the origin of ISO 20022, its diverse use cases, the integral message types involved, and the critical fields one needs to consider.
ISO 20022 was conceptualized by the International Organization for Standardization (ISO), in collaboration with several other international financial standards organizations. Launched in 2004, it was devised as a universal messaging scheme to streamline global financial communication. By endorsing a common language for financial communications, ISO 20022 aims to surmount the barriers posed by disparate national and company-specific standards.
ISO 20022's use cases are expansive, encompassing domains such as payments, securities, trade services, cards, and forex. The messaging standard is used across various financial processes, from executing cross-border payments, to settling securities trades, processing credit card transactions, to facilitating regulatory reporting. Its versatility and interoperability have made it a preferred choice for new payment systems worldwide, including SEPA (Single Euro Payments Area) and the UK’s Faster Payments.
The messages involved in ISO 20022 are characterized by their structured nature, promoting interoperability and precision. These messages are classified into different categories, including Payments (pacs), Cash Management (camt), Securities (sese), and more. Each category consists of numerous message types designed to cater to specific business operations. For instance, under Payments, we have pacs.008 for customer credit transfer and pacs.002 for payment status reports.
While ISO 20022 messages comprise numerous fields, some hold pivotal importance due to their implications on the transaction. For instance, in a payment initiation message (pain.001), fields such as 'Message Identification', 'Payment Method', 'Requested Execution Date', and 'Creditor' are critical as they guide the payment's trajectory. In a statement message (camt.053), fields like 'Balance', 'Entry', and 'Transaction Details' hold key information about account transactions.
Additionally, the ISO 20022 framework allows for the inclusion of rich, structured data in payment messages. This is a remarkable upgrade from the limited information-carrying capacity of legacy formats. The 'Remittance Information' field, for instance, can include extensive invoice details, supporting automated reconciliation at the beneficiary's end.
File name structure and versioning
ISO 20022 message versioning follows a specific protocol designed to manage and identify the updates or changes to message standards over time. Each ISO 20022 message has a version number which indicates its evolution and modifications. These versions allow for backward compatibility and ensure that the changes do not disrupt existing systems.
To understand versioning, let's break down a typical ISO 20022 message identifier, such as "pacs.008.001.09", or “pain.001.001.03“ message typically used in request to pay setups.
"pacs" represents the business domain, in this case, Payments Clearing & Settlement.
The first "008" represents the message type within the domain, denoting a customer credit transfer message.
The second "001" is the version of the message type, signifying the first version.
Finally, "09" represents the revision number, indicating that this is the ninth revision of this message version.
When a new message is designed or an existing one is modified, it is issued a new version number. Minor changes lead to a new 'revision' while substantial changes result in a new 'version'. For example, a minor update to "pain.001.001.03" could result in "pain.001.001.04" (fourth revision of the first version), while a major update could lead to "pain.001.002.01" (first revision of the second version). Following you can see the list of message categories or domains:
acmt – Account Management
admi – Administration
caaa – Acceptor to Acquirer Card Transactions
camt – Cash Management
catm – Terminal Management
pacs – Payments Clearing & Settlement
pain – Payments Initiation
reda – Reference Data
seev – Securities Events
semt – Securities Management
sese – Securities Settlement
setr – Securities Trade
trea – Treasury
tsmt – Trade Services Management
tsin – Trade Services Initiation
It is essential to note that ISO encourages backward compatibility, meaning newer versions should not break the functionality of older ones. This allows organizations to transition to newer versions at their own pace. ISO also maintains all versions and revisions of its messages to ensure organizations can refer back to or use an older version if required.
Schema compatibility
Before we move into the next segment of our discussion, it's worthwhile to take a moment to revisit some key concepts that underscore the functionality of software message or API-based contracts in general. Specifically, we'll be focusing on understanding the principles of backward and forward compatibility - two essential considerations that greatly impact the evolution and adaptability of digital systems.
In an ideal scenario, we would prefer to have every component within a system operating on the same version, ensuring consistent functionality and seamless interaction. However, given the inherently distributed nature of payment systems and the multitude of actors involved - ranging from banks, payment gateways, to technology vendors and others - achieving simultaneous updates across all parties becomes a logistical challenge. Each actor may have their unique operational constraints, technological resources, and update schedules, which means that version upgrades across the system will inevitably occur in a staggered, non-synchronized manner. Therefore, it becomes crucial to maintain robust backward compatibility measures and have in place mechanisms to handle version mismatches, ensuring smooth operation of the system despite the diversity in component versions.
This diagram fully explains the difference between backward and forward compatibility.
Backward compatibility means that consumers with a newer schema version can correctly parse and interpret data from producers with an older schema version.
Forwards compatibility means that consumers with an older schema version can correctly parse data from producers with a newer schema version.
When a modification is designed to be both backward and forward compatible, it is termed as fully compatible. This scenario commonly arises when an optional field is introduced to an existing system. If a change in the schema or specification is neither forward nor backward compatible, then it is an incompatible change or a breaking change. In order to cope with this scenarios we can make use of the parallel change pattern. This pattern is a software engineering technique used for evolving a system in a manner that maintains its integrity and continuity. This pattern involves creating a new path or functionality while keeping the old one operational. In essence, it is running the old and new systems in parallel. The new functionality is added and used alongside the old one, with the system being capable of supporting both simultaneously. This approach allows for testing and gradual migration to the new system while maintaining operational stability. Let’s understand the pattern with some diagrams. The Parallel Change pattern unfolds in two stages: 'Expansion' and 'Contraction'. Initially, during the 'Expansion' phase, we seamlessly incorporate the new interface into the existing system. This allows the legacy functionality and the new behavior to coexist harmoniously. Once all system users have transitioned smoothly onto the new schema, we transition to the 'Contraction' phase. During this phase, we systematically eliminate the old behaviour from the system, ensuring a clean and efficient upgrade to the new interface.
Key Fields in ISO 20022 PACS Messages
The core essence of ISO 20022 message structure is characterized by its XML (eXtensible Markup Language) nature. XML, being both human-readable and machine-readable, is specifically designed to encode documents and serialize data, making it well-suited for messages interchange between computers and systems. An XML-based framework ensures that ISO 20022 messages can be easily interpreted by any system that follows the standard.
In the Payments Clearing and Settlement (pacs) messages domain of ISO 20022, the most essential fields often include: Message Identification, Creation Date and Time, Interbank Settlement Date, Number of Transactions, Total Interbank Settlement Amount, and Debtor and Creditor details.
The Debtor and Creditor details typically include: Name, Account (Identification, SchemeName), Agent (Financial Institution Identification, Branch Identification). These identify who the money is coming from (debtor) and who it is going to (creditor), including their respective accounts and banks.
Here is a simplified example of how these fields could appear in a pacs.008 XML sample document:
<pacs.008.001.09>
<MsgId>1f9d1733-e037-4c64-96e1-d802ab1fdeb2</MsgId>
<CreDtTm>2023-07-07T13:33:33Z</CreDtTm>
<NbOfTxs>1</NbOfTxs>
<TtlIntrBkSttlmAmt Ccy="EUR">1000</TtlIntrBkSttlmAmt>
<IntrBkSttlmDt>2023-07-08</IntrBkSttlmDt>
<Dbtr>
<Nm>John Doe</Nm>
<Acct>
<Id>DE23500105172368482343</Id>
<SchmeNm>IBAN</SchmeNm>
</Acct>
<Agt>
<FinInstnId>DEUTDEFF</FinInstnId>
</Agt>
</Dbtr>
<Cdtr>
<Nm>Jane Smith</Nm>
<Acct>
<Id>ES6931901162114179529978</Id>
<SchmeNm>IBAN</SchmeNm>
</Acct>
<Agt>
<FinInstnId>BBVAESMM</FinInstnId>
</Agt>
</Cdtr>
</pacs.008.001.09>
In this example, John Doe is transferring 1000 EUR to Jane Smith, and their respective bank identifiers are also included in the message.
ISO 20022 is recognized for its numerous identifiers and reference fields that play crucial roles in streamlining payment processes. In order to provide an in-depth understanding of these components, we plan to dedicate an entire segment of The Engineer Banker to unpack the meaning and significance of each identifier and reference field within the ISO20022 standard.
In the context of ISO 20022, real-time payments represent a specific subset of the broader standard, with its own defined messages and processes, geared towards facilitating immediate, 24/7/365 payment transactions. The ISO 20022 Real-Time Payments Group (RTPG) has developed a universal 'real-time payment message set' to address this need, including payment initiation, receipt, reporting, and related interactions. These messages are designed to be flexible, adaptable, and interoperable, supporting various domestic and cross-border payment systems worldwide. However, it's crucial to understand that while these real-time payment messages form a distinct subset, they are inherently integrated within the overarching ISO 20022 framework. This means that they are designed to work in harmony with other message types and services within the ISO 20022 ecosystem. This allows for a seamless transition between real-time and non-real-time payment environments, contributing to the standard's overall versatility and comprehensive nature. When it comes to specific real-time payment infrastructures like FedNow or RT1, each will make its own determinations about which fields are essential and how they correspond to the use cases in question. These decisions are made based on the individual needs and design requirements of each system. The objective is to ensure that these fields provide the necessary functionality and efficiency to meet the unique demands of their specific real-time payment environments.
ISO 20022 Adoption
The adoption of the ISO 20022 standard has seen a dramatic rise across several payments systems worldwide, reflecting the global financial industry's intent to harmonize communications and improve interoperability. To this end, numerous payments systems are currently either undergoing or have recently completed their transition to ISO 20022.
In the United States, the Federal Reserve and The Clearing House are progressing with their migration plans. The Clearing House's Real-Time Payments system (RTP) is fully ISO 20022 compliant, and the Fed's new FedNow service, due to launch in 2023, will also be based on ISO 20022. Both organizations are working closely to coordinate the migration of their high-value payment systems.
In Europe, the Single Euro Payments Area (SEPA) adopted the ISO 20022 for credit transfers and direct debits as early as 2014. The Eurosystem's TARGET2 and EBA CLEARING's EURO1 are now transitioning, aligning their migration plans with SWIFT's.
The migration is in progress in the UK as well, where the Bank of England's CHAPS system has recently adopted the standard. In addition, the New Payments Architecture (NPA), which will change how Bacs and Faster Payments operate, will also employ ISO 20022.
In Asia, the Bank of Japan's BOJ-NET and the Hong Kong Interbank Clearing's HVPS+ have already transitioned, while the Reserve Bank of India's RTGS is currently migrating.
Australia's New Payments Platform is a another example of a system that was built from the ground up using ISO 20022, showing the standard's rising importance in the design of next-generation payments systems.
As the adoption of ISO 20022 gains momentum, the financial industry is set to reap the benefits of improved efficiency, interoperability, and richer data, leading to more effective compliance and better customer service.
Therefore, ISO 20022 significantly contributes to the harmonization of global financial communications, thus enhancing interoperability between different payment schemes. It is a universal standard for financial messaging that encapsulates a comprehensive data dictionary and a robust modelling methodology. These features allow it to offer a common language and model for payments data across the globe. Its flexibility allows it to be implemented across different platforms and systems, while still maintaining a consistent structure. Consequently, when payment schemes adopt ISO 20022, it becomes easier to exchange detailed and structured information across different systems. This interoperability paves the way for improved efficiency in cross-border payments, reduced transaction costs, and increased speed of execution. It also enhances transparency and traceability in payment transactions, thereby aiding in compliance with regulatory requirements and reducing risks associated with money laundering and fraud. By streamlining financial communications globally, ISO 20022 plays a pivotal role in creating a more integrated global payments ecosystem.
Interoperability between payment systems
Interoperability between payment systems or schemes refers to the ability of different systems to interact seamlessly with each other, enabling the successful exchange and processing of payment instructions. Here are the major types of interoperability:
Technical Interoperability: This pertains to the compatibility of technical infrastructures, systems, and protocols between different payment schemes. It includes aspects such as communication protocols, security mechanisms, data formats, and software compatibility.
Semantic Interoperability: This involves ensuring the data exchanged between systems is correctly understood by all parties. Semantic interoperability is critical when dealing with international transactions where the meaning of data must be preserved across different systems, languages, and cultures. The ISO 20022 standard plays a key role in promoting semantic interoperability by providing a universal financial language.
Business Process Interoperability: This refers to the harmonization of business rules, processes, and procedures between different payment schemes. It involves coordination of business operations like transaction routing, reconciliation, clearing, and settlement processes.
Legal and Regulatory Interoperability: This pertains to the alignment of legal and regulatory frameworks across different jurisdictions. It includes aspects such as contractual arrangements, risk management frameworks, compliance with AML/CFT regulations, privacy laws, and other relevant legislation.
By addressing these various layers of interoperability, payment schemes can create a more connected, efficient, and resilient global payments ecosystem.
As an example, The EBA CLEARING’s RT1 system and the Eurosystem’s TARGET Instant Payment Settlement (TIPS) are two of the key real-time payment systems operating in the European Union. Both of these systems handle instant payments in euro, allowing for money to be moved between accounts in a matter of seconds, any time, any day. Business process interoperability is achieved through the alignment of business rules, transaction routing procedures, settlement processes, and other operational aspects between the two systems. Both systems are compliant with the SEPA Instant Credit Transfer (SCT Inst) scheme, ensuring uniform business processes.
Technical interoperability is secured through the use of common messaging formats and communication protocols, such as ISO 20022 for payment messages, ensuring that instructions sent from RT1 are correctly received, understood, and processed by TIPS. This interoperability helps facilitate seamless, near real-time transfer of funds between RT1 and TIPS participants, enhancing the reachability of the overall SEPA Instant landscape in the European Union.
By embracing this universal language, financial institutions worldwide are set to drive significant advancements in global transaction processing, data quality, and customer experience. As ISO 20022 continues to evolve, it's clear that its implications will extend far beyond the realm of messaging standards, forming the backbone of next-generation financial infrastructure.