It's challenging to have a conversation about EMV cards—cards with chip technology—given their well-documented fraud-mitigating shortcomings, without diving into a conversation on tokenization. And these conversations just intensified with Apple announcing the use of tokenization with its soon-to-be launched mobile payment application. Tokenization of payment card data can provide an additional layer of security to EMV cards for in-person payments and mitigates fraud risks that these cards don't address in the non-face-to-face environment.
I recently spoke at a forum on EMV cards, where it became evident to me that there is a high degree of confusion in the payments industry, especially within the merchant community, about tokenization. Currently, multiple standards initiatives around a new tokenization framework are under way, so Portals and Rails is embarking on a series of posts on tokenization. In this first installment, we define tokenization and distinguish between tokens generated within the merchant's environment (an enterprise solution) and payment tokens generated as an end-to-end-solution. A future post will compare the various payment end-to-end tokenization initiatives that have been announced to date.
In the data security and payments environment, tokenization is the substitution of sensitive data with a surrogate value representing the original data but having no monetary value. For payment cards, tokenization refers to the substitution of part or all of a card’s PAN, or primary account number, with a totally randomized value, or token. A true token cannot be mathematically reversed to determine the original PAN, but a token service provider in a highly secure environment can subsequently link it to its associated PAN.
Tokenization of payment credentials has been around since the mid-2000s, driven primarily by the issuance in 2004 of the Payment Card Industry Data Security Standard (PCI-DSS), which defines merchant requirements for protecting cardholder data. Merchants historically stored PANs for a variety of reasons, including to use in settlement reconciliation, perform incremental authorizations, handle chargebacks, and identify cardholder transactions for loyalty programs. With tokenization, merchants can remove PANs from their data environment and replace them with tokens—and thereby reduce their PCI-DSS compliance requirements. However, this enterprise solution still requires that the PAN enter the merchant environment before the tokenization process taking place.
Under the tokenization initiatives currently under way from the Clearing House and EMVCo, a financial institution would issue a token replacing a cardholder's PAN to the person's mobile handset, tablet, or computer device before initiating a digital payment transaction. So the merchant, rather than receiving the cardholder's PAN for initiating a transaction, would receive a token value associated with that PAN, which would then be de-tokenized outside the merchant's environment to obtain the necessary authorization and complete the transaction. The merchant never has knowledge of the cardholder's PAN—and that is a significant difference between these tokenization initiatives and the enterprise solution related to handling payment credentials.
The Clearing House's and EMVCo's concepts for payment tokenization are similar in many ways, but they also have differences. A future post will delve into the end-to-end tokenization initiatives and consider the impact on mitigating risk in payment transactions.
By Douglas A. King, payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed