The Yin-Yang Of Tokenization, Vendors Now Splitting Into Two Camps

Written by Evan Schuman
September 23rd, 2009

In recent months, an encrypted laundry list of vendors has announced products in the so-called end-to-end encryption space and/or the tokenization arena. But this week added two key announcements into the mix, from Voltage Security and a combo rollout from First Data and RSA Security. The reason they’re key is that, for the first time, two of the largest players are offering true differences, ones that speak more to retail security philosophy than anything else.

These two rollouts—from very competitive interests—also happen to agree on something that signifies a maturation of the retail security space. They agree that PCI is likely to insist that retailers deploy some combination of some form of encryption and tokenization, a position that should end months of bickering between the end-to-end vendors and the tokenization vendors.

The philosophical differences come down to how retailers want to—or, more precisely, decide that they need to—interact with payment card data. For the last couple of years, the retail rallying cry has been that the card brands and/or acquiring banks are in a much better position to hold that cyberthief-attracting data than retailers. Getting rid of the card data, in theory, would make retailers less attractive to data thieves, might get them out of all of that nasty PCI paperwork and assessor arguments, and allow them to focus on selling stuff.

The approach from First Data and RSA is a service that takes the card payment information and converts it into a token and then stores the sensitive data in its system. The First Data argument is that this leaves the retailer with no sensitive card data and, therefore, far fewer associated risks and hassles. The position is that the burden of protecting that data is now lifted entirely from the retailer.

The Voltage approach is more of a software package (they like to call it a framework) that lets the retailer control how the data is tokenized, but it’s the retailer that stores and controls that data. The rationale here is that the retailer is the business that accepted the card, so the liability stays with the retailer. As long as the merchant is going to be held responsible, that chain might as well call the shots as to how that data is protected and controlled.

“What happens to the tokens if the provider goes bankrupt or gets acquired?” asked Wasim Ahmad, Voltage’s Vice President, Marketing. “They’re doing it as a service, which means that [that retailer’s payment] data will be off in a cloud somewhere. Putting all of the numbers in a vault paints a big target on them.”

Looming behind these philosophical debates is the PCI Council, which is expected to unveil its next version of the PCI guidelines in about a year. This version is almost certain to include guidance about how the council wants retailers to deal with encryption and tokenization. The key issue at play: Will the PCI Council consider a token to be within the scope of PCI? Is it payment card data that is merely masked? Is the fact that these tokens are made from real card numbers—and can easily be converted back into real card numbers at the retailer’s whim—going to be used to justify keeping tokens within scope? And, as a result, will retailers be forced to continue just as much of the paperwork as before?

Although the tokenization methods vary slightly from vendor to vendor, the tokens can’t be converted back through a key or an algorithm. But the software has a way of matching each token to the actual card number, for chargeback and other purposes. The vendors will argue that tokens should be out of scope. But that’s not likely to be an argument that the card brands or the PCI Council will find persuasive.

Let’s look at each offering a little closer.


3 Comments | Read The Yin-Yang Of Tokenization, Vendors Now Splitting Into Two Camps

  1. bill bittner Says:

    The only question about tokenization is “Why did it take so long?” The greatest vulnerability to customer card data occurs when it is in “clear text” format. The sooner it is encrypted, hopefully before it is first recorded, the more difficult it will be to steal. Tokenization based on a private encryption key that is unique for each retailer will reduce the vulnerability of data. Even if some programmer in a particular retailer figures out how to decrypt the data stored in their files they will not have the private keys of other retailers and be able to use customer cards anywhere but their own stores.

    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.

  2. Sid Sidner Says:

    There are many trade-offs between end to end (E2E) and tokenization (TOK).

    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 ( 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.

  3. Steve Sommers Says:

    There are two big hurdles that the Voltage will need to overcome — price point and PCI scope. This article was the first I saw the $65K price tag and if this is the case, it will make their solution only financially feasible for level 1 & possibly level 2 merchants. PCI scoping wise, a merchant hosted solution, in most cases, does not reduce the risk profile for the merchant since the cardholder data still resides at the merchant’s location. It may help some with specific applications, but overall it’s just moving the risk around within the merchant location.

    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.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.