Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


11:00 AM
Pat Carroll
Pat Carroll
Connect Directly
E-Mail vvv

Tokenization: 6 Reasons The Card Industry Should Be Wary

VISA's new token service aims to provide consumers a simple, fraud-free digital payment experience. It's a worthy goal, but one that may prove to be more aspirational than functional.

If we have learned anything about payment technology over the past decade, it’s that there will always be a new technology or a new scheme that will be championed as a way to reduce the growing rise of payment card fraud. While we should be encouraged by progress on this front made by our payment industry cohorts, I believe the sheer size and complexity of the payment industry dictates that there will never be one silver bullet, one solution that will solve the payment security predicament we face.

One such example of this dilemma is the news about VISA’s newly launched tokenization effort, aptly called Visa Token Service, which aims to “offer consumers a broad range of simple digital payment options, while protecting their sensitive information from fraud.” While this is indeed a worthy goal, in practice, until harmonization is achieved, this may prove to be more aspirational than functional.

Simply put, data tokenization is a security process of replacing sensitive payment data (such as payment card details) with a non-sensitive equivalent (a token or “identifier”) that has no value in and of itself other than to link back to the sensitive data through a tokenization system. This system will work to replace the sensitive payment information found on payment cards (physical or virtual) with a "token," the rationale being that because tokens do not carry a consumer's payment account details (such as the 16-digit PAN -- permanent account number) they can be safely stored by online merchants or on mobile devices for e-commerce and mobile payments.

Because a primary objective of tokenization is to eliminate the need for sensitive payment card data stored at the merchant side, it can certainly make a very positive impact on one of the most pressing aspects of cybercrime: the ability of fraudsters to steal card data from merchants, as they have from Target and other retailers over the past year, including the newest victim, Home Depot. This can only be a good thing and is absolutely a step in the right direction. In effect, however, tokenization shifts the data risk to the processor/tokenization provider, as the card data still needs to be stored and held for merchant payment purposes (matching of token with card data) at settlement.

As an advocate for strong payment authentication and transaction verification, I support any security technology that can help protect the consumer from payment card fraud. While tokenization is definitely a worthy and solid step forward by reducing sensitive payment data proliferation, there's a number of issues that must be considered:

  1. Tokenization systems themselves become attractive targets for fraudsters, and the traditional security measures that the industry relies upon are inadequate to keep the hackers at bay.
  2. As it stands now, a lack of standards, certifications, and security best-practices mean that there will be many custom-built implementations, which will result in fragmentation that will cost the industry much for years to come.
  3. Token generating/processing will add additional cost to the processing of a transaction. This will likely be borne by the merchant but ultimately passed on to the consumer.
  4. Access to tokenization systems will typically require real-time access. Such tokenization systems will be centralized or stored within the cloud, which raises concerns about security, resilience, latency, and cost.
  5. Tokenization doesn’t address the card skimming/cloning problem (it is not an alternative to EMV).
  6. Tokenization doesn’t add any additional validation to the transaction over and above what is already in place today.

Clearly, to effectively address these and all future challenges, we need more coordination among all of the industry stakeholders. That is why I am encouraged by the actions of the Federal Reserve Bank of Boston Mobile Payments Industry Workgroup (MPIW), which recently formed a workgroup to tackle such issues.

In my view, the war against cybercrime and payment fraud will not be won with any single solution, but instead, only through industry collaboration and multiple layers of protection and verification that are employed through every step of transaction processing. True protection means layered defenses, all designed to frustrate and repel attackers.

Pat Carroll is the executive chairman and founder of ValidSoft, a global supplier of cybersecurity and transaction authentication solutions utilized by banks, financial services companies, and governments to secure and authorize payment transactions. He has more than 25 years ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Robert McDougal
Robert McDougal,
User Rank: Ninja
10/10/2014 | 3:52:35 PM
Re: Mobile Payments Industry Workgroup (MPIW)
Thanks for the link!


I fear you are correct, there isn't a silver bullet.  No single solution will put a halt to this problem.  I will go a step further and say that I don't think it can be completely eradicated, only mitigated through the concerted efforts of all players in the payment industry.
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
10/9/2014 | 1:58:35 PM
Re: Mobile Payments Industry Workgroup (MPIW)
Thanks for the link, Pat. I'm reposting it here since I have permissions for live links!

User Rank: Author
10/9/2014 | 11:12:32 AM
Re: Mobile Payments Industry Workgroup (MPIW)
Hi Marilyn, the Mobile Payments Industry Workgroup (MPIW), was convened in January 2010 by the Federal Reserve Banks of Boston and Atlanta through their Payment Strategies and Retail Payments Risk Forum groups. The focus of the MPIW is primarily to facilitate discussions among the industry as to how a successful mobile payments eco-system could evolve in the U.S. You can get more information on their web-site: http://www.bostonfed.org/bankinfo/payment-strategies/mpiw/index.htm. The Tokenization workgroup study would presumably have been carried out by a sub-committee of the MPIW. 
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
10/7/2014 | 2:32:22 PM
Mobile Payments Industry Workgroup (MPIW)
It is encouraging to hear about the MPIW out of Boston. Are they focfusing on tokenization or taking a broader look at the payments landscape?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...