The Remittance Data Transport Conundrum for Banks

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.

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.

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.

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.