If tokenization works for card numbers, why not use it for more?

In the wake of the massive data breach at Equifax, some are calling for tokenization of all data that has the potential to be stolen by fraudsters.

Payment tokenization is the process of replacing a primary account number (PAN) with a unique payment token that is restricted in its usage to a specific device, merchant, transaction type or channel. Broadening the use of tokenization would establish a defensive posture that the payments industry has been encouraging all to embrace. Though the payments industry has been using encryption for years, the use of tokenized payments data was kicked off with the launch of Apple Pay in 2014.

Amid this context, EMVCo, the technical body overseeing EMV chip standards and guidance, released the tokenization 2.0 specification last week with an eye toward applying payment tokens to more use cases in e-commerce, while also streamlining how tokens can be controlled in a single payments channel.

Chris Ratcliffe/Bloomberg

EMVCo published its version 1.0 technical framework in 2014 to address the needs of digital payments including e-commerce, and to minimize the fraud risk associated to an exposure of PANs.

"I’ve been advocating for quite some time that tokenization should be implemented for all sensitive data, not just payment card data," said Julie Conroy, research director and fraud expert with Boston-based Aite Group. "As we’ve seen from all of the health care breaches and the subsequent rise in application fraud, as well as all the credential breaches and the rash of account takeovers, there is a lot more data than payment card data that is valuable to organized crime rings."

Tokenization 2.0 clarifies a previous specification as a new standard in which merchants, acquirers and payment processors can link a cardholder's EMV payment token and PAN, thus setting rules for bank identification number controllers to implement payment account reference for their bank identification numbers (BINs).

The inclusion of a common set of definitions and terminologies sounds simple, but addresses the need to dispel confusion and delays in payments, said David Worthington, vice president of business development at Rambus, developer of a wide range of security products. Rambus operates as an EMVCo technical associate.

Such common language potentially sets the framework for tokenization to expand into other areas not related to payments. But EMVCo wants to start with all payment data being protected.

"We are always working toward an end-game where all payments, and even all data, are tokenized," Worthington said in a blog. "We need to get to a place where static tokens, like PANs, are no longer used and dynamic tokens are universal."

Tokenization 2.0 allows a token requestor to share the same payment token between multiple token users, generally merchants. This change has the potential to bring the fraud prevention capability of dynamic tokens to scenarios like one-click ordering and payment, and in-app payments, Worthington said.

“EMVCo has been working closely with the payments community to develop the technical framework to create a common functional baseline for payment tokenization solutions to achieve worldwide interoperability,” Jack Pan, EMVCo executive committee chair, said in a press release.

The latest version offers significant updates and use cases that reflect payments industry input to "define how EMV payment tokens are generated, deployed and managed," Pan added. "The level of detail assists in establishing a stable payment environment and delivering a common set of tools to facilitate transaction security.”

EMVCo indicated the upgrade strengthens mobile Near Field Communication transactions with a mobile device initiates a transaction at an NFC-enabled terminal, as well as card-on-file e-commerce when a merchant has payment token and related data stored in a merchant platform.

The new version also introduces a payment token assurance method that enables a token requestor, such as an issuer, digital wallet provider or merchant, to have information related to the identification and verification processes associated with the issuance of a payment token.

"One notable thing in the spec is the ability to request a token with a value other than the PAN," Aite's Conroy said. "I’ve spoken with a number of merchants who want to leverage various services offered by the payment networks, but they have architectural limitations that prevent them from presenting the full PAN."

The new tokenization version provides a lot more flexibility, and doesn’t punish those who were early adopters of various forms of tokenization, Conroy added.

"I also like the shared/limited use payment tokens that recognizes some of the unique dynamics of the various modalities of payment in e-commerce," she said.