SHOUTOUT FINTECHNA

Two weeks ago, we reviewed the fast-developing world of real-time #payments. Since then, NACHA launched Phase 1 of its same-day ACH program, activating same-day credit transfers. We have also had further activity in the space, as Citi joined ClearXchange. (Note: I understand that none of these systems are true “real-time,” but that is the terminology that has stuck, so we will use it. A more accurate term would be “same-day payments” or the UK’s “Faster Payments”)

Navigating a complex landscape

The real-time payments landscape is becoming more complex. By my count, we now have at least 7 major systems competing, with more on the way:

1. Mastercard Send
2. Visa Direct
3. FIS PayNet
4. Fiserv PopMoney
5. Same-Day ACH
6. Electronic Payment Orders?
7. ClearXchange (Zelle)
8. Dwolla
9. PayPal (sort of)
10. Venmo (sort of)
11. The Clearing House
12. #Bitcoin/Ethereum/other #blockchain-related systems

The first six systems are built on existing rails, either card or ACH or e-check, and bank support has been mandated. That is not to say that consumers can actually use them; in most cases, the user interfaces have not been built, or are in the process of being built. That’s what I mean when I refer to PayPal and Venmo as (sort of) faster payments; they act like real-time systems for certain use cases, but integration with the underlying funds transfer mechanisms is not yet seamless. This is why the recent announcements of integrations with Mastercard Send and Visa Direct that I discussed two weeks ago are important.

This is definitely a case of too much of a good thing, and I’m sure I’ve missed some important players. What are the terms of competition here, and where should #banks be placing their bets?

Structure of a real-time payments transaction

I think it’s helpful to think of the market in terms of layers, like this:

The top layer is what the end user sees, and might be a digital wallet like PayPal, or a mobile wallet like Apple Pay, or an app, or a web form or button on a web page that interacts with a cookie in the browser. Its purpose is to collect information about what payment the user wants to make.

Next in the stack is a routing and directory layer. The job of this layer is to find the “best” route for the payment to take, based on the options available. The answer to this question will depend on several factors:

• What real-time services the user interface recognizes
• Where the payment is going
• Which of the real-time services recognized by the user interface can reach the destination
• How much it will cost to route the payment over a particular real-time service (this will be a bundle of costs, including switching, interchange, settlement and other fees)
• How fast the payment can be authorized and posted using a particular real-time service (this will probably be related to the cost – faster posting is more expensive)
• How fast the payment needs to be posted (this can be an option at the user interface level)
• Whether there is an incentive to use a particular real-time service, such as a volume agreement or a prepaid fee

Note that settlement is not typically going to be a factor here; I am assuming that any consumer-grade real-time payments service will in fact be using net settlement at regular intervals throughout the day, with ultimate money movement occurring over a real-time gross settlement system (RTGS) like Fedwire. This is how faster payment systems like the one in the UK are architected.

Brief introduction to “net” and “gross” settlement

Parenthetical for those not familiar with the terms “net” and “gross” settlement: gross settlement is what most people think of when they think of a payment. A certain amount of money is taken out of one account, and is put into another account. Net settlement is a system where you record all the transfers out (debits) and the transfers in (credits) for each account, and sum them up periodically. This is more efficient, because a typical account will have both debits and credits over a period of time, and rather than settle each one individually, you can do them all as a batch. For example, suppose that you get paid $1,000, and you pay bills in the amount of $100, $200, and $300. The bank could do four separate settlements, or it could bundle them together and pay you the net amount: $1,000 in credits minus $600 in debits, or $400. Since each transfer costs about 79 cents, the savings really add up when you are talking about thousands of transactions.

Faster payment systems need to balance speed, risk and cost

The frequency of net settlement itself depends on how much risk can be tolerated by the system. As credits and debits accumulate, exposure grows, until net settlement occurs and balances are reset to zero. Authorizing a transaction by checking available balances will be an important feature for a real-time system to have; otherwise, the risk of a non-sufficient funds (NSF) event is greater. Gross settlement risk is usually covered by prefunding reserve accounts.

Any faster payments system can emulate true real-time performance by posting immediately and taking some risk that the net settlement phase will return some exceptions. This is essentially what the credit and debit card systems do, which is why they appear to operate in real-time at the point of sale (and also one of the big reasons they charge so much for interchange).

This sounds like a good job for a payments hub, and it seems to me that payment hubs are going to be in greater demand very shortly. Banks, processors, and wallets will all need ways to pick from a plethora of options using a range of criteria, and a payment hub is the best way to do that.