Portals and Rails recently embarked on a series of posts on tokenization. In the first installment, we defined tokenization and distinguished between a merchant-centric enterprise tokenization solution and payment tokens generated as an issuer-centric end-to-end solution. In the second installment, we examined several different attributes of the issuer-centric end-to-end token initiatives currently under way and considered their impact on mitigating risk. In this post, we examine the shortcomings of end-to-end token initiatives and question if they are really a coup in mitigating risks in today's environment.

The goal of payment tokenization is to substitute sensitive data—such as account numbers, expiration dates, and security codes—that criminals can use to extract monetary value with surrogate values that lack monetary value. In light of the number and depth of recent data breaches, tokenization seems like a grand idea—let's get data that fraudsters can use out of the payment transaction flow and the merchants' systems.

But current uses for these end-to-end initiatives are limited to card-on-file transactions for in-app or e-commerce payments and mobile proximity payments. I know you have to start somewhere but, in the near future, only a small percentage of transactions will use tokenization. These end-to-end initiatives are solid solutions, but are currently extremely limited. Thus, there will be a continued need for the industry to use a variety of methods to fight fraud, including the merchant-centric enterprise tokenization solutions the first installment discussed.

And isn't the point of the significant EMV investment currently under way to mitigate risks associated with counterfeit cards using compromised card data? In other words, it should render compromised card data useless. But I am hearing the EMV naysayers claiming that, in an EMV world, data compromises will still take place and, while fraudsters may not be able to counterfeit cards, they can still use that data to shop on the Internet.

Those naysayers are correct.

But let's circle back to the use cases for the current issuer-centric end-to-end token initiatives. Is tokenizing payment data for card-on-file and mobile proximity payments really going to have a material impact on preventing card-not-present fraud? Are these tokenization efforts really the best solution for this challenge? It could be many years before we regularly use our mobile phones for proximity payments. I am confident that we will be using chip-enabled cards for a significant number of transactions within two to three years. Would it be wiser to rely on solutions that leverage the chip or other security features of cards? Or maybe it's time we realize that cards weren't designed for card-not-present uses and place a higher priority on the broader adoption of existing and emerging non-card-based payment solutions in a multi-layered security approach.

Unfortunately, I do not have the answers. But these questions and topics will certainly be discussed during the upcoming Securing Remote Payments conference that the Retail Payments Risk Forum and the Secure Remote Payment Council is hosting. If you are interested in attending, please reach out to us. We will be in touch with more details.

In the next installment in this series, we'll look at new security and operational risks introduced with these token initiatives.

By Douglas A. King, payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed