First Data And RSA “Legitimize” Tokenization–Then What?

Written by David Taylor
September 23rd, 2009

Columnist David Taylor is the Founder of the PCI Knowledge Base and former E-Commerce and Security analyst with Gartner.

The conventional wisdom is that when large vendors enter a niche market, those vendors “legitimize” that market. But the announcement that First Data and RSA Security are getting into the credit card tokenization business raises many issues beyond them simply “making” the tokenization market. Here is my first take on the implications of this announcement:

  • Pressure On The PCI SSC To Embrace Tokenization
    The PCI Security Standards Council already commissioned Price-Waterhouse Coopers to do a study of tokenization, end-to-end encryption and other “beyond PCI” issues. The results will likely be discussed at the PCI SSC Community Meetings. That’s great. Merchants, service providers and even QSAs want specific guidance about tokenization. This announcement and the weight of the players in the market should virtually guarantee that tokenization will be specifically addressed in the next release of PCI DSS, in addition to QSA training and other guidance from the SSC.

  • Pressure On Payment Processors And Gateways
    I have said before that the number of companies offering tokenization will increase several-fold within a year. We’ve already seen about a dozen players enter the market in the last six months. I’m expecting 30 to 40 more announced packages over the next six months, as payment processors, gateways, encryption vendors and application vendors all vie to see who can remove credit card data from the merchant environment the fastest.

  • Tokenization Standards And Portability Will Be Hot Topics In 2010
    The more options in the market, the more the demand for “token switching” will increase. Merchants who have entrusted their card data to Service Provider X will increasingly seek shorter duration contracts and have more specific demands about how they migrate their data from one tokenization provider to another.

    Because there are not currently any standards for either the form of a credit card token, how it is generated or how one token type can be converted to another (they can’t, BTW), as more merchants realize this, they will raise concerns about being “locked in” to a particular tokenization approach. Smaller vendors will develop “token migration” or conversion tools, etc.

  • Multi-Channel Options And Other Complexity Issues Will Emerge
    One of the challenges for First Data, or any large processor that supports multiple payment platforms, is how to field an approach that works across all of these platforms. If a merchant is truly going to remove credit card data from its environment, it will have to do it across all the channels through which it does business–retail POS, MOTO (mail–E-Mail–order/telephone order) and E-Commerce.

    Because a typical large retailer is running all channels, including three to five different POS systems, implementing tokenization across all these channels and platforms will not be easy. There will be lots of tough questions, along the lines of “so, tell me specifically how you do this across platforms?” coming from merchants in 2010 and beyond.

  • Applications Integration Will Become Much More Important
    With large payment processors and security vendors in the market, application vendors will feel some pressure to support tokenization of all Personally Identifiable Information (PII), not just PCI data. I am expecting the major enterprise application vendors to seriously consider whether they are doing enough to help their customers limit the current pervasiveness of PII or any data that has value on the Black Market.

    The reason tokenization is so important (and even necessary) is because PCI and PII data are so pervasive that any long-term strategy should be addressed as an Application Data Management issue. I don’t see anything near term from the application vendors, but simple awareness of this issue would be an improvement.

  • Pressure On End-To-End Encryption Players To Add Tokenization
    I also expect this announcement will help speed the resolution to the “feud” between the end-to-end encryption and tokenization factions. These two options actually work very well together, as most of the players have admitted to me privately. Although today it may still be in their best sales and marketing interests to draw a dividing line, I do think the First Data/RSA announcement will help convince the players that both components are needed for a complete approach to get the data out of the merchant environment and keep it fully secure in the process of doing so.

  • The Bottom Line
    I could go on. A lot. But I figure that there will be a lot of interesting reactions coming out of this week’s PCI SSC Community Meeting and from others. If there is interest in doing more on this topic, let me know, and I can address some of it in my next column, after the U.S. Community Meeting. As always, if you’d like to discuss this, just visit the PCI Knowledge Base and fill out our “Contact us” form or just send me an E-Mail at

  • advertisement

    Comments are closed.


    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.