According to my colleagues in research at Accenture, global card transaction volumes are in the region of 206 bn txns per year and growing, while global interbank payment volumes are roughly 108 bn txns per year, also growing. Real-time interbank payments are starting to appear in countries around the world, and will add to these figures.
Card transactions almost universally use the ISO8583 standard. This uniformity and ubiquity are a remarkable achievement, especially in comparison to the much lower volume interbank payments which use a diverse set of standards, often country-specific and typically incompatible.
However, ISO20022 is fast becoming the accepted messaging standard worldwide across Financial Services, and is the obvious choice for the new real-time payments systems being developed. For example, in Europe, the European Payment Council is developing the SCT Inst using ISO20022, while the real-time payment systems in Denmark and Singapore are already operational using ISO20022.
So, why is ISO20022 the standard of choice in preference to the highly successful ISO3583 standard, and can it lead to the same degree of global interoperability of real-time payments that has been achieved by the card networks?
The flexibility of ISO20022 for real-time payments
Information about a payment is increasingly seen as important as the payment itself, and the rich set of data definitions, flexible character lengths and types (including Asian and Cyrillic texts) make ISO20022 a great standard for information flow. In particular, the 140 character remittance field of the ISO20022 standard is often cited as an example of how the standard is suited to support rich payment information. However, ISO3583 also has a similar 140 character remittance field, but the issue is that it isn’t widely used, and to introduce it into message sets of systems that don’t currently use it would be a huge undertaking.
Therein lies the key benefit of ISO20022 – for not only does ISO20022 have a rich set of data definitions, but it is supported by sophisticated toolsets and utilities to manage them that greatly simplify definition of new message sets and rules. In turn, this makes ISO20022-based systems easier and less costly to maintain than ISO3583-based systems (which don’t have a similar set of tools).
The data richness of ISO20022 is a big advantage, but this is eroded somewhat nowadays where any data in any format can be linked through a url in a payment message field, similar to the way a url can be used in a tweet on Twitter to link to further information. Additionally, the richness of ISO20022 can make true standardisation difficult, for example, there are many variations of field usage within the ISO20022 message format for SEPA CTs and SEPA DDs.
However, in addition to its data richness, it is the flexibility and maintainability of ISO20022 that definitely makes it the better standard for future (real-time) payment systems, instead of ISO3583.
Cross-border interoperability of real-time payment systems
Just adopting ISO20022 does not guarantee interoperability between payment systems that use it. Domestic debit card schemes may use ISO3583 but that does not make them compatible with the international schemes such as Visa, MasterCard and American Express, and is why they often cannot be used outside their home country or online. Similarly, unless local real-time payment systems use a common message and rules set with ISO20022, then they may not be interoperable across borders with other ISO20022-based payment systems. That is why there is a global standards initiative, the ISO Real-Time Payments Group (RTPG), led by Payments UK, and formed of over 40 payments organisations from around the world, which is defining a common approach to using ISO20022 for real-time payment messages and processing rules.
The Faster Payment Scheme (FPS) in the UK uses ISO8583, but it had to create (in 2007/08) its own message set and processing rules, that are very different to those used for card payments. For example, FPS uses synchronous processing whereby every real-time payment is confirmed, or rejected synchronously by the receiving bank so that the sender knows real-time the payment has been successful or not.
The EPC’s definition of the SEPA Inst and The Clearing House in the US, and other real-time payment initiatives such as NPP in Australia should all be going through a similar process as FPS did with ISO8583 to define an ISO20022 message and rules set for real-time payments. The challenge for the RTPG is to provide guidance to these initiatives so that they are compatible – a difficult, but not insurmountable task, particularly since there is clearly willingness in the industry to achieve interoperability, as well as regulatory impetus to do so.
….and the blockchain?
With blockchains and distributed consensus ledgers arousing strong interest in banks and payment processors, I expect that these solutions will need to have some compatibility as well with ISO20022 in order to integrate with bank and payment processor systems. While data compatibility should be straightforward, rules compatibility may not be, with concepts such as consensus mechanisms, mining and cryptographic immutability that are not typically found in interbank clearing systems. It will be interesting to see how ISO20022 and blockchain/distributed consensus ledger initiatives develop together.
However, data and messaging interoperability is only part of the answer, and there are ways to achieve it without a uniform standard. Message mapping/translation can still be used to link different systems using different message standards or variations of the same standard. For example, FPS is in the process of accrediting aggregation services to access its central infrastructure – even though this runs on ISO3583, these aggregation services should be able to accept payment messages in ISO20022, MT103, STD 18 and other formats, and translate them for use with FPS. Therefore, even though FPS does not use ISO20022, it should be possible to make it compatible with other ISO20022 real-time payment systems through message translation (although this is dependent on the extent of additional data requirements and alignment of processing rules).
Most importantly, the other part of the answer to interoperability lies in settlement, the ability to settle payments between banks across borders. In the cards world, the international card schemes achieve this with ease – for example a Visa card issued by a bank in Germany can be used to purchase from a merchant in Singapore, because Visa provides a mechanism for the issuer’s bank in Germany to settle with the merchant’s bank in Singapore.
Settlement is in fact the bigger of the two challenges in cross-border interoperability of real-time (or any) payment systems. Uniformity of messages and rules through a standard such as ISO20022 is important and achievable, but it is settlement interoperability that will be most difficult for real-time payment systems to crack.