Blog article
See all stories »

The Remittance Data Transport Conundrum for Banks

Small and large companies alike want more streamlined A/R processes.  The driver behind a common standard for remittance information delivery is to enhance the value of and promote the growth of electronic payments in order to improve efficiencies and enable straight-through processing.

Earlier this summer, I attended a remittance standards conference hosted by the Federal Reserve Bank of Minneapolis and the Accredited Standards Committee X9.  Participants represented the Federal Reserve, ASC X9, ASC X12, SWIFT, ANSI, ISO, IFX, OAGi, GS/1, vendors and payments industry analysts. I was reminded of the old adage, “The beauty of standards is that there are so many to choose from!”  While the market need for a remittance format standard was understood by all, it was acknowledged that the format and transport mechanisms will take considerable time and effort to define.

Last week at Sibos in Toronto, remittance delivery was again discussed in the context of supporting the extended remittance information in the new Customer Transfer Plus (CTP) message defined by the Federal Reserve Banks and scheduled to be implemented on November 19, 2011.  Financial institutions using the FedLine Direct® Fedwire Funds Service are required to be able to receive CTP messages, but support for sending the new CTP message is optional.

But, what are the implications?  As was pointed out during the discussion, the fact that a bank can receive the extended remittance does not mean that it can be delivered downstream.  And while some banks will be ready on November 19th to offer a full suite of tools capable of delivering this extended remittance data, many (arguably a majority) will not.

In addition to the many available (and competing) remittance data formats, the actual delivery of remittance data falls into two camps: in-band and out-of-band.  With in-band remittance delivery, the remittance data travels with the payment information.  With out-of-band remittance delivery, the remittance data is stored in a repository separate from the payment information and is reunited with the payment details prior to delivery to the customer.

One of the reasons that checks still prevail in North America is because the remittance data travels in-band, located in the top two-thirds of the paper above the perforation.  When discussing the out-of-band solution, corporate customers are adamant that they do not want the responsibility and burden of reuniting data. They clearly see that as a responsibility of the financial institution providing the service.  North American solutions appear to favor in-band transport of remittance data while European solutions appear to favor the out-of-band approach.

Ultimately, corporates want payment and remittance data delivered together and the burden appears to be on the banking industry to enable straight-through processing and make the receipt of electronic remittance straightforward and simple. This will help drive the continuing migration towards electronic payments.

I welcome your thoughts on this topic.


Comments: (4)

Chris Errington
Chris Errington - None - London 30 September, 2011, 16:03Be the first to give this comment the thumbs up 0 likes

For me, ‘in-band’ transmission wins every time because I’ve had too many ‘out-of-band’ experiences.

Our business insight on this is that not only do the banks need to adopt an ‘in-band’ remittance capable payment standard but the corporates need to change their attitude as well.

In our work with banks and corporates seeking to straight through processpayments to their back office we come across issues with bulk payments all the time.  The problem is that the bulk payment arrives electronically but no remittance data is attached – creating the ‘missing remittance’ issue and a reconciliation nightmare that technology can’t really help with. 

But never underestimate just how much of the 'missing remittance' problem arises not from the lack of a payment message with the necessary fields, but from the customer simply refusing to share the remittance data at the outset.  Your customer has the extended remittance information readily to hand and in electronic form, after all it comes straight out of the accounting system when the payment is initiated. But, your customer is unwilling to always share it with you.  No matter how hard you try, you cannot get a list of the invoices making up the bulk payment.

If you are someone like a property agent or pension administrator then you are receiving large bulk payments all the time and have a contractual (sometimes legal) duty to pass on those payments to a third party in good time.  But if you are unable to get your customer to tell you what the bulk payment was made up of then you have a business process problem and not a banking problem. 

Therefore, a global adoption of remittance standards tomorrow would not solve everyone’s problems.  First, we need to change the attitude of some customers – who just don’t want to tell you what they are paying.

So the ‘missing remittance’ problem won’t be solved by the banks alone, nor should it be.  Corporates also need see the benefit of sharing information between them, initially outside of the banking system, before we can realise the true benefits of straight through processing within the banking system.

A Finextra member
A Finextra member 03 October, 2011, 05:58Be the first to give this comment the thumbs up 0 likes This is an issue that confronts all markets and will be one of those areas that defines how well banks can adapt to changing market needs. The issues that I have seen is that when customers move away from cheques for economic reasons, they move towards ACH/bulk payments that does not naturally provide remittance data. In fact they were never designed to carry such data. ACHs bulk payment clearing systems were only designed to carry simple payments. What I have seen is that customers have chosen to taken the cheapest option and not think of the downstream consequences. I have plenty of war stories about dealing with pension/superannuation funds who struggle to take compulsory superannuation payments via ACH payments. My favourite was discussing with a beneficiary customer how we could trace a payment to a pension fund with over 300,000 members with the reference "Super for Sue". Some banks provide such services (payment with remittance) with proprietary solutions but they effectively "materialize" the rem data by only offering fax/email/web notification of data to beneficiary. Even for their own customers! Whilst it provides some efficiency it does not really solve the information with payments dilemma. The payment is still detached from the remittance in most cases. Other reasons for customers still retaining the remittance notification process are: - My remittance details are complex and I don't think the bank can do it. Basically they don't trust the bank to get it right or the banks' solution is too expensive. - There are plenty of proprietary solutions embedded in the system that manages the payment/remittance creation process. All of the major ERP /accounting systems have this functionality. Hopefully with some of the discussions occurring at a ISO 20022 standards level this may start to resolve itself. Talk of developing specific industry Message Extensions with Supplementary Data may provide the underlying impetus to see market participants (including banks) move towards allowing the data to flow with the payments.
Nick Collin
Nick Collin - Collin Consulting Ltd - London 03 October, 2011, 13:52Be the first to give this comment the thumbs up 0 likes

Interesting discussion.  I did some work on this in the UK recently and concluded that the best we can hope for, realistically, is that payers include a simple, meaningful payment reference in the payment message and that if the remittance data is at all complicated they should use the same reference to link to a separate out-of-band remittance message.  This in itself seems to be difficult enough, but it should be achievable.  Yes, a rich, standard, in-band, ISO 20022-type solution would be wonderful, but I fear that apart from closed loop transactions between highly sophisticated companies it will remain a pipe dream for many years to come.

A Finextra member
A Finextra member 12 October, 2011, 23:08Be the first to give this comment the thumbs up 0 likes

We have found that out-of-band is especially helpful when the amount of remittance data is very large.  One of our customers routinely makes payments containing anywhere from 25,000 to 35,000 lines of remittance.  Existing standards cannot handle that and our solution delivers the data in formats that are easily loaded into the recipient's A/R system.

I tend to be bullish on the ISO 20022 specific industry Message Extensions with Supplementary Data as mentioned above. To me it is analogous to the EDI message set which satisfies industry-specific requirements with industry-specific messages.

Retired Member

Member since

19 Mar 2009


Blog posts




This post is from a series of posts in the group:

Payments strategies 2015-2020-2030

Payments systems visions, strategies, trends, pilots, forecasting, and planning for the short-, medium-, and far-term.

See all