A new wave of payment capabilities is hitting shores around the world.
This wave is made up of better, faster, and cheaper “credit-push” systems. That means that transactions enter the payments systems from the sender’s bank (like a wire transfer) rather than from the recipient’s bank (like a card or check). Credit-push payments have a number of advantages, most particularly being bounce-free, as the party that has the money is sending it. They also have better risk management characteristics: the sender’s bank, presumably already in a position to authenticate their customer, does that job rather than the receiver.
Think of it this way: a card payment transaction has two messages. A real-time question, that says “is there enough money?”, and a batch clearing and settlement transaction that follows. In a push payment scenario, the real-time message can be the statement “here comes the money”, rather than a question. But I get ahead of myself.
Notably, most of these new systems are also faster: most have real-time notification to the recipient’s bank (and on to the recipient), followed by batch same-day settlement. Others are not-yet-faster, or offer “faster” as an option to the participating banks: these will, I think, need to move to be same-day to compete.
Who We’re Watching
- The Faster Payments System in the U.K. (first out of the box – in 2007!)
- The SPEI system in Mexico
- Visa OCT and MasterCard MoneySend
- FIS PayNet
- Fiserv Popmoney
- clearXchange
- Initiatives getting underway in Nigeria and Sweden
- Planning and development happening in Australia and Singapore
- PayPal and other online wallet providers
Keep in mind, also, many of the bill payment and B2B networks in various countries – which could morph into the “faster, better, cheaper” direction. Many of these already use a “credit-push” concept.
(And just to make things more complicated, I’ll acknowledge here that some of these systems are going to do same-day debits, as well as credit-push. More on that in some future post.)
Prospects for Success
There are a number of issues and complexities that these new systems are navigating – after all, this is the payments world!
Use Cases
Successful credit-push payments systems, I believe, will eventually be used for multiple domains: person-to-person (P2P), business-to-business (B2B), bill payment, remote purchase, and POS purchase transactions. Most systems start by focusing on one domain (like P2P) and then expand into others. The various use cases have different data requirements, but might nevertheless share common payment applications. (Recently NACHA came up with a proposal for a simple addenda record to an ACH payment transaction that will carry a URL linking the payment to whatever data the sender wants the recipient to see. That’s the right approach, and one which some of these newer systems should adopt!)
Of the various use cases, the largest opportunity is undoubtedly B2B payments. But the most intriguing use case is point of sale purchases – imagine a consumer with a mobile device, pushing a payment to a merchant – no authorization required!
Recipient Identification
Some of these systems require the sender to know the recipient’s bank account information (routing number, account number) or their card number. That has any number of problems associated with it, from fat-fingering errors to risk exposure (in the U.S., a business has little protection if their account number is used to fraudulently debit their account). So many systems are using, or contemplating, some form of directory that would map a token, or alias (such as a phone number) to the receiver’s bank account or card information. Having such a directory is a clear position of power, and there is much debate about who should operate these and what they would include. The B2B or bill pay equivalent of this is a recipient identification scheme: BPAY in Australia is an excellent example of how this can work.
Risk Management
The sender’s bank needs to authenticate the payment order from their customer. It may seem obvious that online banking authentication should do this trick – but there are worries. A bank authentication system that is “good enough” for account inquiry or bill payment may prove “not good enough” for sending money real-time out of the bank: banks may need to enhance their capabilities. The sending bank also needs to be able to do real-time account debits: in concept not a problem (after all, think of debit card purchases or ATM withdrawals), but systems may still need some engineering to support credit-push payments. The receiving bank has relatively little exposure, as long as the notification received from the paying bank is a binding promise to pay. (Some systems are still equivocating on this last point – but it will become increasingly clear that it is a requirement.) Both banks, of course, need to worry about the very real risks that these systems are used for nefarious purposes – but the significant work done over the past ten years in OFAC screening, AML procedures, etc. means that there are good frameworks available.
Bank Business Cases
This is by far the thorniest issue. Credit-push payments have unclear revenue streams from end-users, and threaten to cannibalize highly lucrative existing products, from wire transfers to debit cards. Without question, these new systems are going to be cheaper than the old systems. Batch settlement will make them closer to today’s ACH than wire systems, with order-of-magnitude differences in costs. And credit-push, as a single transaction and process, will arguably be lower in cost, from a processing and risk management perspective, than debit cards.
Bankers around the world are singing the classic incumbent’s song: “My customers don’t need this! They like what we give them now!” As I told a group of bankers last October, that is sort of like the recording industry in 1995 reassuring itself that “online music is never going to happen”. But this ostrich-like stance is a good recipe for being disintermediated by non-bank payment providers. Banks do seem to understand this, at a strategic level, and are reluctantly proceeding with the projects. (In several countries, however, regulatory action – either gentle nudges or outright mandates – has been necessary to get the bankers going.)
Interbank Compensation
Yes, I’m talking about interchange here. Interchange, although controversial, is a reasonable method to enable one side of a payment transaction to receive compensation from the other, value-receiving side. The trick is figuring out which side is accruing the value. Some of the new credit-push payment systems have no interchange, some have a fixed unidirectional interchange, and some have a structure that recognizes that interchange will need to flow one way (say, from the sending bank to the receiving bank) in some use cases, and in the opposite way (from the receiving bank to the sending bank) for other use cases.
The value, of course, is experienced primarily by the end user, not their bank, and interchange schemes normally result in the costs incurred by the interchange-paying bank to be passed on to their customer. So a biller or a merchant, for example, may be willing to pay to receive a payment: a consumer might not. But a consumer might be willing to pay (although not much!) to send money to another consumer. Successful schemes will need to have this “directional flexibility” in setting interchange.
Brand
This is the sleeper issue. In payments, brand is not just marketing – it is also the term used by two end parties to tell each other how they will pay. At Glenbrook, we talk about “small b” brands (“I’ll send you a check”) and “capital B” brands (“Do you accept American Express?”). The key is that both end parties need to understand the term. This is the problem with schemes where each bank has their own name for the service: how do the two bank customers talk to each other? “Faster Payments” in the U.K., and “BPAY” in Australia are great examples of services that have a “small b” brand, used by many banks in conjunction with their own “capital B” brand. Understandably, private sector payments services resist the “small b” brand approach, wanting to preserve the value of their own service and use brand strength to bring more banks and end users into their own system. But unless one private sector company ends up with total market domination, the problem persists. This challenge must be solved in any country that wants fast, credit-push payments to work.
Faster and Cheaper – But Better?
So are these systems “better”? We certainly can debate the point, and I have heard bankers make passionate arguments against the need for “faster money”. But I’d say common sense tells us that people will expect payments to be able to move as quickly as any other kind of electronic communication. The great success of the U.K.’s “Faster Payments” service certainly supports this point of view. Enterprises, I think, will welcome instruments that have the speed of wire transfers without the heavy costs of those networks. And if there’s ever a system that would entice consumers away from the use of cash, it’s likely to be fast “push” payments like these.
By the way, if you haven’t seen it yet, take a look at AT&T’s advertisement, touting the capability to “talk and surf at the same time” on an iPhone5. The tagline is: “It’s not complicated – doing two things at once is better”. I think I’ll take as my tagline: “It’s not complicated – faster payments are better than slower payments”.
The Next Step?
So imagine we are a couple of years out, and a significant number of countries (maybe even the United States!) have implemented same-day credit-push systems that work to reach a large number of people – and enterprises – in the country. What if these systems could interconnect? It’s not difficult to imagine – country ACH systems are already connecting. We could have a global same-day payments capability that could serve both consumers sending remittances home, and enterprises paying global suppliers. Now that would be something!
Our existing systems are what they are for a variety of historical reasons. These new systems, I think, will be faster (by definition) and cheaper and better (by logic). The incumbents may look at this with dread, but they need to prepare. “Faster, better, cheaper” is possible – and on its way.
A note on the author: At Glenbrook, we tell people coming through our Payments Boot Camps that if you were to build a new payment system from scratch, it would be a real-time, credit-push system. I live in Southern Oregon, where some of the local citizens think we should form a separate state – or possibly country – called “The State of Jefferson”. If that happens, I trust that the new government will ask me to design their payments systems.
