A Deposit By Any Other Name?

by Carol Coye Benson on February 12, 2014

in Banking, Carol Coye Benson, Faster Payments, Uncategorized

Carol Coye Benson - Glenbrook Partners

What’s the difference between card acceptance and a deposit?

In both cases, money is being delivered into a merchant’s bank account – in fact, a purist would point out that a deposit actually is the last stage of card acceptance for a merchant.

But consider instead a different kind of deposit – something that is more like the deposit of your salary into your bank account.  In the U.S., this is done through our ACH system.  Your employer sends a file to their bank, and a day or two later money is deposited into your account.

Your bank doesn’t charge you for accepting this deposit – in fact, they are glad to have your money come in.  They pay a tiny processing fee to the ACH operator who sends the file to them.    But no one pays anything like the “merchant discount fee” that a card-accepting merchant pays.

That’s a consumer example.  The ACH system is also used for business-to-business payments, and a business receiving an ACH payment from a business customer gets that deposited into their account.  They (the receiving business) may pay a small transaction fee to their bank for receiving the payment – but again, nothing like a “merchant discount fee”.

An acquirer providing card acceptance for a merchant, on the other hand, does charge their merchant this discount fee.  So what are they doing to earn this?  Quite a lot, actually.

  • First, our card systems are “pull” payments systems, not “pushes” like the ACH examples above.  In a “pull” system, you either have to have a real-time authorization system (which cards do), or you have to accept the risk of bounced transactions (as with checks).   That costs money, and part of a merchant’s fee covers the acquirer’s share in those costs.  Furthermore, the consumer’s card issuer is doing a lot of that work, and the card acquirer plays the role of a channel in directing a compensating fee from the merchant to the card issuer –that’s the mechanism we refer to as interchange.  (The card acquirer plays this role because they’re the one with the relationship with the merchant – the card issuer doesn’t have a relationship with the merchant.)
  • Secondly, our card networks have elaborate rules, many of which protect various consumer rights, including protecting a consumer when their card is used at a fraudulent or badly-behaving merchant.  The merchant’s acquirer bears financial responsibility for some of these costs, and their pricing needs to cover that risk.
  • Finally, card acceptance has always involved a fair amount of heavy lifting in terms of physical devices (terminals, etc.) and connectivity – one of the things that the acquirer needs to do is support the merchant’s physical card-accepting environment.

Although you can argue about the level of merchant discount fees, I think most people in our industry would agree that there is some real value being provided to merchants by their acquirers (and, behind them, by the card networks and card issuers), and that the merchant discount fee price is an appropriate way to capture this value.

So why am I thinking about this?  Because I believe that a confluence of technical, regulatory, and business developments could result in some fundamental changes to these economics.

What might happen?

  • “Push” payments may start to supplant “pull” payments. Imagine, if you will, that you are living in a country that has a bank-based consumer immediate funds transfer system.  The U.K. has this with Faster Payments, and Mexico has it with SPEI . Other countries have it or are working on it – we’re thinking about it. These systems are like the ACH – they are simple, “push” payments that create a deposit into the receiver’s account.  These are always “good funds” transations – there is no need for an “authorization” transaction to ensure that good funds are there.  In the U.K., it’s up to the receiving bank to decide if they will charge their customer for accepting the deposit – but I bet most of them don’t.

These systems today are used primarily for P2P or B2B transfers, or for bill payments.  They aren’t used – yet –  for purchases at the point of sale.  But they could be.  Imagine using the banking app on your mobile phone to “push” money to a merchant’s cash register, rather than to another person.  That would be an ACH-like deposit into the merchant’s account. Although the merchant’s bank might charge them for receiving the money, it wouldn’t be likely that it would be much: and without an interchange structure, there would be no way for that money – the fee the receiving bank is charging the merchant – to make its way back to the consumer’s bank.  (In the U.K. they are starting to go in this direction – with the recently announced “Zapp” offering – it will be interesting to see what the pricing is there.)

  • Secondly, some of these new payments system may not have the same consumer protections built into them that our card systems have.  Although that may sound alarming, I’m merely pointing out that consumer protection doesn’t necessarily have to be embedded in payments system rules that end up transferring liability from one party to another.  Not all of our payment systems have this: if today you pay a merchant by check, and that merchant fails to give you your goods or otherwise behaves badly, you may have legal recourse to the merchant – but not because of the rules of the checking system.  The merchant’s bank, which received the deposit, is not at risk of having to return the deposit because of the merchant’s behavior.

In the developing world, some of the new “push” payments systems, particularly mobile wallet systems (often carrier provided) have no built-in recourse.  This isn’t because they don’t care about the consumer – it’s because this is a way of drastically lowering the overall cost of the payment system, and therefore lowers barriers to its use, as well as reducing the logical need for a merchant discount fee to cover those risks.

  • Finally, we all know that the physical environment at the point of sale is undergoing some major changes.  As a merchant, if I am using a generic tablet and WIFI or BLE to accept payments, I may not need (and I certainly won’t want) to pay my acquirer a hefty fee for enabling physical card acceptance.  Especially if the consumer is also paying with their phone…

So altogether, changes like this could result in some mostly unintended – and little considered – effects on our industry economics.  None of this would be simple, or easy.  Especially, expect resistance from incumbents – particularly financial institutions, who could be economic losers with these changes.  But progress does tend to march on, and doesn’t always respect the past! If I were asked to handicap the odds of the three changes I listed above happening in the U.S. market over the next five years, I’d say “medium” (faster “push” payments), “low” (consumer protections outside of network rules) and “high” (merchant device “independence”).  What do you think? I’d appreciate your comments.

26 Responses to “A Deposit By Any Other Name?”

  1. Phillip says:

    Wouldn’t Dwolla be a good example of a push payment network available here in the U.S.

    • Yes, in concept. But to work, a “push” network needs to have the financial institutions in the country signed up – with 14,000 in the U.S., Dwolla has a long road to tread. FIS PayNet, and Visa Personal Payments are two debit networks that are using the “push” model, that already have problem (mostly) solved. clearXchange is headed in the right direction, with the three largest banks on board – but still only covers some recipients. (All networks will say they can handle “off network” payments, but those payments are delayed or use other rails.)

  2. Geoffrey Tunbridge says:

    I agree with your assessment. However, there are challenges that could stop a complete move to ‘push’ payments. The “promise to pay” capability that the current Merchant Pull and Cheque models allow. Without some Buyer protection most will be unwilling to give payment details to a Seller. Also, without “promise to pay” as a capability of the payment these type of transactions will have to move to instantaneous or ‘on account’ model.

    • Peter Ehmke says:

      Hi Geoff. Unless I totally misunderstood you I see some flaws in your argument: firstly, there is no need for a “promise to pay” in this kind of payment. Payment is simply irrevocable made. it does not even have to be immediate settlement as long as the ACH rules determine that the payment is irrevovable once it has been made. Secondly, in this payment type the consumer does not give any of his data to the merchant at all. so no worries at all there. i suspect this latter ;oint will actually drive a lot of the development in future.

    • In a push transaction, the buyer doesn’t provide their payment details to a seller – the seller just gets the money! And yes, to work, this model needs to have the effect of instant transactions. What I mean by that is that the real-time message from the payers bank has to be immediately binding on the sending bank. The actual settlement can happen later; typically later that day or the next day.

    • José says:

      Excellent article Carol. Geoffrey, good point. Will you please explain more about the “promise to pay” you pointed out.
      Thank you very much.

  3. JC says:

    Well written, thank you. Would be great to have visuals, though.

  4. Shawn Hagmeier says:

    Perhaps the most challenging aspect of push payments for merchant purchases is the notification. If I push a payment to a merchant, the merchant will want real time notification of the payment on their system prior to releasing goods to the consumer. Unless the merchant and consumer are participating in the same closed loop payment system, there is no defined and established protocol for managing the real time messaging. This is handled implicitly in the pull model represented by the card networks. Unless consumers demand push payments in order to protect their payment credetials, I am skepitcal that anyone would bear the enormous development costs the a push payment system would require.

    • Sean – I think the idea is that today’s authorization message, in a “pull” system, would be repurposed as the real-time notification to the merchant’s bank, and on to the merchant. I like to think of it as changing a question “Is there enough money?” to a statement “Money is coming”. Same message, so in theory could avoid huge development costs. Merchants and their banks are already setup to handle this in real time.

  5. A wonderful assessment and much needed discussion on one component of the modernization of payments, the push from consumer to merchant. Given communications connectivity enhancements with messaging standards and mobilization as a method for payment origination and receipt as articulated in this article, there appears to be little reason why payments shouldn’t be conducted in this manner, assuming payment participants involved with handling the payment transaction agree to bear the economic gains and losses from the change. Those changes to be determined based on transaction flow and design. However, treating a push payment and ignoring the authorization as a critical piece of a payment and treating it as a “check like” deposit doesn’t leverage the technological capabilities available.

    Ignoring, for the time being, the effects of the economic impacts on participants and focusing primarily on efficiencies of payment transaction flow with a push transaction, the following could provide push capability with authorization capability added to the deposit feature:

    1. Mobile payment origination from consumer to merchant for purchase of goods and services.
    a. Consumer funds authorization and account information stored on mobile device or consumer bank, and sent to merchant bank partner for payment delivery and, immediate or future settlement (dependent upon financial institution DDA settlement capability which in the US is not immediate).
    i. Requires security standards for authentication of consumer and consumer bank identity and account information.
    ii. Requires real-time connectivity for consumer and consumer bank account information.
    iii. Requires security standards for authentication of merchant and merchant bank identity and account information.
    iv. Requires real-time connectivity for merchant and merchant bank account information.

    The above addresses only the consumer to merchant payment transaction in this article with technological assumptions made based on the capabilities of the consumer mobile origination devices, consumer bank DDA system access capabilities, merchant receiving device and receiving bank DDA system access capabilities, in short, significant changes in the payments network infrastructure, thus the economics of the payments network infrastructure; much needed changes.

  6. Randy – the consumer instruction would go their bank, not to the merchant’s bank….

    • Carol, My assumption is the payment transaction is conducted in two parts, the first being the authorization for the payment sent to the consumer’s bank, and the second part being payment instruction for goods or services delivered to the merchant’s bank. If the payment is conducted as one unit of work, and the consumer’s bank handles both parts of the transactions, then you’re correct. I suppose this would be a design consideration with cost and revenue implications.

  7. Randy and Shawn bring up some good points. Pieces may be there, but to get this to work in a mass market is tough. Where is the network that delivers the purchase request from the merchant to the bank app (ie Zapp example)? Additionally, in today’s pull world, the merchant has a terminal to notify them of real time authorization. It would be a big change to reverse engineer a terminal, or to integrate to every POS system to deliver a message to the merchant that the payment is approved, merchant you can deliver the goods or service. In Zapp’s example, it looks like the bank and the merchant have to participate in its closed loop. Same with Dwolla.

    Even if the real-time settlement of funds could be solved in the near-term, matching an amount to pay between buyer and merchant and real-time notification to the merchant for the mass market seems further away.

  8. Debbie – I agree, there are lots of pieces that would need to materialize. One possibility is that the deposit into the merchant’s bank account (done in real time) triggers a real-time message to the merchant terminal “you’ve been paid”. Not simple, not in place today – but maybe a nice opportunity for a new bank service!

  9. Carol and Debbie,

    Debbie’s question: Where is the network that delivers the purchase request from the merchant to the bank app? Well, therein lie some of the challenges and the opportunities with the use of technology advancements confronting evolving existing payments networks or introducing new payments networks into the US market. The beauty of the newer Zapp, Dwolla, clearXchange, Paypal, and other payment networks, is the high level of modernization within closed payments networks schemes, such as mobile device and account integrity assurance among those financial institutions participating in those closed payments networks schemes, with the closed payments networks schemes resulting in a fragmentation of other payments networks participants through the US. The benefits of these newer payments networks are the effects of modernization and real-time features provided, such as consumer authentication, bank/account identification, account/ payment funding authorization, merchant bank/account identification, payment delivery and account posting and consumer/ merchant notification; all assumed to be provided real-time from mobile or web devices. The negatives are the potential confusion to the end-users of these newer payments networks; differences in their uses.

    What’s being developed by Zapp, Dwolla, clearXchange, PayPal and other payments networks organizations are brilliant examples of initiatives that operate independent of each other benefitting their payments participants, but don’t benefit those that don’t “join” their specific payments networks schemes. The varying payments networks methods do not provide a common core standard of processing, which should be provided, leaving independent peripheral payments methods open for creative consumer oriented presentation and features beyond payments, such as payments related applications on Smartphones, or other financial application products.

    The POS terminal challenge for payments posed by Debbie is an example that is not addressed easily in any of the payments networks schemes noted since most address Smartphone and Web origination payments networks, yet existing and future payments networks require processing characteristics supporting multiple origination devices.

    I may be veering a bit from Carol’s original article a bit, but the article has provided some impetus to improve payments networks with the goal of the US payment industry to ensure consumer and merchant account integrity across all payments networks, including all origination and receiving devices, and all methods of payment origination and receipt which may be accommodated through the use of common API’s supporting connectivity between all consumer origination devices, transmission methods, consumer origination connectivity, payments network processing, central bank communication (where applicable), consumer bank connectivity and consumer account DDA processing, merchant bank connectivity and merchant account DDA processing, and merchant payment capture devices with payment notification. A bit generalized for the purpose of this discussion and certainly a tall order, but, an opportunity with a collaborative effort required by all parties mentioned in this article where applicable, and other existing payments networks participants where applicable, with hopefully a common goal of a single cohesively structured “Core” payments network, with participating peripheral payments networks, where applicable.

    So, in answer to Carol’s predictions in the article, restructuring of the content of the goal could be that of outcome of desire, that being changes to “push” payments of “high”, with a major restructuring of the US Payments Network with ancillary peripheral payments networks making the other two changes, “consumer protections outside of network rules”, and “merchant device independence”, separate initiatives to be performed independent of the first change. Randy

  10. Peter Ehmke says:

    A look at the PSDII proposals of the European Commission could be instructive as to how a market based on push payments might be created. The proposal effectively would create a new type of regulated player (TPPS) with guaranteed access to my bank account via a standard interface to be prodduced by EBA (and herein lies the real challenge). The bank has to tell the TPP the availability of funds and has to irrevoccably initiate the transfer requests sent by the TPP on behalf of the account holder. The TPP would confirm that to the merchant. So this would create a standardised middle office structure with equal access to all and leave it up to the individual TPPs to create consumer and merchant value and attraction for their service.

  11. Peter, I did find some information on the web broadly describing the European Commission’s proposed PSDII methods and services, and roles of the third party providers. It’ll be helpful understanding possible alternatives to Carol’s suggestions for improvements in the US Payments Industry. Carol, thanks for initiating discussion with this important component lacking in today’s US payment systems’ infrastructure; a much needed fix for consumer and merchant, with cost and revenue impact TBD!

  12. Dave Birch says:

    When you add up all the components, push payments are also a lot cheaper overall.

    I suspect that the merchants will begin to incentivise consumers to switch to push. If you imagine the bastard child of Safeway Fast Forward and Vocalink’s Zapp, the tender choice will vanish into the app and the merchants will give double points for people who choose ACH push. Of course, whether the USA will have an FPS in my lifetime…

  13. Dave Birch says:

    “If I push a payment to a merchant, the merchant will want real time notification of the payment on their system prior to releasing goods to the consumer. ”

    This what (e.g.) Zapp and PingIt do.

    • Dave,

      The belief by many participants in the US payments industry is the move towards a Faster Payments System requiring real-time access to consumer and merchant accounts is not one worth the effort due to the cost and impact on existing and future business models negatively affecting revenue. I’m assuming your FPS abbreviation references Faster Payments System. The effort entails establishing communications and applications connectivity from a third party provider (i.e. Federal Reserve Bank or other) to all financial institutions and their accounting systems in the US servicing consumer and merchant accounts. The number of applications at these financial institutions requiring change to accept the necessary consumer and merchant requests to effect money movement for payments is significant. The enhancement and/or establishment of communications connectivity to financial institutions providing 24/7 effectiveness using telecommunications redundancy advancements, cloud infrastructure, and other techniques require significant effort as well. The effort towards implementing a FPS, in general, requires a firm commitment by all participants in the US payment industry, where applicable, requiring potential consolidation of accounting systems, communications connectivity, third party providers, and mandated standardization of security controls around Smarthphone and mobilization of payment transactions. A tall order, yes. Possible in our lifetime, you bet, if commitments are made in a reasonable timeframe. The challenge is how to obtain these commitments and who acquires these commitments and from whom. Alternative payment providers such as PayPal, clearXchange, Dwolla, et al, are preventing the development of a potential ubiquitous payment solution that could provide benefit to consumers and merchants, and other money senders and receivers. There are revenue models that could provide value to some participants in the US payment industry with an FPS, albeit ones shifting revenue gain based on models chosen with specific payment behaviors encouraged. Our country is positioned to engage in the development of a payment solution to partner with payment solutions globally and should with an FPS and new payments network, not just benefiting consumers and merchants, or generally, money movers, in its current direction, that being independent payment solutions with no common strategy, providing benefit to fragments of payments participants and their consumers and merchants, and other money senders and receivers. In short, many competing initiatives preventing significant changes in the US payments industry, but many compelling reasons to effect the required changes.

  14. Dan M says:

    ACH-type “push” is still quite rough. It requires the sender to know sensitive account info (name, acct #) for the recipient. And when the push request hits the receiving bank, they effectively have to pull funds from the sender, knowing the sender’s account info (or that of some intermediary).

    You have to look to bitcoin to see a pure solution to this problem. Payments are *actually* pushed, with neither sender nor recipient having to know the other’s sensitive info. The magic that allows this is public-key cryptography, which has been in use in other domains for decades (ie, logging into your bank account only with SSL). No other network payment system accomplishes this.

    • Dan- in an ACH “push”, you are right that the sender needs the recipients info. Various aliasing/directory solutions can help address that. But the receiving bank does not have to “pull” funds from the sender, or know their account info.

      • Dan M says:

        Gotchya… I can see how the message (“file”) from the sending bank could contain an auth token of some sort verifying the authenticity of the “credit funds to account xyz” msg. That’s still only as secure as the channel, though, unless the token itself is cryptographically signed. Apologies if I’m missing something obvious here (very possible 🙂 ) !

        In any event, bitcoin’s solution is far more pure and secure. I would expect its technological breakthroughs to ultimately be incorporated into various aspects of our payments fabric. Sensitive info, on any side of the transaction, no longer has to be transmitted, *or* stored by any central body (ie, hacking target).

  15. Carol – Hopefully the debit networks would succeed for establishing reach to financial institutions’ accounting systems in real-time. Lacking knowledge of the technical detail of their backend reach, assumptions made are changes would be required for subsequent reach into the heart of the financial institutions’ data centers for accounting applications’ systems’ access. Reuse of the debit networks as a participant in a payments network in the manner suggested should be considered for reach to “all” financial institutions’ accounting systems determined by cost, compared to alternative existing providers such as the Federal Reserve Bank, or new providers. With regard to Dan’s comments with Bitcoin; although Bitcoin has value in money movement due to its stealth construct, its value as a virtual currency is still wrapped in rigorous debate and is a solution yearning for global approval and questions with regard to its viability. I’d be reluctant to base a payment network industry standard entirely on Bitcoin, or any other virtual currency, but would certainly design in a manner to make room for its use. The bigger question is how do we, those interested in pushing ideas forward, gain consensus on a direction, and a drive decisions to make these decisions work?

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics