Remittance Information

An end to end straight through process remains as an ambition in the payment ecosystem. Especially in the B2B space, the communication medium is still old school data standards such as ANSI X12, UN/EDIFACT. Historically, payments were the first business process that banks digitized and thus many of the current models are still tied back to legacy processes and technologies. Initial solutions were using mainframe technology and the core payment messages and processes are built around a certain total message size of 2,000 bytes.

Many modern initiatives across the globe are solving for speed in the retail sector and for some high value payment use cases but struggling to include vast majority of the business entities due to the limitation posed by the “Remittance Information”.

So, what is a Remittance Information? – It's simply an information about the payment, in other words, it’s a payment obligation. A buyer sending money to a supplier associates the payment to an invoice and provides invoice details along with the payment message. Here the invoice detail is the Remittance Information.

Two types of Remittance Information – Structured and Unstructured.

Increased use of mandatory and structured data will further enable automation of reconciliation processes and greatly improve the visibility of cash positions for beneficiaries.

Countries and the schemes vary in their message layout and sizes. Shown below are the remittance information sizes for some of the schemes across the globe:

The major payment systems are moving to the new global messaging standard for payments known as ‘ISO 20022’.

Any payment system requires a messaging standard, i.e., a common set of rules for exchanging relevant payment information to enable efficient communication with participants and related infrastructures. Messaging standards covers things such as:

·?????How senders and receivers identify each other.

·?????How key properties of a payment message, such as currency, amount and value date, are represented; and

·?????What additional information can be included alongside settlement data, and in what format, to enable onward transport and processing of the payment.

First published in 2004 by the International Organization for Standardization (ISO), ISO 20022 is a globally agreed and managed method for creating financial messaging standards. ISO 20022 has the following key features:

·?????Open Standard: Specifications are freely available; development is open, and the standard can continually evolve to meet users’ needs

·?????Network Agnostic: The syntax (language) can be read by a wide number of computer operating systems.

·?????Increased data carrying capacity and improved structure: It allows better identification of the originators and end beneficiaries of payment instructions, better understanding of the purpose of a payment, and avoiding data truncation when sending messages.

The ISO20022 Structured Remittance Information is composed of about 250 data elements (the unstructured is limited to 140 characters).

Remittance information delivery can be accomplished in one of three ways –

1)???Embedding the Remit information in the payment instruction – forwarded through the financial institutions to the beneficiary/originator.

In this case, the initiating party populates the structured or unstructured remittance info component (considering size limitations/constraints agreed on beforehand with its bank).

2)???Separately sending remittance advices and payment messages. Multiple scenarios exist to generate and forward these remittance advices:

Scenario1) Separate remittance advice is generated by the initiating party and delivered by the initiating party to the creditor/debtor. The Customer Credit Transfer Initiation or Customer Direct Debit Initiation message, contains the unique reference of the Remittance Advice in the End-to-End Identifier. This reference will be passed on in the interbank chain and provided to the creditor/debtor through credit/debit notification/statement to allow reconciliation of the incoming credit/debit with the remittance advice.

Scenario2) The initiating party is sending their bank both the actual payment and the remittance advices (which are separate messages, in a format agreed between the parties) The debtor/creditor agent provides a remittance advice delivery service - it separates the remittance advice and can deliver them to the Creditor/Debtor (A) either through direct communication to the final creditor/debtor or, where the interbank settlement allows, to the Creditor Agent/Debtor Agent (B).

The Customer Credit Transfer Initiation or Customer Direct Debit Initiation should contain a reference to the Remittance Advice message, and - when not agreed on beforehand with the beneficiary/originator - details of how and where the Remittance Advice message is delivered or where the details can be found. This info should be passed on in the interbank payment chain and reported to the creditor/debtor.

Scenario3) The initiating party includes the remittance information within the payment (using the structured remittance info component) but has agreed with its bank that the bank will extract the remittance info, will generate a separate remittance advice (as the info is too lengthy to channel through a payment system) and will deliver either to the creditor/debtor agent or creditor/debtor. The bank ensures that the interbank payment message contains the identifier of the Remittance Advice and provides information (in the Related Remittance info) component on where the Remittance Advice message is delivered or where the details can be found. Depending on the service agreed, the bank will deliver/or make available the remittance advice to the creditor agent/debtor agent or creditor/debtor (as shown in scenarios A and B above).

3)???Third option is where the structured remittance information is separated from the payment details, and is provided as a reference to a separate data repository with a unique ID. In this model, a unique ‘remittance creditor reference’ would accompany the payment details in the message from end-to-end. The reference itself could be a URL hyperlink to a repository, provided by the debtor.

Note: The Scenarios provided above are not exhaustive.

A uniform ISO 20022 implementation across the participants and the regions are crucial to the success and growth of payment systems as well as the B2B supply chain. Each participant, market and scheme following different and local approaches to handle remittance information will create the frictions and face costly rework frequently.

ISO migration timelines for some major schemes -

References :