[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
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.
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.