Tokens, For You, From Issuers

Tokenisation is evolving. What started as a merchant-side technology for protecting cardholder details has morphed into a network centric solution for protection of card transactions. The next step will be to move to issuer-side tokenisation but that’s only a partial solution; ultimately tokens will be owned by consumers, and how they’re used will be for the consumer to decide. Merchant tokens were a step forward in security and network tokens opened up digital transformation of payments issuer tokens but it will be personalized issuer tokens that really change the landscape for digital transactions.

Today payment tokens suffer the burden of a payment system legacy. In existing card payment schemes PANs are not just card numbers, they’re proxies for cardholder accounts and, ultimately, proxies for cardholders. When PANs are replaced by tokens this breaks these links and exposes them as the separate use cases they really are. Why should I, as a consumer, give a merchant my personal details in order to make a payment? Why should my bank account details be shared with PSPs and acquirers and other third-parties in the four party payment model just so they can track my behaviour and manage my risk?

Historically merchant side tokens were simply a way of scrambling PANs so that they weren’t sitting around in databases where hackers could scrape them and use them for making card transactions. In face to face use cases across most of the world we solved this problem by using EMV, where simple possession of the card details wasn’t enough to make a payment. Unfortunately we solved this problem just as the world went online, where using EMV was at best difficult and at worst impossible. So finding ways of protecting PANs in merchant-side databases became important, which is where the idea of tokens came from.

However you can’t transact with a merchant token, it’s simply a safer way of storing card details, albeit one that can be used across different merchants if it’s supported by their common acquirer or PSP.

To transact using tokens we needed networks or issuers to be able to generate tokens and recover them on the fly in the middle of a transaction. And these tokens offer real advantages for all parties, because a network token can express all sorts of constraints that a PAN cannot: transact today only, transact only in New York, no adult purchases, transact at this merchant only, transact using this device only, etc, etc.

It’s easier for networks to do this than it is for issuers because, it turns out, PANs are used for all sorts of important network side functionality like billing, chargebacks, risk and fraud management. In fact, using payment tokens causes all sorts of problems for all parties involved in the 4-party model because, by an invisible process of scope creep, PANs have been co-opted for all of these things; so dematerialising the PAN into a token breaks all sorts of processes. Which is why we’ve now got the Payment Account Reference (PAR) being added to network messages as we inexorably add layer upon layer of patches to the existing networks to keep them running.

But under new-style push payments, which we’re already seen be successfully employed in Europe and Asia and which will shortly become insanely popular in Europe due to the European Commission’s PSD2 regulation, due to be implemented by an issuer near you by January 12^th 2018, I no longer need give my PAN or any proxy of my account to a merchant in order to make a payment. I will, instead, authenticate myself to my issuer who will provide an identity token to the merchant, which the merchant can use to trigger a push payment. An identity token is pseudonymous, it doesn’t require me to provide my personal details to the merchant. If the merchant is anxious to find out personal information from me, in order to build loyalty or to sell my details to some online marketing company, then they’ll have to figure out some way of persuading me to do so separate from the payment transaction.

By analogy I could ask my issuer to provide anonymised identity tokens for any number of purposes that aren’t anything to do with payments. Obviously other parties could provide such tokens – credit reference agencies or government passport offices for instance – but as issuers already have to do the basics in terms of ID&V for KYC and AML then it’s an obvious extension to the set of APIs that they are surely already thinking about providing. And, of course, nothing stops networks or acquirers or PSPs or other parties from offering similar services.

Inexorably tokenisation is moving from being a niche, merchant side security technology into being a core, issuer side identity technology. The opportunity for issuers is huge, but if they don’t accept the challenge then there are plenty of other companies who’d be happy to take up the slack.