Payments Views

Carol Coye Benson

Faster, Better, Cheaper – Like it or Not

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

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.


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.

Leave a Reply

6 Comment threads
2 Thread replies
Most reacted comment
Hottest comment thread
7 Comment authors
AnonymousSilverStream AdvisorsSubtleDataCarol Coye BensonKetharaman Swaminathan (GTM360 Marketing Solutions) Recent comment authors
newest oldest most voted
Notify of
Chris Dunne

Really excellent blog post. At VocaLink we built and operate the Faster Payments service in the UK and we have also built the proxy database for the UK Payments Council that will map mobile numbers to bank account details, and I agree with pretty much everything you say. There are two other additional things to consider. For real-time credit push systems to take off you need ubiquity of reach (ie you need to be able to send to everyone). At the start of Faster Payments this was definitely not the case, but once all bank accounts became reachable volumes really… Read more »

Dan Martin

You seem to avoid the issues of fraud associated with push payments. Every push-based payment system I’ve seen is the playground of fraudsters. For instance, any ecommerce merchant that exclusively accepts wired transactions (such as Western Union) in return for products is almost certainly a scam. It’s too easy to receive “push money” and hide behind anonymity. Since the victim, in a push-payment system, has no dispute options, and there is not additional parties assuming the risk, the consumer has no recourse. Successful push systems, such as PayPal, offer dispute resolution, and are still constantly having to battle fraud. They… Read more »

Ketharaman Swaminathan (GTM360 Marketing Solutions)

Having led a Top 3 UK bank’s Faster Payments program back in 2007-8, I agree with almost everything you say. Talking about making payments by using only email or mobile phone number, Barclays’ PingIt mobile app is worth watching. It happens to use the Faster Payments rails for the interbank leg of the payment transaction.


Insightful commentary.

To your comment, “Most systems start by focusing on one domain (like P2P) and then expand into others,” it will be interesting to see which domain takes hold first. We’re focused on Point of Sale, so we see the potential in this arena.

SilverStream Advisors

Yes, this is a useful discussion topic. We spend a significant amount of time in the B2B sector and, as many are aware push payments or buyer-initiated payments (BIP) have become fairly common. Adoption remains low for these types of transactions but the systems and processes are well established. The interesting trend to watch in B2B is how much of these credit-push systems will continue to follow the traditional issuing/acquiring processes established under the card schemes. There is a trend underway to pull these transactions off the card networks and onto proprietary systems. This mirrors a simply ACH-push scenario with… Read more »


> What if these systems could interconnect?

Would it look like Bitcoin?