Tokenisation – Here We Go Again?

The concept of tokenisation has been around for centuries as a means to “reduce [the] risk in handling high value financial instruments by replacing them with surrogate equivalents.” The concept is simple, sound and proven, yet in today’s digital age, it raises questions that were previously not considered important, or even relevant. For example; If you need to tokenise something – an account number for example -, why do we expose those account numbers during a transaction in the first place?

The short answer is that we do NOT need to exposed account details, not with the dramatic advances in mobile phone authentication over the last 10 years. However, the reality is not that simple, in fact, the challenges faced by today’s organisations is enormous in both scale and complexity. From retail merchant, to acquirer, to issuer (especially the issuer!) cleaning up the detritus left by 50 years of card payments is a truly Herculean task.

But for 50+ years the global adoption of payment cards changed the course of payments forever, and did so in the right direction; away from cash. Despite the numerous benefits we have enjoyed from this non-cash pioneer, we now unfortunately see the cost of that success in the numerous and on-going data breaches involving millions of payments cards and BILLIONS of €/£/$ in fraud losses annually.

In the world of payments, even in 2015, the term tokenisation is synonymous with replacing a payment card (Visa, MasterCard, Amex, Chine Union Pay etc.) Primary Account Number (or PAN), with a token of less – or preferably no – value to an attacker. This is not a new concept, even for payment cards, as vendors have been providing tokenisation solutions for well over a decade, even longer in closed-loop payment environments.

So if solutions were available way back in 2005, why are there still countless billions of PANs floating around? The answer to this isn’t simple either, and it starts with the fact that there are at least three different types of tokenisation related to the surrogation of PANs:

  1. Acquiring / PSP / Merchant Tokens – “This token is created after the cardholder presents their payment credentials. ‘Acquiring Tokens’ may be used as part of the authorisation process, including card-on-file transactions.

    Note: These tokens were the first to be introduced, and represent a ‘distributed’ model. Providers must only maintain Payment Card Industry Data Security Standard (PCI DSS) compliance and potentially Payment Application (PA) DSS compliance (depending on the implementation).

  2. Issuer Tokenisation – “Also known as virtual card numbers or alternate PANs, issuer tokens are created by issuers to reduce risk in specific use cases (e.g. commercial card applications, and consumer-oriented services).

    Note: This solution can look almost identical to the Acquiring tokens.

  3. EMV Tokens – “Tokens compliant with the EMV Payment Tokenisation Specification – Technical Framework developed as a multi-scheme initiative by Visa, MasterCard and American Express and first published in March 2014. Ownership has now been transferred to EMVCo, who will take responsibility for further development of the framework going forward.”

    Note: These tokens were made available by the major card schemes beginning late 2014, and represent a ‘centralised’ model based on a specific standard; EMVCo’s ‘EMV Payment Tokenisation Specification’.

These solutions have their own benefits and drawbacks, depending on both your requirements and to whom you speak, but there’s one thing a tokenisation solution should NOT do, and that’s disrupt any legacy process. Loyalty programs, anti-fraud mechanisms, big data analytics and a host of others can all be tied to primary account numbers, and can all be broken if the token-to-PAN relationship is not maintained.

Perhaps the most obvious drawback of the EMV Tokens in particular is a direct result of one of its most significant security measures; a token can be assigned a ‘domain’, and only transactions in that same domain will be processed (an e-commerce token can only be used for e-commerce transactions for example). While this sounds logical, when you consider that an individual merchant can be a domain (Amazon for example), it’s obvious that just one card can have several or even dozens of assigned tokens. Every token costs the Issuers €0.20 for provisioning, then anywhere between €0.02 and €0.005 for ‘hosting and life-cycle management. An issuer who has just 5,000,000 tokens will be paying >€1M for up-front, then >€600K / annum to the Token Service Providers (currently just the card brands themselves).

It can be assumed that this cost will be off-set by the reduction in card fraud, but this further assumes an almost global adoption of the tokenisation service, and a seamless interface to the consumers. Consumers will simply not accept any additional complexity in the payment process.

So while the concept of tokenisation is a good one, it not only raises the question posed in the first paragraph; ”If you need to tokenise something why do we expose [those account numbers] during a transaction in the first place?”, the fact that tokenisation will be most prevalent in mobile transactions (like Apple Pay) raises a concept even more fundamental; why is there anyone in the middle?

A payment is a movement of value from one place to another, so it follow that there are only 4 stakeholders involved; the consumer and their bank, and the merchant and their bank, right? However, for a branded payment card transaction, you can add an Issuer (of the plastic), an acquirer (not necessarily your bank), potentially a Payment Service Provider (PSP) and of course, the card brand itself. All of whom take a piece of the transaction.

The card brands have performed this intermediary function for 5 decades, and their success was entirely justified. They put the trust into non-cash payments when none could possibly exist in a global market. Yes, there is fraud, fraud in the billions, but the volume of traffic across the card brand rails is in the multi-TRILLIONS.

Nothing could match the card brand’s acceptance, security and sheer ubiquity …until now. The smartphone we all take for granted has the capability to match the assurances represented by the card brand logos, all while bringing payments back to its original foundation; a representation of trust.

We are a long way from being able to disintermediate anyone in the current payments ecosystem, but tokenisation [for example] should only be seen as a patch on something broken as opposed to a solution in and of itself.

Anyone looking for solutions needs to learn to ask the right questions or their payment solutions will be out of date before they accept the first transaction.


How PCI Has Driven Innovation in Payments

If you came this far you did one of the following when you read the title:

1. Scoffed;

2. Screwed up your forehead in confusion, or;

3. Laughed.

Good, these all mean you’re cynical and therefore a perfect audience, so let me put you out of your misery; this is a story of unintentional cause and effect, and has started a trend that will not stop until credit cards as we know them are dead and buried.

About time too. 60+ year old technology in payments is akin to leaches in medicine (no offence card brands, but this analogy is particularly relevant).

When PCI was first drafted, it was very clear for whom it was geared; e-commerce organisations running Windows. How do you translate the configuration standard requirements (for example) to someone working on a mainframe. For Windows, you take out what you don’t need (hardening), for zOS, you build in only what you need. What about logging? Can syslog record everything you need in 10.2.X?

This is one of the most minor issues that drove organisations to seek alternatives to compliance, cost / effort / ROI, you name it, PCI is a burden any way you look at it. Yes, cardholder data should be protected, but enforcement of a single standard across all industry sectors and business types was never going to work.

At first, organisations became VERY creative in making their PCI burden go away. From outsourcing, to revamping all business processes in favour of truncated card numbers (except authorisation of course), to going back to cash only (not kidding). While almost EVERY merchant organisation should consider the first 2 anyway, it really didn’t help either retail, or e-commerce.

So the first foray into a technical ‘innovation’ was to make PCI go away for areas where they could not fix their systems to a degree that supported PCI compliance. Organisations started looking for alternatives to processing the full cardholder data; tokenisation was born (poetic licence, we’ve had forms of tokenisation for centuries). But this does nothing for authentication traffic which requires the fill account number.

Then came my personal favourite; Point to Point Encryption (P2PE), a.k.a. – and before the SSC decided to kibosh it – End to End Encryption (E2EE). The theory is very sound; encrypt the data for the point of interaction (usually a Pin Entry Device, or PED) all the way to the point of decryption, but the eventual PCI-approved solution is as complex as the DSS, limited (currently) to approved hardware devices, and requires a degree of certification few have even looked at.

A lot of organisations put their entire PCI programme on hold until such times as the P2PE standards were defined, and now that the first one (hardware/hardware) cannot apply to them, they continue to do nothing until such times as a hybrid standard is released.

So what you have here is; PCI forced the innovation, which in turn caused a justifiable delay in doing anything at all, which means that cardholder data is no better protected. Brilliant.

So P2PE, which had so much promise, is now stagnant. Organisations SHOULD have developed software solutions for legacy PEDs 3 years ago, which would have almost forced acceptance. But no-one did, and now it’s too late. How do you standardise a P2PE solution for an infinite number of scenarios? You don’t obviously, but with the advent of the next innovation, even PEDs themselves are becoming redundant…

We have the ultimate PCI and card brand killer; Mobile Applications / Mobile Payments. Still fairly new, growing exponentially – and to add the ultimate piece of irony – but cannot be PCI complaint unless the device was built for purpose. In other words, smart phones and tablets, by themselves, can never be PCI compliant. Not that this will stop their use.

Mobile payments, in all its forms, is already forcing the CARD BRANDS to innovate, or in the case of Visa, buy interest in vendors like The Square. But the SSC, as a standards only body, can never keep up. Eventually, as credit card numbers decline, so will the SSC and ALL it’s standards, and a replacement will be formed when people realise this massive drive for innovation has set us BACK in security…again.

That’s my final point of this blog; unless security is built in from the ground floor of this wave of innovation, the innovators will be directly responsible for the impossible-to-follow standards of the future.

As long as there are profit drivers, and Windows OS, I will always have a job…