Post image for Really Big Questions in Payments

Glenbrook’s Allen Weinberg wrote a few weeks ago about his view of the Grand Challenges in payments…. a daunting list, and one I agree with.  But I want to extend his discussion on one of his challenges:  “Realigned value chain economics in a push payment world”, and add two more: “What is the proper role for government in the issuance of money?” and “Who owns the payment address?”

Warning – these are just questions – not answers!

The Economics of Credit Push

The credit and debit card industries, as they evolved, created a number of new businesses – one of which derives from the merchant discount fee (MDF) revenue which card acquirers, and their partners, receive.  This business was a fairly radical departure from the past: merchants previously simply deposited checks and cash into their bank accounts, paying perhaps a deposit fee but nothing like a merchant discount fee.

Now, this is a complicated subject, and you may think I’m talking about interchange – but I’m not.  Interchange, of course, is a part of the MDF which is passed on to the issuer, to cover various of the issuer’s costs.  This is a tendentious subject in countries around the world.  Although I think one can make a case that debit interchange is on a trajectory to zero, that’s not my point here, or what I’m asking you to think about.  Consider instead the rest of the MDF: the money that the merchant’s acquirer and their partners keep.  Why does that exist, when no comparable amount exists in a straight deposit scenario? Here’s my take – (which I have written about before):

The rationale for the acquirer’s portion of the MDF was sound:  significant new costs needed to be covered.  These included the merchant-side cost of managing (asking for, receiving) the good-funds authorization; the cost of the merchant-good-behavior guaranty; and the costs of supporting the hardware and connectivity requirements for online payments.   In exchange, the merchant received all of the manifold benefits of electronic payments.  A good deal – not at any price, but clearly value to the merchant for which they were willing to pay.

But the new world of credit push payments looks very different.  This is unfolding in two variations around the world.  Developed nations are introducing new, or enhancing old, ACH-type systems for real-time “push” payments.  Developing nations are introducing various forms of mobile money wallets – also capable of doing real-time “push” payments.  These look a lot more like a direct deposit of payroll transaction than they do a card transaction.  The costs mentioned above are more or less gone: there is no need for a good funds authorization; the rules are generally written so that the receiving bank (or financial services provider) is not making any behavior guarantees to the sending bank; and the hardware and connectivity is probably a phone and the internet.

These credit push systems are being introduced for P2P, B2B and bill pay use cases, and not, generally speaking, for merchant payments.  But it is inevitable that they will expand into this: we see this with the introduction of “Pay By Bank” in the U.K., and by products such as Kopo Kopo in Kenya.  Many people assume that a commercial business model similar to that used for cards will prevail – but will it?  Does that make sense?  Or will it look more like a simple deposit into a merchant account?

There is, of course, one important additional source of cost in these payments – the need on the part of both the sending bank and the receiving bank to perform AML compliance.  This is complex because both the risks are new (what exactly are bad guys going to do with these new capabilities?) and because the regulatory environment around them is not yet settled.  But banks will need to price their costs in managing this – both to the sending party and to the receiving party.  Where merchants are the receiving party, they will need to pay some of this.  What is not clear is if card-like interchange will exist on these systems which will entail a merchant’s bank compensating a consumer’s bank for some portion of the consumer’s bank’s costs.  There is no such interchange in the U.K.’s Faster Payment system, although (as I understand it) the “Pay By Bank” merchant payment service offered on top of this will have a component of merchant revenue shared back to the consumer’s bank.

One final thought on this question.  A simple, direct, party-to-party electronic message.  That’s what we’re talking about, right?  Think about email – and the cost of email to the end-users.  That may be the way we are heading.

Government and Money Issuance

“Issuance” is a funny word.  We use it in the card industry – to mean the entity (usually a bank) which issues a card to a consumer – but we hardly think of it as the issuance of money.  A debit card bank, instead, has a deposit liability to the customer – representing money in the bank that has been issued by the central bank of the country.  (A credit card issuer has a willingness to extent credit; again, not an issuance of money.)  But in the developing world, so-called “mobile money” is created when, typically, an MNO accepts a cash deposit at an agent and creates an electronic balance for the depositing customer. The MNO is deemed to have “issued” the mobile money (sometimes called “eMoney”).  What’s really the difference?  Not much.  The MNO has created a liability, just like the debit card bank did.  The balance at the bank is backed by the bank’s cash on hand, and, usually, guarantees of the government.  The balance at the MNO is backed by a deposit the MNO has made at a bank.

So why do I bring this up?  I’m fascinated by the discussions around the idea of central banks issuing virtual currency – using some variation of the blockchain schemes that abound.

Let’s think about cash for a moment.  The government is the issuer – the creator – of cash.  The government bears the expense of creating the cash, and, along with the banks in the country, the cost of distributing, collecting, and safeguarding cash[1]. The government, of course, also has a strong interest in its role as issuer of money because of its interest in controlling the monetary supply and through this controlling some aspects of the economy.

Although merchants and consumers undoubtedly incur costs in the use of cash, many people, and many small merchants, perceive that the use of cash is free to them.  So thought of this way, cash is a national utility – perhaps what economists call a “public good” – provided by the government to its citizens.

Within the payments industry, we’ve been focused on replacing cash with electronic payments for a long time.  There are very good reasons to do this, which I don’t need to elaborate on here. But does it necessarily follow that what had been a government function (issuing cash) suddenly becomes a commercial function (enabling electronic payments)?  Why doesn’t the government start issuing “eMoney” – perhaps in virtual (blockchain-like) form?  And can this be done with some of the attributes of cash today – so that it’s use is essentially free to consumers?  If the government issues “eMoney” – how are banks involved?  Are they even necessary?

It will be fascinating to watch.

Payments Addresses

How will you address a payment you send to someone (or some business)? A simple question, one would think.  But there are myriad options.  First of all, let’s clear the air about the differences (yes, yet again) between “pull” and “push” payments.  In a “pull” payment (like a card transaction, or a check), the payer has to give the payee their account number (or a token to it) – so the payee can send this data through the value chain and accomplish the “pull”.  That’s what a check number or a card account number does – you give it to a merchant, the merchant gives the number to their bank, who uses it to pull money out of your account.   By the way, very bad things can happen when that number is stolen – hence the move to tokenization in the card world.

But in a “push” world, the reverse is true.  The payee has to give the payer some kind of account information, so that the payer’s bank (or institution) can send it to the correct place.  It’s an addressing issue, like a physical street address, a URL, or a phone number.  Generally speaking, the bad things that can happen with a “pull” account number can’t happen with a “push” address.[2]

So “push” addresses aren’t secret – they should be freely and easily given to anyone you want payment from.  It makes a lot of sense that they be something that is easy to remember – some commonly known item (phone number, email address) or some easy-to-remember-and-use code.  A good example of this is the BPAY code used in Australian bill payments.  More recently, in the U.S., Square has introduced this with their “$Cashtag” concept and PayPal with “PayPal.Me”.

But in the United States, we are looking at a universe where in all probability there will be multiple credit-push payments networks: Square and PayPal and The Clearing House and Visa and FIS Paynet, etc.  Will each network use its own addressing system?  How inconvenient will that be for payers and payees to remember and manage? Or might these competing networks agree to collaborate on a common naming protocol – and the underlying directory/discovery/routing infrastructure that can support network interoperability?

If there is a common protocol, who will “own” that?  Is that a government function, like ZIP codes?  A non-profit organization with that as it’s purpose, like ICANN? A banking industry association, like the ABA and bank account routing codes?  Or will each network persist in “owning” its own naming scheme, putting the burden of managing the inefficiencies of this on its own customers?  That sounds crazy, but remember each network is hoping that it will be come the network, and control of the naming scheme may help with that….

Important discussions along these lines are currently going on in the U.S. payments industry – but it is far from clear that common sense will prevail.  I’ve been advocating for a concept I call “PayCodes” – let me know if you want to know more about that!

So that’s my list of the biggest questions facing our industry.  Comments welcome!

[1] The government’s costs in doing this are to some extent offset by the mysterious phenomenon of seignorage.

[2] Unless that “push” address can also be used to “pull” payments – like a bank account number.

3 Responses to “Really Big Questions in Payments”

  1. Tom Hay says:

    Interesting questions Carol.
    When we were designing the “Pay by Bank” push payment scheme in the UK, my initial idea was to take a lot of cost out of the system by eliminating acquirers. However, one role of acquirers that applies equally in debit card and push payment scenarios is insurance against merchant failure. Some businesses, for example holiday companies and furniture stores, typically take payment well in advance of delivering the goods/service. If the merchant fails (goes bankrupt) in the meantime, who is going to compensate the customers who have already paid, but received nothing in return? For this reason, instead of crediting merchants immediately, acquirers typically hold back a float, the size of the float depending on the level of risk presented by the specific merchant. If push payments went straight from consumer account to merchant account, disintermediating the acquirer, there would be no remedies for consumers – caveat emptor.
    One option would be to make the value chain more transparent, so a customer could choose between the lowest cost payment method where they bear the risk of non-delivery of goods or service, versus a higher cost “insured” payment where an intermediary (acquirer) will provide compensation in case of non-delivery.

  2. Nice post but I must point out one error in your line “Developed nations are introducing new… real-time “push” payments”. This is certainly not true at least of a developing nation like India. India got ACH-like A2A payment methods (NEFT, RTGS) first (over 10 years ago); it then got (around 3-4 years ago) mobile wallets (from MNOs, fintech companies and banks). So mobile wallet is in addition, not in lieu of, ACH-like payment methods.

  3. dave f says:

    Carol, Good questions. I agree a world with multiple “push” addresses is too complicated. In fact even one is pretty daunting if it’s another thing to remember.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics