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.
Part 1: EMV® Payment Tokenisation Specification Framework
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:
What is the EMV® Payment Tokenisation Specification Framework?
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:
- Describes the payment tokenisation ecosystem.
- Describes the entities within the payment ecosystem that perform functions in support of payment tokenisation and identifies potential impacts.
- Describes specific functions that can be used to enable payment tokenisation.
- Describes a common set of definitions, concepts, controls, and flexibility that supports payment tokenisation across different ecosystem models.
- Specifies the required, conditional, and optional fields associated with token requests, token generation, token issuance, token provisioning, and token processing.
- Identifies the necessary and common interfaces that support the payment tokenisation ecosystem.
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.
What is a Token Programme?
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.
What is a Token Service Provider (TSP)?
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:
- Generating and issuing payment tokens.
- Operating and managing the Token Vault (a database where the original PAN and its corresponding token are stored, along with other transactional data).
- Allocating tokens.
- Managing the token lifecycle.
- Managing the token-PAN relationship and de-tokenisation processes.
- Operation and administration of the underlying cryptographic platform for executing tokenisation functions.
- Maintaining the security of the token management environment in accordance with the PCI TSP standard, which will be discussed later.
What is a Token Requestor (TR)?
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.
What is a Token Vault?
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:
- The cardholder uses a device that supports the mobile wallet application and registers a card by entering the data into the application.
- The app sends the data to a Token Requestor (TR).
- The TR sends the data to the Token Service Provider (TSP) with which it is registered and requests the issuance of a new token.
- The TSP verifies the data with the card issuer.
- If everything is correct, the TSP records the PAN and links it to a new token in a secure database (Token Vault), along with the TR’s identifier, the token’s expiration date, and a set of additional security features known as the Token Domain, which include restrictions on the new token’s use in certain channels, use by a specific merchant or a group of specific merchants, a limit on the number of permitted uses, and cryptogram verification.
- The TSP notifies the application of the newly generated token.
- The application stores the generated token (Device Account Number (DAN) in the case of Apple Pay or Digitized PAN (DPAN) in the case of Samsung Pay) in a secure medium (Secure Element (SE) or Host Card Emulation (HCE)).
Use and Processing of Payment Tokens:
- The cardholder (in this case, the user of the digital wallet app) uses the payment app to present the payment token to the merchant from their device via any of the following channels:
EMV Contactless: If the payment terminal (Point of Sale – POS) supports contactless payments via NFC (Near Field Communication), the EMV contactless specification is used to transfer data.
Contactless MSD: If the payment terminal does not support contactless payments according to the EMV specification, the device can use contactless MSD (magnetic stripe data) mode, which emulates a magnetic stripe transaction. - The merchant sends the token and dynamic cryptogram data to the acquirer.
- The acquirer routes the transaction to the payment network, just as it would with a normal transaction.
- The payment network determines that this is a token and not a PAN, since the token has a specific BIN. It then routes the transaction to the corresponding Token Service Provider (TSP).
- The TSP validates the token, the associated cryptogram, the Token Requestor (TR) identifier, and the Token Domain usage restrictions. If everything is correct, it proceeds with de-tokenisation and sends the original PAN data to the payment network.
- The payment network sends the original PAN data to the issuer.
- The issuer validates the transaction using the original PAN data and sends the response to the payment network.
- The payment network replaces the original PAN with the payment token initially received and sends it to the acquirer.
- The acquirer notifies the merchant of the transaction result.
Part 2: PCI Token Service Providers (PCI TSP) Standard Explained
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:
- Token Vault Management.
- APIs that support any external interaction.
- HSMs that perform cryptographic key management functions for the Token Vault and other tokenisation services.
- Systems used to process token-related functions and data, including token data mapping, token metadata, token domain restriction data, and identification and verification (ID&V) data, etc.
%20Standard%20Explained.png?width=864&height=499&name=Part%202-%20PCI%20Token%20Service%20Providers%20(PCI%20TSP)%20Standard%20Explained.png)
What is the Token Data Environment (TDE)?
The secure, dedicated environment in which tokenisation services run is called the Token Data Environment (TDE), where PCI TSP controls are implemented.
What is the Relationship Between PCI DSS and PCI TSP?
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:
- Within the TDE, payment tokens must be protected in the same way as a PAN.
- Outside the TDE, payment tokens do not require protection and are not within the scope of PCI DSS.
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.
What Requirements Does the PCI TSP Standard Contain?
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
Who Can Assess Compliance Against the PCI TSP Standard?
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.
What are the deliverables of a PCI TSP compliance assessment?
As with most PCI SSC standards, a PCI TSP compliance assessment concludes with the delivery of two documents:
- PCI TSP Attestation of Compliance (AoC).
-
PCI TSP Report on Compliance (T-RoC).
How Long is a PCI TSP Assessment Valid?
A PCI TSP compliance attestation is valid for 12 months and must be renewed at the end of this period.
Is There an Official List of PCI TSP-Validated Entities?
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.
Subscribe to our Blog
David Acosta
Senior Cybersecurity Consultant with more than 20 years of proven record in the cybersecurity field, working on projects with Government agencies, banks, retailers, financial entities, telecommunication companies as well as some of the largest payment card processors around the world. His information security background includes consultancy and compliance assessments, audit, training, implementation of security technologies, design of secure architectures, policy development, among others. David is a Senior Member of the Institute of Electrical and Electronics Engineers (IEEE), and he currently belongs to Colombian Army Reserve Forces (Professional Reserve) as a Lieutenant. Mr. Acosta is the founder and contributing author of PCI Hispano (www.pcihispano.com), a specialized community portal in Spanish language covering Q&A of PCI SSC standards. He has written a lot of security articles in main Spanish information security magazines and ISACA journal, along with several security vulnerability advisories.
See All Articles