Taking Care of Business – The US Approach to Real Time Payments

The US has always been more business-friendly than the Old World, and New York is peppered with temples to industry built by 19^th century tycoons such as John D. Rockefeller and J. P. Morgan. Appropriate then that The Clearing House (TCH) in New York should be designing their real time payments system primarily for the use of businesses and corporates. Their recent Payments Perspective Conference revealed why this approach was taken, and how it is progressing.

In the US, the Venmo P2P payment service has been wildly successful – to the extent that “to Venmo” has entered the vocabulary – a sure sign of mass user adoption. Venmo is a non-bank service, so some of the biggest US banks have got together to launch Zelle, a competing P2P service. Zelle provides a messaging layer that allows the sending bank to debit their customer and send a message to the receiving bank, who immediately credits their customer. The payer and payee perceive this to be a real time payment service, but the inter-bank settlement happens across the ACH rails a couple of days later.

Even though Zelle solves the real-time P2P problem, the banks that own it – which are mostly the same as the ones that own The Clearing House – identified another under-served market, namely the B2B space. The Clearing House has done a significant amount of research with businesses to see what they need from a payment system, and their real time payments initiative is aimed squarely at addressing those needs. Hence the features and functionality are somewhat different from the consumer-focused European initiatives.

The most counter-intuitive consideration is that businesses do not see speed as the most valuable feature of real time payments. Equally or more important are the ability to carry rich data; and the availability of non-payment messages.

Rich data in the real world

One perennial business problem is payment reconciliation. At the conference, a representative of a property letting company gave a great example. Their larger tenants may have multiple properties, each of which receives different services, some regular and some ad-hoc. A typical monthly invoice for such clients is “the size of a phone book”. The client may make a part payment of the invoice, flagging some items as disputed; while the payment may also cover items from previous invoices that were disputed but are now resolved. Marrying up the remittance advice against invoice lines is a time-consuming manual process.

Imagine, then, that the property company could send an electronic invoice across the “payment” rails; and the customer payment message is enriched by a breakdown of items being paid. The property company’s systems could then perform the reconciliation automatically, cutting down on manual work and making significant cost savings.

Rich data is the main selling point of the ISO20022 message format that has now become the accepted standard for real time payment systems. It allows non-payment data, such as invoice and remittance data, to be sent in the same message as the payment, eliminating the need to correlate and reconcile data from two different sources. This provides the foundation to automate and solve the reconciliation problem, and this is one of the features of the TCH real time payments that is really attractive to business.

Some people expressed reservations about the practicality of this vision, pointing to previous initiatives such as Electronic Data Interchange (EDI) that came unstuck as standards multiplied into a mutually incomprehensible babel. Strong governance will be needed for TCH to avoid this fate. Another challenge is the ability to carry “telephone directory” quantities of data in a single real-time message – the larger the message, the slower the transmission and the higher the bandwidth used – though the technologies driven by the internet have significantly reduced the impact of large messages.

Non-payment messages

A payment is just one step in a longer-running customer interaction, so a payment message is just one member of a richer message set that supports the end-to-end process. There are two views on how this should be supported. One school of thought says that payment messages are special, so should be supported by a dedicated network, while non-payment messages can go across a different network, such as the Internet. This was the approach used by Zapp, where Request for Payment messages flowed across a separate network from the Faster Payments. The need to connect to two different networks and orchestrate business processes across them both was one of the technical challenges that held back adoption of that solution.

The other view is that a secure messaging network can be used to carry any kind of message, payment or non-payment. This is the principle on which the SWIFT network developed, with a rich message set that can be used for many different purposes. Closed User Groups can be used to control who can send and receive which messages. This is closer to the approach that TCH has adopted, though their function-first approach leads to a less flexible solution than a network-first design.

The specific non-payment messages that TCH have chosen to support are the ones that businesses need. The most important one is the Request for Payment, which supports a wide range of use cases, ranging from bill presentment to ad-hoc payment requests. It is vital because it allows the biller to supply invoice information that they can later use to match up the payment, as discussed above.

Another non-payment message is the Stand Alone Remittance Advice, which provides further support for businesses to reconcile payments received.

Finally, faster

Although “faster” is not at the top of the shopping list for B2B payments, it is still important for some purposes. A speaker from a large airline highlighted the problem with paying thousands of employees, many of whom have wages that vary week on week. Emergency pay-outs by insurance companies could also be made more efficient by using faster payments.

The elephant in the room that was mentioned from time to time, but not discussed at length, is the possibility of using real time payments to replace card payments in e-commerce. This is the use case that unequivocally needs real-time (response within a couple of seconds) and not just “quite fast” (within a few minutes). Businesses are making increasing use of debit cards, so this is another likely use case for the future.

This being the US, a payments conference would not be complete without a discussion of cheques. Sure enough, the final item on the agenda covered a recent Fed report that showed that after years of decline, cheque usage has stabilised and may even be growing again. If real time payments can help the US kill off that antiquated instrument, that will be a justification in itself!

America first

Just as the world watched the UK to see whether the concept of Faster Payments would be successful, so other countries will be watching the US to see whether real time payments takes off for business usage. I think it will – the view that real time payments are useful to consumers but not businesses never had much supporting evidence, and is mostly used as an excuse for inaction. There will be a few critical success factors, such direct support for real time payments by the major ERP system vendors, but when these fall into place, I foresee large-scale adoption of real time payments by businesses of all types. Just as Faster Payments boosted the UK from an embarrassingly slow three day clearing to being a world leader, so TCH real time will make the US the country to beat for B2B payment processing.

First published on bobsguide on 31^st July 2017