What is ISO 20022?
Financial institutions need to exchange a massive amount of information with their customers and between themselves to conduct their businesses. Such exchanges only work effectively if all parties to a transaction share a common understanding of interpreting and processing the information. ISO (International organisation of Standards) creates that common language and model for payments data across the globe.
ISO 20022 is the new global language for payments, helping make the quality of data richer, structured and more meaningful.
Why is ISO 20022 critical?
Considering the pace at which the world is changing and how small it is becoming, as a virtual space, financial institutions need to keep pace through digital innovation. Even if a financial institution doesn’t have a global presence, it will still interact with numerous parties daily and quickly. In relation to the movement of money, these parties will include correspondent banks, corporate customers, and other financial infrastructures and communities. In a world in which banks are competing and collaborating with FinTech’s, emerging platforms and new business models, it is imperative for everyone “to speak” the same “language” so that new services can interoperate with the old safely and securely.
Quality data is the key to safety and security. Unfortunately, today’s movement of money is adversely affected by flawed information – often reducing the efficacy of our control capabilities. SWIFT data shows that more than 70% of payments from originating parties use unstructured fields to capture critical originator and beneficiary details. While unstructured fields provide flexibility and, arguably, ease in initiating payments, they also make the job of adhering to financial crime regulation commensurately more difficult. ISO 20022 formats provide a framework for structured and richer data, thereby reducing the risks inherent in poor quality data, whilst promoting best practices end-to-end.
[70 countries have already adopted ISO 20022 to replace domestic or legacy formats – so migration is a necessary reality.][format as infographic]
What are the opportunities?
The main objective of the ISO 20022 framework is to create a globally connected financial world where risk-bearing information flows seamlessly between systems and jurisdictions.
In addition to enabling new client experiences, the availability of more meaningful data, such as better structured reference information, will provide the community with the opportunity to change and improve post-trade reconciliation and settlement processes:
- There will be more options available to automatically determine transactions that match – vital to achieving enhanced straight-through-processing (STP), i.e. processing without manual intervention.
- Richer data will provide even more opportunities for artificial intelligence (AI) and machine learning-powered reconciliation systems to identify possible matches correctly. Thereby reducing the number of matching and reconciliation errors, ensuring manual investigation is kept to a minimum and focused on genuine breaks.
- The availability of richer and more structured information will enable innovations, yielding new services for the benefit of customers and providers alike.
Once the critical payment systems have migrated to ISO 20022, approximately 80% of transactional volume worldwide will be utilising the new standard.
Available Today: Payments, Funds, Securities and Trade
ISO 20022 organises financial message definitions in business areas – well recognised functional domains in the industry. These business areas are uniquely identified by four-character codes called business area codes. Some examples include:
✓ pacs: Payments Clearing and Settlement
✓ pain: Payments Initiation
✓ camt: Cash Management
✓ setr: Securities Trade
✓ sese: Securities Settlement
✓ acmt: Account Management
✓ tsmt: Trade Services Management
Messages are also available for the peripheral functions and activities that support the movement of money, such as payment exceptions and investigations, bank account management, and direct debit mandate management. The coverage is continuously expanding, driven by industry requirements.
ISO 20022 is the future of payments, but what are immediate short-term implications?
The approach to adoption varies, with one of two models leveraged:
- A one-step, or “big bang”, migration;
- A multiple-step, or “like-for-like”, migration (where data fields and messages are gradually moved over). Even for a multiple-step approach, there are various adoption strategies for migration.
Whether you’re a corporate or a bank, a market infrastructure, or a trade organisation, the same terminology, is being used consistently across the ecosystem.
A migration to ISO 20022 for the entire global banking community is scheduled for November 2022, following a 12-month delay to allow institutions more time to prepare and implement the necessary changes.
There will be a further three years for companies to get ready for the messages (payments and clearing & account management) to be decommissioned in 2025. From November 2022, SWIFT will extend its platform to provide transaction management services. One of them is a mechanism to intermediate between institutions as they gradually move from legacy messaging protocols to ISO 20022, a journey that will be complete by November 2025.
** JDX will explore the adoption strategy from bank’s perspective in a separate article in our series **
Few Short-term implications.
- Operational considerations: This migration doesn’t only affect IT systems, it impacts business rules, and process flows as well. Hence, special attention required for business operating models, i.e. payments processing flows and exception handling, which represents a significant challenge.
- Impact beyond payment processing: The migration will reach far beyond core payments processing. It will affect peripheral systems such as anti-financial-crime applications (especially embargo/sanctions screening and AML systems), liquidity management, billing, account reporting, Nostro reconciliation and archiving systems.
- Difference in options and recommendation: Options and recommendations vary based on the level of involvement with the organisation’s payments. For instance, a bank with a global footprint will have a different approach to a bank that has a smaller regional focus. Similarly, the process will be different if a bank is a direct or indirect participant in payment creation and processing. (We will explore this further in future articles in our series.)
Jurisdiction and timelines for migration:
For banks and financial institutions, the timeline is quite eventful.
- Euro systems are moving to ISO 20022 in November 2022.
- UK CHAPS, high-value payment system moving the first half of 2022.
- The dollar systems Fedwire and CHIPS are moving November 2023.
- And in between all that Canada, Australia, Singapore, Hong Kong, and many other communities looking to move to ISO 20022 in the same timeframe.
That’s a complex change roadmap for everybody. There is a SWIFT coexistence period to try to facilitate that change in cross border payments. The challenge is to ensure that this is being done efficiently and in the least disruptive way.
Making Coexistence Work:
Now the obvious question is, what is Coexistence?
Coexistence, in this case, means that more than one message format is used at the same time in the communication flow for a business process.
A Coexistence approach enables ISO 20022 standards to deliver enriched data elements to participants receptive to the change while, simultaneously, allowing other participants to continue with the previous format standards.
When the migration starts in November 2022, users of both Swift MT (legacy format) and ISO 20022 message formats must be able to interoperate. Consequently, between now and then, i.e. ready for November 2022, financial institutions will need to ensure their interfaces are prepared for the coexistence period.
The coexistence period will allow organisations to incrementally enable interoperability, if they’re operating in multiple jurisdictions, at their own schedule. SWIFT will provide the tools for these measures. Implementing organisations can use SWIFT translation services to translate to standard messages and exchange might include both (MT and ISO 20022) depending on the services being used. If your counterparty is not ready, SWIFT will translate for them using its central transaction management system.
From Coexistence to Interoperability:
Financial institutions have their own formats to store information and exchange it between applications. This information can then be mapped to whatever format is necessary for the outside world. And even when the external format changes, FIs often used to continue the old version internally and map it to the new format before sending it out. Typically, FIs find this cheaper to map/ transform the information to and from the new format than to change their legacy application. This is where interoperability comes into the picture with the ability to map different messaging standards. Classic, e.g., is from MT103 to Pacs.008 – both are Single Customer Credit Transfer.
Granularity of information details shown below:
Source: SWIFT Standards
Along with the finalisation of SWIFT standards over the past few years, various ISO 20022 usage guidelines have also been developed. Most importantly for High-Value Payments Plus or HVPS+, (in the one-to-many space), Cross border payments and Reporting or CBPR+ (in the many-to-many space). Each set of guidelines contains similar but unique complexities with which market participants will need to familiarise themselves.
Used predominantly by Market Infrastructures (MI), the HVPS+ usage guidelines were developed by SWIFT for the six core message types: pacs.008(FI To FI Customer Credit Transfer), pacs.009 (Financial Institution Credit Transfer), pacs.004(Payment Return), pacs.002 (FI To FI Payment Status Report), camt.029(Resolution of Investigation) and camt.056 (FI To FI Payment Cancellation Request). At the time of their creation, SWIFT decided that the guidelines would not be validated on the SWIFT network, allowing each MI to comply with the HVPS+ and apply their own restrictions or essence to it. Therefore, banks will need to ensure they comply with various versions of HVPS for the respective MIs with whom they have partnered.
For use in correspondent banking, an additional set of guidelines, known as the CBPR+, were drafted, establishing global ISO 20022 Market Practice guidelines and translation rules for selected SWIFT MT category 1,2 & 9 messages. The guidelines cover pacs ( Payments Clearing and Settlement), pain (Payments Initiation), and camt (Cash Management) message types. Unlike the HVPS+ guidelines, CBPR+ will be validated on the SWIFT network and be interoperable with HVPS guidelines.
The slight differences between the two usage guidelines have several potential implications for all market participants. For example, a payment sent to an MI will use pacs.008 based on the HVPS+ usage guidelines, yet once it is passed on to a correspondent bank, it will use the CBPR+ usage guidelines. Therefore, banks will need to ensure that they understand both approaches and “speak” all the “languages” of ISO 20022.
The CBPR+ migration timeline has been moved out by a year, to November 2022, to accommodate the many market participants preparing new and existing infrastructure for the transition.
** HVPS+ guidelines and the CBPR+ handbook is published on SWIFT’s website for reference.
ISO 20022 with API (Application Programming Interface):
APIs, APIs and APIs. What is an API?
We are constantly hearing about the increase of API use for ISO 20022 for Tier 1 banks and the new players rising in the market. The main drivers for using these are the various payment initiatives around the world. The simple rationale for using APIs is that they are a smooth, lightweight and easily configurable interface. The simple and main benefits are that it is cheaper, on-time, easier to use and easier to maintain. These benefits are something which all key players in the market would want to achieve.
Think of API as a product. It represents something we have chosen to share with an audience under a defined set of terms and conditions”. In technical terms, it is a software intermediary that allows two applications to talk to each other and deliver the response for the request.
A real-world, daily life example of an API is the weather information displayed on our smartphones. Google utilises an API to send a request for the data and to receive a response to display that information. There are many daily life examples of APIs, e.g. request on a coffee machine, logging on to our social networking profiles, payment via PayPal etc.
** An essential article covering APIs for ISO 20022 will be published in a separate article in our series **
An FIs testing strategy will significantly depend on its migration approach to ISO 20022, especially which market infrastructure it operates within.
For instance, for those FIs working with the ECB, they published their T2 Migration, Testing and Readiness Strategy, in February 2020. The document was published by the Migration Testing and Readiness Subgroup (MTRSG) of the TARGET Services Working Group (TSWG), and elaborates a migration, testing and readiness strategy for T2 intending to ensure a smooth transition to the new T2 service:
It outlines that there will be three different stages of testing, respectively: the Euro system Acceptance Testing (EAT) stage, the Central Bank Testing stage (CBT), and the User Testing stage (UT), including relevant testing phases for connectivity, interoperability, community, migration testing and the testing of the interrelations with local central-bank services and ancillary systems.
Before starting the testing, the ECB, national central banks and T2 participants will be granted sufficient time to establish connectivity for testing. Also, Participants FIs that do not need to wait for SWIFT readiness for testing as a small sandbox is set up by SWIFT where customers can begin testing. They can start generating these new messages in their systems, and sandbox upload them. The sandbox will tell them whether the ISO 20022 message is compliant. Also, to implement stop-gap translation tools are available. Testing for participants can be completed in phases i.e.
- Locally / Internally (Using sandbox, translator services)
- End to End testing with other FI participants, i.e., Market Testing.
- With Market Infrastructure (Connectivity to be established from both ends)
** we will publish a detailed overview of testing strategy in a separate article in our series **
SWIFT’s new Migration Approach incorporating Transaction Management:
The latest developments began in March 2020, when SWIFT announced a revised strategy centred on introducing a central Transaction Manager (TM). The TM will provide end-to-end orchestration of transactions and allow the industry to move away from point-to-point messaging and towards central transaction processing.
The core of the new strategy is the Transaction Manager. It will hold a master ‘transaction copy’ and orchestrate a transaction from sender to receiver, fundamentally changing the processing and communication of messages for participants in a payment. Put simply, consider this as the next logical version of SWIFT GPI, which has provided end to end transparency for cross border payments and more recently domestic schemes with the introduction of SWIFT ‘gpi instant’.
Translations – To intermediate between the different messaging formats, the TM will provide coexistence measures to ensure banks can use the standard of their choice for transactions. Banks will be able to send and receive transaction information via MT, MX and API formats.
Sanctions: Fulfilling the compliance obligation for every agent is NOT changing. With the introduction of the new platform, if the original payment transaction is based on ISO 20022, intermediaries using the MT channel will have three options to sanctions-screen the data. Three ways depicted in the below diagram:
This new standard unlocks unprecedented opportunities for the payments community. Enriched and structured data will enable richer customer experiences and ensure better compliance. At the same time, standardisation will improve interoperability, open the door to further innovation, and provide opportunities for developing new revenue streams.
This publication is the first in a series that JDX is publishing to advise our clients around ISO 20022 adoption. Each publication looks at ISO 20022 adoption from several different aspects and perspectives, including implementation and testing strategies, the potential use of APIs and the new commercial opportunities that will arise through adopting the framework and standards.
The next publication will focus on the various approaches a bank could undertake to deliver ISO 20022 strategically. We will explore several strategies, covering time to market, infrastructure and operational costs, data integrity and compliance. As a snapshot, banks can approach their ISO 20022 adoption strategy from one of three broad categories outlined below. Banks should be approaching ISO 20022 adoption through a strategic and commercial lens that focuses on transforming and enhancing existing processes and technology for commercial benefit.
1. Full Migration – Each system within a banks payment processing chain is upgraded to accept, process and send ISO 20022 format messages natively.
2. Simple Translation-Translation tools transform inbound messages into their MT equivalents and outbound messages into their ISO counterparts, while underlying payment and reporting systems remain mostly unchanged.
3. Bridged / Linked Translation– Underlying payment systems remain largely unimpacted, and messages are translated from MT to ISO formats and back. Overflow information from inbound messages is stored to be restored and reintegrated into the corresponding outbound messages.
For further information on how JDX can help with your ISO 20022 adoption implementation, please contact our Movement of Money practice lead, Michael Levens.