Perhaps the shift to the “something present” transaction is coming sooner rather than later

[Dave Birch] I read an excellent piece on Forbes called “Tokenization and the collapse of the credit card model“. It was written by Matt Harris from Bain Capital Ventures and he set out a key issue that is shaping the strategies of many of our clients right now, and shaping them from a variety of directions. The article was about Braintree’s introduction of a kind of sort-of-federated sort-of-tokenisation to the US online payments market. It’s a live play at the “something present” payment model that we been talking to our clients about for some time. Braintree are serious players: they have something like a fifth of the US cardholder population on file already (and a high proportion of the online active early adopters) and they have convinced some of their merchant base (e.g., Uber, LevelUp, HotelTonight and so on) to share their payment credentials. If you register your card details at Merchant A then you don’t need to re-register them at Merchant B. You have sort-of wallet in the cloud that is nothing to do with banks, schemes or the merchants themselves.

Truly, identity is the new money. But how does Merchant B recognise you as the shopper from Merchant A? They collect the “fingerprints” of your laptop or phone or whatever. Obviously, I would prefer a mechanism based on a more functional identity infrastructure, but this is an interesting place to start. Matt points out why not everyone in the marketplace might be happy with this combination of convenience and security.

This is horribly threatening for all of the incumbent players in the four party model: traditional acquirers, issuer and the networks. Plain vanilla merchant acquirers will struggle to compete with Braintree online and Square offline as their tokenized user bases grow. The issuers lose their ability to differentiate. Once tokenized and hidden, any given card product is far more vulnerable to being displaced, as the issuers have already learned from PayPal

[From Tokenization And The Collapse Of The Credit Card Payment Model - Forbes]

Matt then asks a killer question, a question I have asked issuers before now. How do you stay “top of wallet” when there is no real wallet? This is a fascinating topic, largely because no-one knows what the right answer is yet. There are people who work for card issuers who have a lifetime’s experience in forcing a product to top of wallet. They know exactly how much you have to spend, the mix between media and rewards, the right messages to get over. But for APIs? Given that consumers may no longer see the payment brand at POS (as I already don’t when I use, say, Hailo), how can you persuade them to select your bank, card, network, mobile payment service or whatever at setup time when they configure their retailer app? I did get involved in a discussion about this a couple of weeks ago, and one of the suggestions made was security: if consumers felt that your “network” was more secure, then they might be persuaded to choose it over alternatives. Maybe offering 2FA, for example.

71% of consumers would prefer a slower payment process with more rigorous security checks than a faster process with fewer checks.

[From The Paypers. Insights in payments.]

I wouldn’t. I couldn’t care less about card fraud as it’s not my problem. If some rapscallion books a weekend away with my card, it’s the airline’s problem (without 3D Secure) or the bank’s (with 3D Secure). Nevertheless, the idea of combining device and password to deliver a 2FA “something present” transaction is sound. It’s interesting to speculate, by the way, on what that device might be…

The watch can and should, for most of us, eliminate passcodes and passwords altogether on iPhones, and Macs and, if Apple’s smart, PCs: As long as my watch is in range, let me in!

[From The Apple iWatch | askTog]

The idea of competing for “first API” instead of “top of wallet” seems inevitable on current trends and I am very interested in what it means for the nature of competition. We’ve completed a detailed study of the API landscape for one of our financial services client last year, and I am well aware of the wide range of APIs that are out there, varying in functionality, “layer” and delivery (the quality of service and grade of service that sits behind the API itself).

While Braintree, Square et al work using card-on-file right now, in the not-too-distant future they will be using secure and functional APIs to obtain direct access to payment networks. You could see how in the UK, for example, these APIs would lead to retailers incentivising payment via Faster Payment Service (FPS) or ACH, perhaps direct-to-bill and other mechanisms suited to a particular purchases. So I buy all of Matt’s vision around this. And we already know that the retailers would prefer direct-to-bank solutions, which could point towards decoupled debit as the SP model of choice. The kind people at the Mobey Forum have invited me to give a keynote at their Mobey Day in Barcelona on 11th June, so I thought this might make a good subject for discussion and I’m putting together a few slides on “Apps, APIs and Authentication” to stimulate thought and debate.

If you want a case study, Africa (as in so many other payment-related initiatives) is a good place to look. Oltio (a joint venture between the MTN and Standard Bank in South Africa) has developed a mobile remote authentication payment product called payD, which allows a cardholder to authorise a debit transaction, using their bank PIN for authentication entered into their personal mobile phone. Well, you may say, “what’s so interesting about that?”. Phone plus PIN sounds pretty much like card plus PIN. And indeed it is, to consumers. But for a bank to allow consumers to enter their card PIN into a handset is a big deal, because mobile handsets are not approved PIN entry devices (PEDs) as far as Visa and MasterCard (and most other folks) are concerned. The fact that a bank has decided that the security infrastructure is good enough to allow customers to buy using conventional EMV cards plus offline PIN or using their phone app plus online (same) PIN is  big deal.

These are personal opinions and should not be misunderstood as representing the opinions of
Consult Hyperion or any of its clients or suppliers

These are the personal opinions of Consult Hyperion and its guests and should not be misunderstood as representing the opinion of its clients or suppliers. To discuss how any of the technologies discussed in this post can benefit your business, please contact Consult Hyperion.

Comments

  1. Matt Harris says

    dave, i’m a bit of a fanboy of yours and i’m honored you cited my blog and agreed with part of it. question for you: if the trend towards wallets and api-driven card credential access continues, what are the implications for visa/mc? seems like we agree that it will be challenging for issuers, but do the networks have anything to really fear?

    thanks,

    matt

  2. Consult Hyperion says

    You are much too kind Matt, but thanks. This too complicated for blog comments (!) but I think it is clear that some stakeholders (eg, retailers) would prefer a bank API that bypasses the networks. On the other hand, the networks are not stupid so they must be developing their API propositions right now with a view to offering to retailers value-added services.

  3. James Sherwin-Smith says

    Dave,

    One question from me regarding fraud being someone else’s problem, and somewhat related to Matt’s original article and follow-up question.

    “I couldn’t care less about card fraud as it’s not my problem. If some rapscallion books a weekend away with my card, it’s the airline’s problem (without 3D Secure) or the bank’s (with 3D Secure).”

    That’s a very credit card centric view in my opinion. As you reference later on, the wallet/payment could be funded by another method, say push payments via the ACH (e.g. FasterPayments in the UK).

    So my question: isn’t there a good chance that we’ll see a liability shift back to the consumer?

    Even in the case where an intermediary wallet is funded by a credit card (e.g. PayPal), some card companies drag their feet to honour consumer protection guarantees (e.g. Section 75 in the UK). For me, this is related to your previous post and my comment here: http://www.chyp.com/media/blog-entry/shades-of-grey#comments

    Back to the networks. From my perspective, at the simplest level, the card networks solve a many to many problem: they set an international standard that connects billions of consumers to millions of merchants via thousands of banks. Their future lies in their ability to continue in this role, by managing down the risk, cost and time in electronic payments vs any feasible alternatives. (Note that the networks help others manage risk, but don’t take a balance sheet position themselves.) It might be interesting to note that when EMEA banks were polled on this last year, networks were believed to be one of the top 3 beneficiaries of alternative payments.
    [Source: http://www.oliverwyman.com/advanced-and-mobile-payments-whats-stopping-you.htm ]

    I still think that there is a real threat to the networks, as the barriers to entry are falling
    - new technologies can build scale extremely quickly
    - real time payments via ACH are becoming a reality in national markets (UK FPS, Singapore G3, Australia RTP, …)
    - POS integration is easier as systems move from being standalone to being online/mobile
    - issuing banks have some capabilities in managing credit/fraud on current/checking accounts (over and above acquirers and networks) given debit cards: the challenge will be moving these capabilities off the card rails.
    - interchange (an incentive for issuers to use card networks) is under pressure (cf. anticipated EU regulation, recent JPM announcement)

    Interested in your views.

    James
    @26left

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>