One of the most effective mechanisms for minimising the scope of PCI DSS compliance while also reducing the exposure of the Personal Account Number (PAN) in any payment transaction is tokenisation.
Tokenisation is a fairly simple yet effective concept. It involves replacing confidential data with non-confidential data that maintains the same functionality. To illustrate this concept, think of casino chips. To play, you must exchange real money for chips (tokens), which are valid only at that particular casino. If someone steals them or tries to counterfeit them, their scope of action will be limited, since they cannot use them at other casinos. This restricts the attacker and discourages the crime, as the profit will be less than if it were real money.
Generally speaking, any sensitive data can be tokenised, including personally identifiable information (PII), financial data, information protected by patents or copyrights, etc. If the data to be protected is a PAN, there are three (3) types of tokens that can be used: acquiring tokens, issuer tokens, and payment tokens, each with a different format and functionality, as explained below:
| Acquiring tokens | Issuer tokens | Payment tokens |
| Proprietary token format defined by the entity that generates it (primarily by acquirers, but also by merchants or service providers). | Proprietary token format defined by the issuer. | Format defined by EMVco in the document "EMV® Payment Tokenization Specification – Technical Framework." |
| They can replace all or only part of the original PAN. | They replace the entire PAN with identical data. Merchants or acquirers that capture them cannot determine whether they are PANs or issuer tokens. | They replace the entire PAN. A unique BIN/IIN is used for this purpose. |
| Compliance with the Luhn algorithm is optional. | Compliance with the Luhn algorithm and other PAN validation rules is mandatory. | |
| Depending on the implementation, the token may overlap with the numbering of a valid PAN. | The token never overlaps with the numbering of a real PAN. | |
| They can be used for recurring transactions, one-click payments in e-commerce, and in-person payments. | They can be used for a single transaction (one-time-use/single-use (SU) only) or for multiple transactions (multi-use (MU)). This type of token is also commonly referred to as a Virtual Credit Card (VCC) or a Virtual Card Number (VCN). | They can be used to initiate both in-person and remote transactions. They must be used in conjunction with a Dynamic Token Cryptogram, generated exclusively for each transaction, and with a maximum lifetime to prevent replay attacks. |
| Their use is restricted solely to the entity that generates them (acquirer, merchant, or service provider). | Their use is limited to the issuer that generates them. | They can be used at any merchant and with any acquirer that supports the model. |
| Depending on the implementation, the token can be authenticated using the CVC from the original physical card. | Each token has its own associated authentication mechanism (CVC). | It allows for cardholder authentication using the techniques associated with the original physical card (CVV2, chip and PIN, chip and signature, etc.). |
Both payment brands and the PCI SSC have developed guidelines and best practices for generating, storing, and processing these token types. However, there is a standard specifically developed for the protection of payment tokens: the Payment Card Industry (PCI) Token Service Providers (TSP) standard.
To make this article easier to read, we have divided it into two parts: a first part containing general details on payment token operations, governed by the “EMV® Payment Tokenization Specification Technical Framework” document, and a second part describing the physical and logical security controls that must be implemented to protect that infrastructure, in accordance with the PCI Token Service Providers (PCI TSP) standard.
Before delving into the details of the PCI TSP standard, it is worth clarifying some technical concepts related to the EMV® Payment Tokenization Specification Technical Framework document, which establishes the fundamental criteria for payment token operations:
This document, developed by the EMVCo consortium, defines the roles, functions, and requirements that must be considered when introducing EMV payment tokens into an existing payment ecosystem, enabling these tokens to be used in a payment transaction from the point of capture to the acquirer and then transmitted through payment networks to the issuing bank.
This technical framework:
In order to globally identify each entity that issues payment tokens, EMVCo manages a TSP registration program (Token Service Provider Registration Program ), supplemented by the assignment of a specific 4-character code called a “BIN Controller ID” or “BCID” that allows each PAN to be referenced with a token.
A “Token Programme” consists of the policies, processes, and registration programmes related to the oversight of token service providers (TSPs) and token requestors within a payment system.
A Token Service Provider (TSP) is a role within the payment tokenisation ecosystem authorised by a token programme to issue payment tokens to registered token requestors.
TSPs are responsible for:
A “token requestor” is a role within the payment tokenisation ecosystem that initiates token requests. Each token requestor must register at and be uniquely identified, in accordance with the token programme’s policies and processes.
A “token vault” is a repository that maintains the established association between the payment token and the token’s expiration date, on the one hand, and the PAN and the PAN’s expiration date, on the other, and includes data related to the payment token, including other attributes of the token requestor that are determined at the time of registration and that can be used to apply Token Domain Restriction Controls.
With these concepts clarified, the following outlines the two data flows of a transaction involving a payment token: provisioning and usage:
Payment Token Provisioning Flow:
Use and Processing of Payment Tokens:
Probably one of the most interesting yet least well-known standards developed by the Payment Card Industry Security Standards Council (PCI SSC) is the PCI Token Service Providers (TSP) standard. This standard is currently in version 1.0, published in December 2015, and, as of the publication of this article, it has not been updated since then. The standard did, however, undergo a Request for Comments (RFC) period in 2023 and, according to the document “PCI Security Standards Council 2025 Annual Report”, its requirements are expected to be integrated with other standards such as PCI DSS, PCI 3DS, and the new Environmental Security Standard (ESS) in the medium term.
As such, the standard establishes the physical and logical security requirements, as well as the assessment procedures, for any tokenisation service provider that generates and issues EMV payment tokens, as stipulated in the EMV® Payment Tokenisation Specification Technical Framework, including the following activities:
The secure, dedicated environment in which tokenisation services run is called the Token Data Environment (TDE), where PCI TSP controls are implemented.
Given that a TDE performs tokenisation and de-tokenisation, the Personal Account Number (PAN) is integral to those transactions. This is why, if an entity stores, processes, or transmits the PAN, there must be a Cardholder Data Environment (CDE) to which PCI DSS controls apply.
As such, a TDE can be contained within a CDE, or the two can be combined:
TDE as a subnetwork of the CDE:
Combined CDE and TDE:
For this reason, PCI DSS compliance is mandatory for a TDE that meets the following criteria:
As such, the PCI TSP standard can be considered an additional layer of security controls on top of PCI DSS, complementing PAN security when processing payment tokens.
In addition to the 12 PCI DSS requirements applicable to TDE, the PCI TSP standard includes the following 7 control areas:
TSP 1 – Document and validate PCI DSS scope
TSP 2 – Secure TDE Systems and Network
TSP 3 – Protect and manage cryptographic keys
TSP 4 – Restrict access to TDE based on a business need-to-know
TSP 5 – Identify and authenticate all access to TDE systems
TSP 6 – Restrict physical access to the TDE
TSP 7 – Monitor all access to TDE
TSP 8 – Maintain an Information Security Policy
The PCI SSC has established that only P2PE Qualified Security Assessors (QSAs) who have received additional PCI TSP training may conduct PCI TSP compliance assessments.
Needless to say, the TDE must first be assessed for PCI DSS compliance, which may be performed by a PCI DSS QSA.
As with most PCI SSC standards, a PCI TSP compliance assessment concludes with the delivery of two documents:
PCI TSP Report on Compliance (T-RoC).
A PCI TSP compliance attestation is valid for 12 months and must be renewed at the end of this period.
As of the date of publication of this article, neither the payment brands nor the PCI SSC maintain lists of PCI TSP-validated providers.
For compliance verification purposes, the entity is required to submit its PCI TSP AoC.
At Foregenix, we support financial institutions that offer tokenisation services in achieving PCI TSP compliance through gap analyses and formal compliance assessments, as well as specialised support and consulting during the implementation and rollout of security controls.