First Data's new PCI tokenization service

by Dave Howell on 9/22/2009

Today, First Data announced the new First Data Secure Transactions service. First Data’s service will provide merchants the encryption of cardholder data at the point of capture (e.g., POS), with encryption maintained through delivery to First Data (when decryption occurs in order to continue the transaction process). Here is where things get really interesting: rather than returning the actual card number back to the merchant, First Data returns a “token” value – data that represents the cardholder data (i.e., sixteen digits), but has no real value (because the “token” is not a real credit card number). And First Data maintains the original cardholder data in a secure, PCI compliant environment.

This is an important advancement for a number of reasons. First and foremost, it provides merchants with a roadmap for migrating away from the storage of credit card numbers. This, in turn, offers merchants the potential to become out of scope for PCI DSS compliance. The PCI DSS applies to all companies that store, process or transmit cardholder data. If a merchant no longer handles cardholder data in any of these manners, the PCI DSS should no longer apply.

In addition, the First Data Secure Transactions service provides merchants with a means of avoiding the expense associated with deploying encryption technology. I suspect this will be of particular interest to Level 2 merchants and below, as many of these organizations have neither the capital resources nor staffing expertise required to undergo an effective encryption project. First Data’s service requires no new hardware, and this will be particularly appealing given the budgetary restraints many merchants face.

Now, let’s be clear: RSA is certainly an advocate for encryption. Our BSAFE encryption technology is deployed in over a billion products worldwide. And we’ve done much work with merchants and others in the payments ecosystem to support PCI compliance, including cardholder data encryption. But while both encryption and tokenization provide protections for cardholder data, each also has very different implications for merchants.

Encryption, regardless of how effectively or comprehensively deployed (including end-to-end encryption) will not absolve a merchant from meeting the PCI DSS requirements. Because, encrypted cardholder data is still cardholder data. And, this data is still maintained in the merchant’s systems – meaning that the merchant would be responsible for meeting the full set of PCI DSS requirements. Encryption of cardholder data is certainly a valid approach and one many merchants have taken (particularly Level 1 merchants with mature IT security programs). But it is important to recognize that PCI DSS requirements will not be eliminated by simply applying encryption to cardholder data.

Tokenization, on the other hand, offers the ability to replace the primary account number (PAN) with another piece of data. So, the result is that the merchant may effectively remove cardholder data from its environment. If cardholder data is no longer present, the merchant would, in turn, no longer be subject to PCI DSS. So, if a merchant’s primary goal is to reduce the scope of PCI DSS compliance, tokenization should certainly be considered.

We do need to be pragmatic about this, as well. No one is suggesting that there’s tokenization pixie dust to be sprinkled about, and all PCI compliance challenges will evaporate. Clearly, there’s more complexity. A merchant would need to discover all legacy cardholder data, and either purge those data from the environment, or tokenize the information. This, in addition to the process of instituting tokenization for new transactions. But, tokenization and the First Data service is a marked step forward from what merchants have in front of themselves as options today.

This is the real point: providing merchants with options. Options for how they choose to protect cardholder data, and options for approaches that might lead them down the path of removing cardholder data from their environments entirely. At the end of the day, the latter path is one that many merchants will try to pursue, both as a means of scaling back PCI DSS requirements and as a key step in a comprehensive information risk management program.

This week is the PCI Security Standard Council’s Community Meeting in Las Vegas. I’ll be interested in hearing feedback that comes out of the meeting around tokenization, and whether merchants will begin to pressure others in the payments world to institute technologies that may further scale back PCI DSS implications.