To me, the First Data/RSA approach has a much broader marketplace because it’s financially feasible for level 1-4 merchants and offloads much of the risk. Shift4 has been in the tokenization arena since the inception of the phrase so we have first hand knowledge of the hurdles that will need to be overcome for any company just stepping into the arena.

As this article points out, even within the TOK world, there is a difference between a hosted and an on-premise solution. Like all cloud computing, the sticking point always comes down to security, privacy, and liability. FDR [Editor's Note: We assume this is a reference to First Data and RSA Security] certainly has the ability to provide as strong a security for the token server as anyone, but what will they offer in a contract?

The key concern about TOK is the security of the token server and performance. The security issue is obvious, since it would be the motherlode of card data. The performance issue comes into play any time a client system needs to convert to or from a token. This would be similar to the performance characteristics of going to an external HSM for PIN processing, except the I/O path to token server might be much longer. It would all depend on how often the conversion was needed.

The key concern about E2E is the strength of the card data encryption algorithm. Typically, this is format preserving encryption (FPE) that uses a crypto algorithm like AES in a new mode. Several have been submitted to NIST (http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html) but none are yet approved, either by NIST or ASC X9. It would be terrible to widely deploy an E2E solution, only to find that the bad guys can crack it.

And finally, as the Smart Card Alliance pointed out, why spend a ton of money as a nation on new terminals and systems, when contactless EMV makes the card number worthless? And the main answer is that E2E or TOK can be done on a piecemeal basis, whereas EMV requires adoption by issuers, consumers, merchants, processors, acquiring banks, and the brands. Unless someone finds a value prop that pulls all those entities together, soon, E2E and TOK make the most commercial sense.

But both the approaches discussed here have their merits. While card data needs to be encrypted as soon as possible, the retailer has the need to encrypt other customer data they carry in their databases. Should every programmer be able to read customer names and addresses in their frequent shopper databases? A tool (or framework) that simplifies the management of public and private keys to support encrypting of various data elements would be helpful for everyone.