It is not just for Europe; it is used globally including countries like China, Japan and Russia that use non-roman character sets. It is not exotic; it is built on XML which is the lingua franca of corporate systems. It is not just for large companies; half of SWIFT corporate members are smaller companies. So what is holding ISO 20022 back? Largely misinformation and change aversion, says our Treasury Insider.

There has been a lot of coverage in the treasury press about new standards for immediate payments using ISO 20022. The immediate trigger was a recent announcement by Payments UK that said: “The landmark first draft announced today (10^th August 2015) is the result of work by the ISO Real-Time Payments Group (RTPG), made up of over 50 global experts facilitated by Payments UK, which has been tasked with driving forward the project of developing the ISO 20022 messages required.”

This is good news for corporate treasurers indeed. Whilst we may be satisfied with same day value, immediate payments will encourage the move away from multi-day settlement that remains common in many low-value clearing systems, and will reduce costs as well as delays and float. Less positive has been the implication in much of the press that ISO 20022 is itself a new innovation.

A trusted standard

ISO 20022 XML (eXtensible Markup Language) was started in 2004, and the first messages for payments went live in 2006. So whilst this is not novel, it may be perceived as such since the standards keep advancing to handle new needs like immediate payments. Moreover, the breadth of ISO 20022 has also expanded from payments to cover areas including: securities, trade, cards and FX.

Corporates, including my old employers, have been using ISO 20022 to communicate with banks for a decade. It is famously the basis for SEPA (Single European Payment Area) the pan European payment system. People are less aware that ISO 20022 is also used for clearing in China (CNAPS2), Japan (Zengin and BoJNet) and Russia (CMPG) and too many countries to list all over the world.

XML is simply the machine-to-machine counterparty for the more familiar HTML (Hyper Text Markup Language) which we know and love on our internet browsers. You are already using XML – although possibly without knowing it – it is the glue that holds corporate systems together. For example, internal messaging within SAP – called iDOCs – is XML.

The gold standard

ISO 20022 has standards for every conceivable message a corporate treasurer would want, and in fact a lot more for other financial purposes. SWIFT’s FIN MT standards were designed only for cross border high-value flows like FX settlement. ISO 20022 on the other hand, covers cheques, bank drafts, local low-value (like payroll), bulk payments, cross border and trade.

A group of bankers, corporates, and system vendors called the CGI-MP (Common Global Implementation – Market Practices group) has standardised most payment instruments in most countries, and is working on the rest. This means there is one standard way to get each type of payment executed regardless of which bank you use.

Your systems therefore need only one standard for all kinds of flows, in all geographies, in all languages, and so on. FIN was ‘patched’ to handle some of these needs, but each bank created their own workarounds – causing nightmares for treasury interconnections – and major operational risks as market infrastructures around the world upgrade to offer new services like immediate payments.

Future-proof

Global adoption by market infrastructures and rapid standardisation of corporate connectivity by GCI-MP mean that ISO 20022 is effectively future-proof. Whatever new payment technologies come along, they will most likely be cleared in ISO 20022. Even if they are not cleared in ISO 20022, the global breath and coverage of CGI-MP mean that corporate connectivity standards will be developed at the same time as any new payment systems are rolled out. This means that treasurers using ISO 20022 effectively hedge themselves against the operational risk and cost of future developments in payment technologies and services.

Corporates, including my old employers, have been using ISO 20022 to communicate with banks for a decade.

Moreover, being a global standard developed by corporates and banks and system vendors means that ISO 20022 is extremely well supported by corporate systems – almost all ERPs and TMSs have ISO 20022 functionality built in. This means that treasurers using ISO 20022 lower their costs and operational risks by using established and well known standards (as opposed to implementing bank proprietary standards, Excel interfaces, etc).

Double byte means truly global

There is a persistent myth in treasury circles that ‘SWIFT does not do Chinese’. This error is based on the limitations of the legacy SWIFT standard FIN, which dates from the 1970s when bandwidth was limited, and uses eight bit bytes (computer letters) which allows only 256 characters, which in turn limits FIN to the Roman alphabet. In fact, FIN started in the days of telex, which had only six bit letters, which is why everything had to be in upper case with no punctuation.

ISO 20022 is based on 16 bit double bytes, which allows 65,536 characters, which is enough to handle all known writing systems. And sure enough, ISO 20022 has been adopted by many non-Roman market infrastructures including China, Japan and Russia.

Market infrastructure vs corporate connectivity

It is important to be clear that ISO 20022 is used both for market infrastructures and for corporate connectivity. Market infrastructures means bank-to-bank execution of payments via the central bank for most RTGS or a local central bank approved clearing house for most local low value payments. Corporate connectivity described corporate-to-bank communications; like sending payment instructions to your bank and receiving bank statements from your bank. Most central banks and clearing houses – in almost every major country around the globe – have concluded that ISO 20022 is the best way for them to manage local clearing.

It is not necessary for corporates to use ISO 20022 to instruct their banks to make payments through ISO 20022 market infrastructures – you can use bank legacy formats, or BAI, or UN-EDIFACT, or even Excel. But the more market infrastructures move to ISO 20022, the more compelling it is for corporate connectivity. Conversely, you can use ISO 20022 to instruct your bank to pay over legacy market infrastructures like ACH and FIN or even cheque – and CGI-MP have standardised exactly how to do that for each case.

Global harmonisation

Another persistent myth is that ISO 20022 is not globally standardised, despite the noble efforts of CGI-MP. In most cases, this stems from treasurers perception that ISO 20022 does not take away local requirements like withholding tax in Thailand, boletos in Brazil, purpose codes in China, and so forth. While I understand these frustrations, harmonising local laws across the planet is beyond the remit of CGI-MP.

What CGI-MP can and does do is to standardise the way local nuances should be coded in ISO 20022 messages, so that you only need to figure it out once and it will work with all your banks. In some cases, complaining treasurers may be dealing with countries that have not yet been standardised by CGI-MP. If this is your problem, step up and join CGI-MP.

High value payments

Yet another persistent myth is that ISO 20022 is only for bulk payments and that you have to use FIN for high value payments. This is based on the misunderstanding that because FIN is the de facto standard for things like FX settlements, you need to send a FIN message to your bank to instruct such a payment. I repeat what I said above – ISO 20022 covers all payment types including cross border high value, bulk payments, payroll, bankers’ drafts, etc.

A subtler misconception is that ISO 20022 is slower than FIN payments. When this concern came up at the most recent implementation I managed, we tested the latency of ISO 20022 messages vs FIN messages as well as checking their non-repudiation statuses. As SWIFT told us, there was no difference. So save yourself the trouble – ISO 20022 is the only message set you need.