ISO20022 is a new standard for communication between financial institutions. All financial institutions in the world talk to each other through local, regional, or international networks and clearing systems. For such communication, they have to adapt by the communication protocol and interface mandated by this network or clearing system. ISO20022 introduces a standard format for such communication, and a structure based on XML, with an agreed-upon dictionary for the semantics of the content of the messages to avoid confusion and multiple interpretation as much as possible.
As for SWIFT messages between banks, the usual ISO15022 is used (the MT messages). SWIFT was planning the move to the new standard in November 2022 through its CBPR+ program (Cross-Border Payments and Reporting). However, it was recently moved to March 2023.
For Europe, clearing systems based on TARGET2, which is the foundation for the different types of payments in SEPA, is currently using the same SWIFT protocol (ISO15022). The migration was planned in November 2022 but moved as well to March 2023.
Since SWIFT is the program Registration Authority, which is like the moderator of the worldwide migration on behalf of the ISO organization, a lot of information on the specs, dictionary, use cases..etc, can be found in this link at swift.com.
Benefits of ISO20022
Benefits are around better interoperability between the financial institutions, and the flexibility it provides inside the new format. Main use cases fall under the following categories:
- Better reconciliation for merchants: If a merchant or supplier receives a payment from a customer, customer is always asked to add something like reference/order number/invoice number to the payment description. When the merchant receives the settlement file from the bank or the PSP with all the payments details, the merchant matches the orders or invoices numbers with the reference numbers in the description of the payments to identify which orders or invoices are paid.
This can be easy in the case of one payment per invoice. However, for the case of one payment for multiple orders or invoices, things get more difficult. ISO20022 through its structured format provides the needed fields to add more than one reference number and purpose to the same payment, with the amounts breakdown, which means the reconciliation will be faster and easier to automate.
- Fraud detection: With a solid structure and semantics in the payment transaction, false positives can be much reduced. For example, in the old MT format, a payment can be rejected just because the creditor name has “Cuba” in his/her name. In the new standard, there is a well defined structure for the address of the financial institution.
- More analytics and spend management control: Adding more analytics on top of this structured format, with fields like “Purpose” can make it much easier to build value-added applications, like PFM (Personal Finance Management) applications or upselling products to the bank customers.
The New and Old Formats
Below is an example of how the debtor (the entity that sends the transferred money) can be described in the old MT (ISO15022) format in SWIFT and in the new MX (ISO20022) format.
The example below is part of a pacs.0008 message for customer credit transfer in ISO20022 and how it compares to the MT102/103 message in ISO15022. Other relevant types of messages are pacs.002 for payment status reporting, camt.05x for reporting and notifications.
The Payment Hub
If you are a bank, as a member/participant of SWIFT or TARGET2, and you need to migrate to ISO20022 before March 2023, the main component in your architecture that needs to be migrated is the payment hub. The payment hub is the component that receives the different payment messages from the different networks and clearing systems like SWIFT and TARGET2, and does the needed vetting for the transaction, and either process it locally in the bank system as an (on-us) transaction, or forward the transaction to the relevant destination network or clearing system, to be routed to the destination bank at the end.
Below is a context diagram on how the payment hub is placed with respect to the clearing systems and other systems in the bank.
Some examples for payment hubs products in the market are IBM Financial Transactions Manager, Finastra Fusion Global PayPlus, and Fiserv Enterprise Payments Platform.
A Closer Look on Integration
In the diagram below, we can see as an example the flow for a credit transaction, received from SWIFT. This means that the money is transferred to the person’s or organisation’s account in this bank.
Usually integration with such systems is async. Which means for every type of message, there is a queue for the payment hub to receive the request message on, and another queue for the payment hub to put the response or status message on. There has to be some ID in the message for the consumer to correlate the response with the request.
- The payment message with credit information is received from SWIFT on the queue assigned to this by the payment hub. This is a pacs.008 ISO20022 message.
- The payment hub has to validate the message, so it first asks the fraud detection and screening system if the transaction is a valid one or not. Here the communication is using a format mandated by the payment hub or by the fraud detection system.
Usually, the queues are part of an ESB (Enterprise Service Bus) with translation flows to translate between the payment hub domain format and the fraud detection domain format. After validating the transaction, the fraud screening system responds with an OK message on the response queue. - Same happens to check on the sanctions screening on creditor and debtor entities and countries. The sanctions screening system will respond with an OK message on the response queue. Again, these are not ISO formats, but formats of the screening and payments hub systems.
- If all is success, the account of the creditor entity has to be updated to post the transaction to it in the core banking system. Also, using translation between the two domain formats.
- The payment hub in some cases has to report back the status of the transaction to the clearing system/network using an ISO20022 pacs.002 status reporting message. This is required for SWIFT CBPR+, but not for TARGET2.
Initiating a Transfer from the Digital Bank
A payment debit transfer or transaction can be initiated by the customer, as we see at the top of the diagram. The customer using his mobile app or by calling the call centre can initiate a remittance from his/her account to a destination account. A similar flow to the above one will be initiated but here the customer’s bank will act as the debtor agent in the transaction, which means the financial institution sending the message to SWIFT and then to the creditor agent (Bank).
There is a complete integration layer to provide the digital banking capabilities, usually on microservices. One of these capabilities is to interact with the payment hub to initiate transfers, but first to convert the sync API calls (from the mobile app) to the needed async messages submitted to the systems of record, with the needed business logic. Such a layer is the main foundation for the digital banking or neo banking capabilities on top of the existing banking infrastructure.
Retail and Card Payments
The payment hub and ISO20022 is mainly around remittance or FI (Financial Institution) to FI transfers. Cards payments is a different story that follows a different flow in the grey area at the bottom of the diagram. This is through a different system, the ATM or payment switch, which manages the interface with the ATMs and PoS on one side, and with the card networks on the other side, as we explained in previous posts. It will still need to interact with the bank existing systems to validate and post the transaction.
Markets Migration Strategies
It is interesting to see how the markets are following different strategies for the migration to the new standard.
Some markets like TARGET2 in Europe will follow a big bang approach. This means during a weekend in November 20022, or now in March 2023, the platform and all the financial institutions will migrate.
On the other hand, SWIFT will support a duration of coexistence for both MX and MT systems. This is using their “In-Flow Translation” system, which translates from MT to MX and vice versa. Therefore, financial institutions that didn’t migrate yet can still transact on ISO15022 for a grace period of three years.
To another post.