What is the ISO 20022 standard?
ISO 20022 is a global financial messaging standard that will standardize the data structure for financial messaging for today’s real-time payments world. ISO 20022 will deliver a new rich-data format for payments, empowering organizations to share information across a variety of financial services applications and allow for the development of digital overlay services. ACI can support institutions in its migration to ISO 20022 with a variety of solution options.
Why use ISO 20022?
There are many benefits to the new ISO 20022 messaging standard. First and foremost, the rich data provided enables banks to create and deliver better experiences for customers. This also allows for improved fraud prevention and greater compliance with anti-money laundering (AML) regulations.
ISO 20022 will also support banks in reducing manual investigations and improving straight-through processing (STP) rates. Banks can also improve the high-value services offered to global customers.
Ultimately, banks have to migrate to ISO 20022 as the payment networks they leverage for their business evolve to this new standard.
What is the difference between SWIFT MT messages and new ISO 20022?
ISO 20022 messaging will allow for data-rich transmissions not previously possible with legacy formats (used by SWIFT, SWIFT-like schemes and domestic schemes). The messaging standard will include a new XML format, with greater data volume and a much more granular, interface-friendly layout. The data will also be more structured and feature a record of data along a payments chain.
What is the ISO 20022 equivalent of an MT103 message?
All high-value payment schemes (SWIFT, SWIFT-like schemes, pan-regional schemes and domestic schemes) converting to ISO 20022 are typically using the same message types to address their payments – PACS.008, PACS.009, PACS.004, PACS.002 and a handful set of CAMT.xxx message types.
To directly answer the question asked, plus more, the ISO 20022 Customer Transfer message type PACS.008 is the equivalent of an MT103.
Even though the question was asked about MT103, it is worth noting the answer for a Bank-to-Bank Transfer PACS.009 is the equivalent of an MT201, MT202, MT202 Cov, MT203 and MT205.
To conclude the thought, a return (whether Customer Return (MT103 Return) or Bank Return (MT202 Return)) and then a PACS.004 is used, with some granularity distinction noted in the payload of the data.
Is it enough to convert from MT to XML?
The question was asked in the context of using SWIFT message formats, but the question is applicable to any scheme moving from its legacy format to ISO 20022.
Using a basic convertor can provide connectivity by getting the data between two systems, but a converter will ensure neither compliance nor the intended interface-friendly usage.
To elaborate from the former paragraph, a convertor limits the granularity of data passed and how it is passed. When going from ISO to legacy, at some point truncation will be required. On the outbound side, in most cases, free-form data will be mapped to the ISO freeform fields instead of the ideal granular ISO-equivalent fields. Moreover, since legacy formats can’t handle the exponential amount of data, hence truncation on the inbound path, much data is almost certainly not going to be passed on the outbound legacy engines.
Which payment types are moving to ISO 20022?
The ISO message type is relevant to Customer Transfer Messages (e.g., PACS.004 and PACS.008), Bank Transfer Messages (e.g., PACS.004 and PACS.009) and associated Reports (e.g., PACS.002 and CAMT.052).
Do banks need to be able to receive or send ISO 20022 messages?
Banks must be able to both send and receive ISO 20022 messages to not only remain compliant with network and system updates, but also to continue transacting on behalf of their customers. This is especially true of correspondent banks that must be able to pass the structured, enriched data to the next party in the chain, as well as receive new ISO 20022 messages from across their global network of partner financial institutions.
Is migrating to ISO 20022 mandatory?
There is no regulation that forces banks to migrate to ISO 20022, but at a payments system level, the operators are setting deadlines for the switch over to the new standard. While some schemes are mandating the new ISO 20022 standards, others have coexistence timelines. SWIFT, for example, is doing a “migration” approach, where there will be a coexistence of both FIN and ISO 20022, but should an FI&I send an ISO 20022 message, then one must be able to receive and pass that ISO 20022 along on any redirected message.
Even if a bank doesn’t have to manage a domestic or national payments scheme shift to ISO 20022, it still must contend with the global shift and the impact on its correspondent banking business.
What is the timeline for ISO 20022 migration?
SWIFT announced a revised migration deadline of November 2022. Schemes in the U.S. and U.K. are now staggering their deadlines to allow banks to achieve compliance with a sense of calm, against more imminent deadlines from SWIFT, Canada, the European Central Bank (ECB) and Euro Banking Association (EBA) in November 2021.
Australia and New Zealand have yet to announce a definitive deadline for ISO 20022 migration, but November 2022 is being discussed.
How long does it take to migrate to ISO 20022?
A typical migration timeline can run anywhere from nine to 12 months, depending on the partner and solution. ACI’s ISO 20022 Translator will ensure compliance against the various deadlines, all while giving the ability to manage and leverage the rich ISO data, plus allow the customer to migrate all of its various systems to ISO 20022 on its own smooth, controlled and low-risk timeline.
How can banks migrate to ISO 20022?
Contrary to popular belief, the migration to ISO 20022 does not require a “rip and replace” of legacy systems. ACI is enriching its existing ISO 20022 support, plus leveraging other UP Real-Time Payments solution’s natively ISO 20022-built components.
For financial institutions wanting to protect their existing engine and numerous back-office systems, ACI offers a point solution (yet still very strategic) called ACI ISO Translator. The ACI ISO Translator fits within financial institutions’ existing ecosystem and can help with its long-term payments modernization strategy by allowing it to migrate in a controlled low-risk timeline.
Lastly, should a financial institution want to replace its existing engine, since the ACI ISO Translator is comprised of components in ACI’s UP Real-Time Payments strategic solution, the same financial institution can simply extend the footprint and seamlessly upgrade to ACI’s real-time payments hub.
What kinds of rich-data services are possible with ISO 20022?
The rich data provided by ISO 20022 opens a world of possibilities, from helping banks apply artificial intelligence (AI) to financial advice, to speeding up the automated reconciliation of invoices.
The growth of alternative payment methods will also be enabled by ISO 20022. The rich data captured will allow forward-thinking banks to better incorporate and deliver on these payment types.
Which payment schemes/systems are already using ISO 20022?
SWIFT has supported ISO 20022 for some time now, called SWIFT MX. SWIFT MX is optional and uses a different set of ISO 20022 rules. As of September 2019, there have been 10 high-value payment schemes live on ISO 20022. China’s CNAPs and Japan’s NET are just two examples.
Of course, there are a tremendous number of ISO 20022-based instant payments systems live around the world.
Is it a case of SWIFT gpi vs. ISO 20022, or SWIFT gpi and ISO 20022?
SWIFT gpi and ISO 20022 are separate initiatives, but can open the door to real-time payments and a host of new value-added services, especially when high-value payment schemes go to ISO 20022. Given most instant payments schemes are ISO 20022-based, there is friction in translating the message to and from the legacy high-value payments system. When the high-value payment schemes migrate to ISO 20022, much of that friction will be removed and it will become almost seamless for a financial institution to leverage both high-value and instant payments schemes. SWIFT gpi Instant is a payment with three features:
1. The payment can be domestic or cross-border, but it must be sent via a high-value payments scheme
2. The payment must be marked as a gpi Credit Transfer
3. The payment should originate and/or settle into a local instant payments scheme
When the instant payments scheme gives the originating financial institution the response, the originator returns a response to the recipient so the other financial institution is notified of the outcome.
What’s the impact of ISO 20022 on Universal Confirmations?
For many smaller financial institutions, where adhering to the level of SLA required under SWIFT gpi is not feasible, a smaller scope of messaging types and a lower-level response time mandate is being implemented. This is called Universal Confirmations. Only customer transfers are required to provide a response to the SWIFT Tracker, and the response has a slower SLA response time.
This task is not really related to high-value payment schemes migrating to ISO 20022. The impact is on Credit Transfers (MT103 migrating to PACS.008).