Dgwb blog white border

The payment schemes’ specification for “tokenization” are out. Now it is time for stakeholders to develop their strategies for cutting costs and, much more importantly, adding value.

One of the water cooler topics, as I believe they are called, at the excellent BAI Payments Connect in Las Vegas was tokenisation, which seems to have become bound up with the issue of Host Card Emulation (HCE) and the revitalisation of Near-Field Communication (NFC). The reason they have become bound up (when, logically, the two are quite separate: you can have HCE without tokenisation and you can have tokenisation with HCE) is because the two of them together form an attractive proposition for the payment schemes. Tom Noyes puts it bluntly.

Visa/MA prefer HCE to NFC hands down. It allows them to own the tokenization of cards in mobile. HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. The Networks ARE the TSMs.

[From HCE – Now the PREFERRED contactless approach | Starpoint Blog – Finventures]

This is all true. It does not, however, necessarily mean that mobile network operators (MNOs) are out of the loop. As I said at Mobile World Congress (MWC), just because the payment application isn’t in the Secure Element (SE) that doesn’t mean that the MNOs could not have other applications in the SE that third parties such as banks would want to use because they provide added value. An obvious example might be standardised FIDO clients that could use the low-level authentication capabilities built in to handsets (such as fingerprint readers) but shield service providers from the complexities.

Putting HCE to one side, though, I wanted to make a point about the complexity of tokenisation. It is hard. It is worth doing, absolutely. But it is complicated, and it is going to take some time to work it out. A couple of the banks I was chatting to in Vegas were asking why, so I thought I’d make a couple of general points to help organisations who are sketching out their strategy in this space now that the first draft of the specifications has been released (do yourself a favour and just skip to section 9.2 and go through the use cases!).

Many of the stakeholders want to tokens to be platform for adding value as well as reducing costs. The enhanced “customer recognition” capabilities of a mobile device a certainly a means to deliver reduced costs for the merchants, but for added-value tokens will have to provide something more than simple payment data along the lines of the alias PAN.This means the eventual standards will necessarily be more complex.

The new standard would include new data fields for richer transactional information to help improve fraud detection and expedite approval; consistent methods to identify and verify a user before issuing a token, and a common standard to simplify contactless and online transactions for merchants.

[From Visa, MasterCard, Amex mobile payments power play faces significant challenges – Mobile Commerce Daily – Payments]

Of course, we would all like these facilities at the in-store POS as well, which must be one of the things that that EMVCo (who have been handed the responsibility of co-ordinating the standard) are thinking about. It would be jolly helpful all round if EMV 2.0 or son-of-EMV provided a route to convergence so that the distinction between “card present” and “card not present” fades away.

“Payment tokens also include enhanced data fields to provide richer information about the transaction” said Christina Hulka, EMVCo Board of Managers Chair

[From Tokenization standard in the works – ABA Banking Journal]

These enhanced data fields might well include data coming back from the merchant (e.g., electronic receipts) as well as additional data going to the merchant (e.g., coupons) and you can see that this degree of integration could deliver a very appealing proposition merchants and consumers. So, as I said, complicated but worthwhile.

(There’s a further complexity with tokens. The tokens cannot be independent from the associated account. There are many reasons for wanting to link together tokenised transactions, so it is not just a matter of generating tokens and leaving it at that. Suppose I buy something with token and then I want to take it back to return it? How can the retailer know whether my card was actually linked to the token they saw? For this reason, token transactions need to carry some incomplete information about the associated card. In the current specification this is the last four digits of the PAN.)

Managing all of this is going to be complicated and it has to work right every time at population scale. We’re working hard with our clients to help them to develop the most appropriate strategies to their needs and then set out practical tactics to execute them, but it’s going to take time to get everything in place and on a roadmap going forwards.

Leave a Reply


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.
%d bloggers like this: