PCI tokenization: Vendors need to iron out differences, expert says

The PCI Council has issued its long-awaited guidance supplement addressing the use of tokenizationtechnology to eliminate primary account numbers from merchant systems. Despite the release ofthe report, the tokenization market continues to be plagued with a number of problems, according toUlf Mattsson, chief technology officer of Stamford, Conn.-based tokenization vendor Protegrity Inc.Mattsson said a myriad of token formats have created vendor lock-in, limiting the ability ofmerchants to change systems or use multiple payment processors. Other tokenization systems havescalability issues and cant work with other forms of sensitive data types, Mattsson said.

There was a lot of turmoil that delayed the finalizing of the document.

Ulf Mattson, CTO, Protegrity Inc.

Mattsson, a member of the PCI tokenization special interest group, which helped develop therecent PCI tokenization guidance document, PCITokenization Guidelines, (.pdf) said it took about a year to work out the details of thedocument. Tokenization vendors have long disagreed on a number of details including the supportedtoken formats and the methods used to create tokens. In this interview, Mattson explains that thePCI guidance document is a good first step, but the industry needs to iron out longstandingdisagreements before the technology is wholeheartedly adopted.

How significant is the new PCI guidance document on tokenization?

Ulf Mattsson: I think its much needed. Its a little bit late. Its the first acknowledgementfrom the council about tokenization and its only the first step on the path of validatingtokenization from a PCI point of view. We need to add a lot more steps beyond this supplement.Unfortunately, the supplement contains a lot of disclaimers. The council and the major card brandsadded the disclaimers at the last minute. The council also has no plans to create any certificationat this point.

How difficult was it to come up with a working document?

Mattsson: It was very difficult, even though Visa was able to put out recommendations about ayear ago. The council said it wanted to take the lead because there were a lot of disagreements.There was a lot of turmoil that delayed the finalizing of the document.

What is missing from the document?

Mattsson: I think in the final stages a lot of controversial issues were left out.  [Theguidance document] is starting to give some weight to the technology, but it adds more questionsthan we had before. I think its missing the vendor lock-in issue. When you start to dotokenization its much harder to replace tokens. For example, if you do tokenization with anoutsourcing partner or a payment gateway, you are really stuck with that partner.  Thesetokens are highly customized and theyre all over your applications and databases. They aresometimes deeply integrated into your applications because some applications will not tolerate thetoken format, so there has to be some customization and translation. There should be some wordsabout that lock-in aspect in the document.

Why havent the vendors in this market been able to come together and create an industrystandard to enable companies to change token providers?

Mattsson: Im working in the ASC X9 standards body thatis now addressing tokenization. Were moving in the right direction, but some vendors are pushingtheir model. For example, one vendor is using a form of encryption and they call it tokenization.Thats an extreme example, but weve seen progress. Both Visas best practices and the PCICouncils supplement clearly said is not an acceptable way of generating a token if you want to beout of scope. The council said that is simply an encrypted [primary account number] and anencrypted PAN is within the PCI scope.

What are some other issues holding up standards?

Mattsson: There are other controversial points about outsourcing tokenization. Some vendors arearguing that if you outsource your tokenization, you really have a vendor lock-in situation. So howcan you do this if you need two payment gateways? How can you deal with switching from one paymentsolution provider to another? Larger merchants want to have that function in-house. If we look atupcoming data breach regulations, its not just about the PAN. This is an issue about PII data, PHIdata and cardholder data and they have similar needs to tokenize many of those data types. The onlymodel that will work for them is to have the tokenization server in-house.

The guidance document says theres a possibility to reduce scope with tokenization, but, asyou say, there are a lot of disclaimers. How do you adequately segment components from thetokenization system and the cardholder data environment?

Mattsson: If you take the disclaimers out for a second you see that simply your token serverneeds to be segmented. If you have an in-house tokenization server, you need to put that into aseparate network segment. That is how many QSAs are looking at what is in scope and out ofscope.