If your goal is to limit your PCI scope, should you pursue tokenization or end-to-end encryption? Or should you do both? I find it interesting that many large (L1 and L2) merchants are actively pursuing both options, and I’m wondering if that really makes sense from either a PCI or an economic perspective.
Maybe tokenization and end-to-end encryption are just two closely related approaches that can, when properly implemented, accomplish the same thing: minimize your total PCI scope. One thing is for sure, though: Either way, you will need to bring your checkbook.
Everybody wants to minimize their company’s PCI scope. When I look at scope issues, I generally classify systems into two broad areas. The first is the set of applications and network infrastructure in the payment transaction flow from the POS to the processor/acquirer and back. The second area of scope deals with post-transaction applications that use the data; for example, velocity checking/fraud systems, relationship management, delayed or split shipments, recurring payments, and chargeback and refund processing.
The best way to minimize PCI scope is to not store cardholder data (like the PAN) electronically--ideally, on any of your systems. Although I personally think this approach is possible, I understand that it is not always practical, given the post-transaction applications every retailer uses. Therefore, merchants are looking at a choice of tokenization or end-to-end encryption to get all that nasty cardholder data out of their PCI scope.
The first thing you need to understand is that you have to bring your checkbook. There is nothing too difficult about converting a PAN to a token--just replace the middle six digits with a sequence number, for example. Similarly, although it may take some work, you could encrypt your cardholder data using internal systems and processes. Unfortunately, the PCI Council effectively ruled out both options, saying that if merchants want to implement either of these technologies then they will have to go outside and buy them from a processor or a vendor.
The Council spelled out its reasoning in response to a question about when encrypted data could be considered out of scope: “However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” As I noted in an earlier StorefrontBacktalk column, the key question here is, what is an “entity?”
I don’t know the Council’s intent, but I can tell you that if “validated” means “validated by a QSA” then you can likely forget about the “entity” being a division or subsidiary of your company. To this QSA at least, if you want to use either tokenization or end-to-end encryption to reduce your scope then you are going to have to go to an outside, independent party—be it your acquirer or a vendor. It’s a bit like bringing your own popcorn to the movies; while it may make a lot of sense to you, it just isn’t allowed.
Let’s look first at tokenization, the process whereby, when properly implemented, the PAN may be rendered out of scope for PCI. Tokenization can, therefore, take much of the system and network in your transaction flow (the first area I previously mentioned) out of scope, so long as you do not have the ability to decrypt the tokens. Additionally, you should be able to use the tokens in your post-transaction systems (the second area) if the tokens are the same size as a PAN, you can link them to the same card and cardholder, and your processor or acquirer can use them to process chargebacks and refunds without further involvement from you. What’s not to like?
If we consider end-to-end encryption, we see many of the same potential benefits. It is designed to take the systems and networks in the transaction flow out of scope, and it can do this very well when the encryption takes place at or close to the POS. In a properly configured implementation only your processor (clearly an independent entity) can decrypt the data, so the data should be out of your scope. Additionally, if your encryption vendor can create tokens for you and those tokens can be linked to an individual payment card (two big “ifs”), you may eventually be able to take your post-transaction systems out of scope, too.
Clearly, I am glossing over some details. But this column is not intended to be a master class on encryption and tokenization. I have met with several vendors and I am a fan of both technologies (and I think the Council will be, too). Either approach can reduce PCI scope for merchants when properly implemented. The NRF Expo floor had vendors, processors and acquirers promoting their tokenization or end-to-end encryption solutions, so you have options. And more announcements will be coming soon.
What surprises me a little is how many Level 1 and Level 2 merchant CIOs are still looking at both options. It seems to me that after doing some homework and listening to a few presentations by competing providers, merchants should be able to settle on the technology and implementation that best meets their particular business needs. You will always have risks: Your vendor might go broke or (heaven forbid) be compromised. The technology may lock you into one vendor, thereby making any change difficult. If you get your solution from your processor, you may have difficulty changing processors or acquirers. And, lastly, the PCI Council may surprise us all and come out with some very specific guidance that complicates things for early adopters.
Having said all that, it seems like it is time for merchants--retailers, hotels, restaurants, universities, everybody--to evaluate these technologies and move toward a commitment to one or the other if it fits their business needs. What do you think? Am I being overly simplistic in considering tokenization and end-to-end encryption as near substitutes? Is the continuing analysis due to budget constraints? Do you prefer a vendor or a processor solution? Do you think the PCI Council will relent and allow merchants to pursue internal tokenization/encryption solutions that reduce scope? I’d like to hear your thoughts. Either leave a comment or E-mail me at [email protected].