Contact details:

david.blair@acarate.com

Website:www.acarate.com

SWIFT messaging

SWIFT runs two messaging systems. The old system is called FIN with messages many are familiar with like MT101/3 and MT940. FIN’s age means it was designed as a single byte system, which does not have capacity for large and diverse character sets.

The newer (more than ten years old now) system is ISO 20022 XML or MX messages like ‘pain’ (payment initiation equivalent to MT103) and ‘camt’ (customer account statement equivalent to MT940). Being more recent and XML based, ISO 20022 messages use double bytes and support a practically unlimited number of character sets.

What this means is that ISO 20022, pain and camt messages can handle Chinese, Japanese, Korean, Cyrillic, Arabic, Sanskrit, Hebrew, and any other character set you can think of. Of course they also handle Roman character sets.

If you need proof, consider that almost all countries either have recently implemented or are in the process of implementing ISO 20022 for local clearing. That includes several non-Roman character sets in my back yard (Asia), such as China (CNAPS2), India (ACH), Japan (BOJNet), and so on. Incidentally, many are also immediate payments systems too – the beneficiary is credited immediately and the banks do an end of day net settlement through their central bank, so a bit different from the high value RTGS clearing systems.

To achieve end-to-end straight through processing (STP), we need all parties to be able to handle whatever character set we need to use.

Logically when you pay CNY onshore, all parties can handle Chinese character sets so there should be no loss of information. Likewise, any local payment will go through parties who are all onshore and therefore adapted to the local character set.

Be aware, however, that not all clearing systems support all ISO 20022 functionality. A key potential issue for treasurers concerns data payloads. Corporate to bank pain messages allow 1MB or more of data to be transmitted as part of the message as beneficiary information – typically remittance advices and invoice details. Not all clearing systems, even those based on ISO 20022, support this feature, so alternative arrangements (typically bank to bank transfer of data payloads) must be made. The central banks and clearing houses seem to feel they are in the settlements business not the data carrying business. We, as a profession, have failed to communicate to them that cash is nice but cash we can apply is even nicer.

“To achieve end-to-end straight through processing (STP), we need all parties to be able to handle whatever character set we need to use.”

Corporate connectivity vs clearing | Holistic STP

Assuming a corporate to corporate payment, we have to consider multiple parties.

ERP connectivity

Of course, even when all the connections described above are aligned, corporate ERPs have to be able to handle the required character sets. I will illustrate using SAP as an example.

Assuming your SAP is primarily in Roman characters, and using Chinese payments as an example, you will set up alternate vendor master records for Chinese characters including the beneficiary and bank names that will be used in CNAPS2. Chinese characters from these alternate records will be used when you run the payment proposal to create a payment file. This is what will generate the ISO 20022 pain records in whatever tool you use to communicate with your banks.

FIN workaround

For those who are congenitally opposed to XML, a handful of FIN workarounds were developed 20 years ago, before XML caught on. The three most common workarounds are:

• Use a modified FIN protocol with double byte characters. This can work fine between corporate and bank. It will require tweaking the software at both ends, since these are non-standard FIN messages. And of course they will not work across SWIFT itself.
• Put your vendor code or number in the beneficiary field after separately uploading your non-Roman vendor bank details to your bank. Your bank can then substitute the non-Roman characters for the vendor code and process the payments. First this is non-standard, the messages will go across SWIFT but the resulting payments would be gibberish. Second, you have to make sure the non-Roman vendor bank details at your bank are up to date and have not been tampered with.
• Agree some kind of double byte layered on FIN’s single byte character set that can be used between you and your bank. This will be hard work.

Since many have to work with ISO 20022 anyway for SEPA and increasingly other payment infrastructures, XML just feels like the path of least resistance. But there are (inconvenient) alternatives.

As an aside, let me dispel another SWIFT myth. “ISO 20022 is for bulk payments. You have to use FIN (MT) for high value urgent payments.” Although FIN interpretation is built into the SWIFT network, whereas XML normally goes through FileAct (a different SWIFT service), the speed and the repudiability of both types of messages are the same. I base this statement on extensive testing with three banks when I faced this myth during a SWIFT implementation.

Conclusion

SWIFT can do Chinese and any other character set. FIN cannot but XML most certainly can. FIN is a 40 year old standard based on telex. XML is the standard of the future, already used in your ERP, the internet, and so on. And its reliability has been established over more than ten years. Which would you rather use for your corporate to bank messaging?

The views and opinions expressed in this article are those of the authors.