Exploiting the value of extended remittance information

I sat in on an interesting case study discussion at the London SWIFT business forum last week about the use of extended remittance information (ERI) to improve automation of accounts receivable and payable.

HSBC, BNP and Orange spoke about a successful proof of concept they carried out which demonstrated the value of using ISO XML messages (specifically Swift Bank-to-Customer Cash Management messages – CAMT 52, 53 and 54 message IDs) passed over Swift to carry more remittance information than is possible across existing bank infrastructures. Clearing systems are often restricted to just 18 characters of information. Even the modern SEPA system allows just 140 characters – good enough for Twitter, but not fit for purpose in the remittance world.

Payments that are stripped of valuable remittance information as they pass through the banking system make it difficult for corporates to reconcile the receipt to the invoice. This presents a challenge for Orange which receives high volumes of payments from its customers.

Seeing an opportunity to improve the process, Orange, HSBC and BNP carried out a proof of concept whereby the corporate remitter (the company paying the invoice) sends a rich XML payment instruction that is split into two.  The payment itself goes through the existing banking system to create the cash movement. The rich XML remittance information is sent over Swift to the corporate. The sending and receiving banks collaborate to ensure the file exchange works and make use of the CAMT messages to pass on the ERI. This allows Orange to more easily identify what the bank receipt of funds relates to, essentially by matching the payment to the rich CAMT message key identifiers, such as invoice number and reference in the incoming message. 

While there are still some issues to be resolved around the difficulty of packing and unpacking messages as they enter and exit the banking infrastructure, the success of the trial shows there is now a very real opportunity for all involved to repeat the process and roll it out more widely. There was also a call to action for other banks to join this collaboration. The arguments are compelling: corporates will benefit from the automation of their cash allocation process, while banks gain an ability to charge for the added value whilst retaining their existing payment systems.

In my view this all sounded as though it should have happened 20 years ago but I guess it is progress. Perhaps this time it will be the ISO XML message and Swift that facilitate a step change, so long as the parties are on Swift, the chosen banks support the messaging and parties can handle XML.

Splitting a message into two parts and routing the payment and information separately is a workaround, which causes most of the remittance headache globally.  A better solution is to keep the information firmly together (which Amazon and Ebay achieve) but until such time as the banking system is overhauled these workarounds will have to remain.

The corporate world of matching and reconciliation certainly needs an overhaul, with new technology to assist the drive for automation and control, especially in the shared service centre world. Any improvement to the messaging of remittance information is progress – so adoption of the concepts in the case study can only help.

These developments should also pave the way to reducing the reliance on spreadsheets as the tool of choice for matching and reconciling payments, which has got to be good for the industry as a whole.