The Payment Card Industry Data Security Standard (PCI-DSS) was created to to reduce credit card fraud by increasing the security measures used to protect cardholder data. From nearly the beginning of its introduction, the standard has been criticized for the expense associated with annual certification and for security that did not deliver as promised. These facts have caused various players in the payment industry to question whether the standard delivers value, given the investment required and the increasing number of data breaches reported.
Many conversations around options for security have suggested use of tokenization, which substitutes sensitive cardholder information with tokens. Since the tokens contain no cardholder or card data, they present no value to criminals. This technology improves the consumer’s level of trust and helps issuers avoid the expense associated with notification, loss reimbursement, and legal action.
Furthermore, by removing the need to store actual card details, tokenization may reduce the costs and hours associated with the compliance requirements. Finally, by eliminating the need to store sensitive information, a successful tokenization strategy could enable merchants to shift many business processes and IT systems to the cloud, realizing significant advantages in IT efficiency, costs and flexibility provided in that environment.
For tokenization to be possible, the organizations involved in payment processing need to make modifications to their existing systems.
Merchants: Tokenization requires merchants to substitute the PAN and expiry date information in their databases with token and token expiry date data. Tokenization allows for additional messages to be embedded in transactions, thus making it possible to increase merchant discounts. Merchants using on-premise token solutions will have more options for improving security and efficiencies in terms of infrastructure and change in business processes than those who use a tokenization service.
Token Service Providers (TSP): There are two major areas of setup for a TSP: infrastructure preparation and information preparation. Infrastructure preparations include setting up the token vault, firewall and strong access control measures. An encryption system for the vault, a token provisioning platform, and access APIs also need to be put in place. Information preparation involves defining and codifying token presentment modes for token-based transactions at the point of sale. In addition, supported domains with restrictions and controls, assurance levels and token BINs used to distinguish tokens from each other need to be established.
Merchant Acquirer/Processor: A merchant acquirer or processor first needs to select a TSP and register as a token requestor (TR). Once this step is taken, impacts for the merchant acquirer or processor include implementation of new token POS entry modes, token domain restrictions and controls, new token acquisition APIs, related exceptions, and token acceptance processes. Merchant acquirers and processors also need to reconfigure their PAN analytics strategy to accommodate the fact that post-tokenization data is segmented by domain.
Network: Payment networks typically play the role of a TSP. However, other entities in the payments supply chain can also apply to be registered as a TSP. Fulfilling this role requires networks to consider how they will distinguish tokens, what parameters they will use for token assurance, the domains to be provided (e.g., NFC only, contactless, e-commerce, CNP, merchant specific, wallet specific or combinations), and changes that need to be introduced to the merchant on-boarding to support token registration.
Issuer: Issuers need to make modifications to log the token / PAN mapping for transactions to allow merchants using tokenization to refer to a transaction using a token and not PAN. In addition, issuers may wish to consider alterations to authorization scoring.
