TOKENISATION – THE WAY FORWARD FOR WALLETS

By Dave Birch, Global Ambassador, Consult Hyperion www.chyp.com

At last October’s Money 2020 gathering in Las Vegas, there was much discussion about what is certain to be one of 2014’s most important trends in the retail transactions world: ‘tokenisation’.

Visa, MasterCard and American Express announced they have started co-operating on standards for tokenisation around digital wallets. This is big.

The idea is, essentially, that when you want to buy something, your digital wallet will generate a special ‘alias’ primary account number (PAN) and send this to the merchant. The merchant’s acquirer then passes this back and the issuer (or the scheme) replaces it with the real PAN for processing. By doing this, the merchants (and eavesdropping criminal hackers) don’t get to see the real PAN which should hopefully mean that a) there will be less card fraud and b) there is no need to store real card details in the handset where they may be attacked by criminals.

In Las Vegas the early discussion ranged from ‘weak’ tokenisation where limited use PANs run over the existing rails to ‘strong’ tokenisation (where the consumer’s identity in some form or other runs over old or new rails). I expect eventually the card schemes and others will adopt a long-term strategy to shift to strong tokenisation. I also expect that this will not be restricted to e-commerce. While it’s logical to allow people to continue legacy card use at POS for limited purposes we should also 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 authorize the transaction, which I do, irrespective of the relative locations of me and the retailer.

So how is tokenisation coming along? Well, Visa already has some experience with this with one of their Spanish issuers, Bankinter. The BankInter mobile app generates a token (in this case, a one-use PAN that is valid for a short time only) and passes this 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. The solution re-uses the existing rails so it is not especially expensive to implement.

It is hardly a new idea: one-use PANs have been around for e-commerce from the earliest days of web commerce but they are a hassle 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 they are a hassle for merchants because 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.

The Bankinter case study flags up a particular attraction for issuing banks in the mobile world. It means that the app does not need to use the Secure Element (SE) on the SIM (which is under control) because there are no real card details held in the app. People have been looking around for NoSE (No Secure Element) solutions for retail payments for a while, since it became clear that it was going to be harder than people thought for banks and mobile operators and schemes and handset manufacturers to co-operate in this field, the approach has been boosted by Google’s decision to open up Host Card Emulation (HCE) in Android 4.4 and by MasterCard’s and Visa’s endorsement of it. This means that apps in the handset can have direct access to the NFC interface in phones to emulate contactless cards.

This means that apps will begin to use NFC for convenience, not for security. A retailer and a bank, for example, might integrate payments via HCE into the retailers own app, bringing together Bluetooth Low Energy (BLE) and NFC to provide a seamless customer experience. You walk into the store and get personalised attention through the app – which now knows which shelf you are standing front of – and the app downloads a payment token from the bank via mobile, wifi, BLE or whatever. When you’ve finished shopping you tap and pay at the unmodified POS terminal using that same retailer app which now feeds the bank token to the POS across the NFC interface. An HCE/NFC/BLE world seems rather attractive from a consumer experience perspective.

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. Who knows how it will work. But we do know that tokenisation means that the mobile wallet world will see accelerated development in 2014.