Off the rails

[Dave Birch] A little while back, the always-interesting Tom Noyes raised an issue about "tokenization", a topic that is now (post-Money 2020) front and centre. Tom said that:

I am implying that banks could leverage their entire acceptance and authorization infrastructure without routing anything through V or MA.

[From Business Implications of Payment Tokens | FinVentures]

Tom's right. But, as I said at the time, let's not for one moment think that the folks at Visa and MasterCard are too dumb to have noticed this. Of course they have, and that's why they are working hard to develop propositions (e.g., wallets) that can deliver more value. Yes, bank tokenization could led to ACH-based solutions that bypass the schemes, but will they? Now we read that…

Visa, MasterCard and American Express want to overhaul global e-commerce security, ditching account numbers in favour of digital tokens for online and mobile transactions.

[From Finextra: Card giants bid to boost online checkout security with digital tokens]

Visa already has some experience with this, as I mentioned a few months ago when I wrote about BankInter's token-based approach to NFC. The BankInter mobile app generates a one-use PAN that is valid for a short time and passes this "token" to the merchant terminal. Since it is a standard PAN, it wends its way across the network back to BankInter, where it is converted back to the customer's debit PAN and authorised. Why bother doing this? Well, it means that the merchant (and the processor etc) never see the real PAN so it doesn't matter if it gets stolen, thus saving money on both fraud and fraud prevention. The solution re-uses the existing rails so it is not especially expensive to implement. This is hardly a new idea: one-use PANs have been around for yonks, but they are huge pain in the arse for consumers because they had to run something to generate the PAN, then copy it over to the whatever form you're filling out on the web. And there are other issues to do with refunds and so forth. But when a mobile app is doing it for them, consumers won't even know that it's not their "real" PAN that is being passed to the merchant.

This all sounds straightforward. Nevertheless we all, I'm sure, understand Tom's reasoning. When the first card network (Diners Club) was launched in 1949, the idea that there would be a free network connecting all of the consumers with all of the merchants and all of the banks was unimaginable (although not to science fiction authors – see Robert Heinlein's "Beyond This Horizon", for example) so it made complete sense to invent just such a network: by telephone and post, in the first instance, so that merchants would phone the network for authorisation and then send in their slips for payment. If you want to see how it worked behind the scenes in those days, check out the old Danny Kaye movie "The Man from Diner's Club" that I wrote about before. Magnetic stripes and automated authorisation, chip cards and 3D Security have made it all more efficient, but the basic concept hasn't changed. So, certain persons (e.g., merchants) say, why not? Now we have a network that connects all of the consumers and all of the merchants and all of the banks, so why don't we just use that? Why bother with Visa and MasterCard? Provided the consumer has some "token" to identify the relevant bank account, why can't they just give this token to the merchant and have the merchant go directly to the bank account to get their money?

One day soon, my Waitrose app will obtain tokens from my V.Me wallet, my MasterPass wallet, my PingIt app, my Zapp app and any other wallets it can find on my phone through a standard discovery process and standard API. Then when I check out at Waitrose, my app will pop up and take care of business. Maybe I will have configured my MasterPass wallet, which is where my John Lewis MasterCard will be stored, to allow the Waitrose app to charge £100 without additional authorisation.

Tom's right that this has significant business implications, which is why I was looking forward to his panel on the topic at Money2020. The tokens don't have to run over the conventional rails, which is why the schemes are moving to get a new standard in place quickly (and this is a good thing). So long as Waitrose don't surcharge, I will always have my app use my John Lewis MasterCard because I get cash back in John Lewis vouchers that I can use at Waitrose. I would always do this, rather than opt for the direct-to-bank payment mechanism, until such time as I am heavily incentivised not to. Tom says that

Each group is working to “lock out” others. Banks are working to lock up the ACH rails, V/MA are placing new network fees and controls, issuers are requiring tokens, retailers are locking up data and delivering financial services, MNOs are pushing SWP NFC.

[From Network War – Battle of the Cloud Part 4 | FinVentures]

Tom's point about ACH is an interesting one. Many industry observers have pointed out that a token front-end to ACH (either as a decoupled debit proposition or as a new low-cost bank-owned brand, like Zapp in the UK) might, given consumers' revealed preference for debit, being what many of the stakeholders would prefer. Except, of course, banks. They would (perfectly reasonably) point out that they have no incentive to move to this.

The network where banks have the most influence is ACH, yet they don’t want to encourage ACH use as there is no revenue.

[From Payment Tokenization | FinVentures]

Indeed. So there are two options: make them do it (rather like the Faster Payment Service in the UK), or couple ACH with non-payment revenue opportunities around data (the mobile wallet).

One final point about tokens for today. On Tom's panel, the discussion ranged around what I have taken to calling "weak" tokenization (ie, one-shot PANs) and what I have taken to calling "strong" tokenization (ie, the consumer's identity in some form or other). I will blog about this in the future, but I just wanted to note here that if the schemes were to adopt a long-term strategy to shift to strong tokenization, then I cannot see why this would be restricted to e-commerce. It would surely be logical to allow people to continue legacy card use at POS for limited purposes but to shift both card-present and card-not-present transactions to the "something present" model. Thus, as a consumer, I have the same payment experience whether in-store, online or via mobile. When I want to buy something, a message pops up on my phone asking me to authorise the transaction, which I do.