Category: Tokenization

EMV Payment Tokenisation Framework

Also known as: EMV Payment Tokenisation Specification, EMV Payment Tokenization Specification — Technical Framework, EMV Tokenization 2.0

Simply put

The EMV Payment Tokenisation Framework is a specification, published by EMVCo, that describes how a payment card's real number can be replaced with a substitute value called a payment token for use in transactions such as mobile and e-commerce purchases. The goal is to keep the actual card number out of the transaction flow so that, if the token is exposed, it is less useful to an attacker because its use can be restricted. It is a framework for how tokens are created, delivered, and processed across the payment chain, not a single product or a guarantee against fraud.

Formal definition

The EMV Payment Tokenisation Framework, defined by the EMV Payment Tokenisation Specification – Technical Framework (with Version 2.0 published in 2017), specifies the roles, data elements, and processes for replacing a Primary Account Number (PAN) with a payment token whose usage can be restricted (for example, by domain, channel, or merchant). Per the evidence, it addresses token issuance, provisioning, presentment, and processing so that a payment token can flow from point of purchase through the acquirer and across the payment network in place of the underlying PAN. As EMV payment tokenisation, this is a distinct scheme-oriented tokenisation model and should not be conflated with other tokenisation approaches or with encryption, truncation, masking, or hashing, which transform or reduce data differently; the effect of any tokenisation implementation on PCI DSS scope depends on the specific implementation and validation, not on the label alone. Note also that EMVCo maintains this specification and that terminology, versions, and technical details should be confirmed against the current published specification.

Why it matters

Payment credentials that flow through mobile wallets and e-commerce checkouts are attractive targets because a captured Primary Account Number (PAN) can potentially be reused across many merchants and channels. The EMV Payment Tokenisation Framework matters because it describes a scheme-oriented way to keep the actual card number out of the transaction flow, replacing it with a payment token whose usage can be restricted (for example, by domain, channel, or merchant). If a restricted token is exposed, it is intended to be less useful to an attacker than an exposed PAN, because its acceptable use is constrained.

The framework also matters because it provides a common blueprint. Rather than each participant inventing its own token model, EMVCo's specification defines the roles, data elements, and processes for token issuance, provisioning, presentment, and processing so that a token can move from point of purchase, to an acquirer, and across the payment network in place of the underlying PAN. This shared structure supports interoperability across the payment chain, which is a practical prerequisite for tokenisation to work at scale in mobile and e-commerce transactions.

At the same time, EMV payment tokenisation is a framework, not a single product and not a guarantee against fraud. It is one scheme-oriented tokenisation model and should not be conflated with encryption, truncation, masking, or hashing, which transform or reduce data differently. Its effect on PCI DSS scope depends on the specific implementation and validation, not on the label alone, so teams should confirm details against the current published EMVCo specification rather than assuming a fixed outcome.

Who it's relevant to

Payment processors and acquirers

Processors and acquirers handle tokens as they pass from the point of purchase across the payment network, so they need to understand how token provisioning, presentment, and processing are defined in the framework and how a payment token substitutes for the underlying PAN in the transaction flow.

Security engineers and architects

Engineers designing mobile and e-commerce payment flows use the framework to understand how PAN replacement and usage restriction are intended to work. They should distinguish EMV payment tokenisation from encryption, truncation, masking, and hashing, and validate the specific implementation rather than relying on the tokenisation label alone.

Compliance and PCI DSS assessors

Compliance officers and assessors care about how a tokenisation implementation affects PCI DSS scope. Because that effect depends on the specific implementation and validation rather than on the term itself, they should confirm both the token model and the governing PCI DSS requirements against the current published standards.

Merchant risk and fraud teams

Merchant risk and fraud teams benefit from tokens whose usage can be restricted by domain, channel, or merchant, which is intended to reduce the usefulness of an exposed token. However, tokenisation is not a guarantee against fraud, and it does not by itself address the range of fraud types teams must still monitor.

Inside EMV Payment Tokenisation Framework

Payment Token

A surrogate value that replaces the Primary Account Number (PAN) for use in specified payment contexts. Unlike a PAN, a payment token is issued within a defined token domain and is intended to be usable only under the conditions bound to it. It is distinct from encryption or truncation because it substitutes the underlying value rather than transforming or shortening it, and its effect on PCI DSS scope depends on implementation and validation, not on the label.

Token Service Provider (TSP)

The entity that generates, issues, and maintains payment tokens and manages the mapping between the token and the underlying PAN. The TSP typically operates the vault that holds the token-to-PAN relationship and performs de-tokenisation for authorised requestors under defined controls.

Token Requestor

An entity registered with a token service to request tokens for a defined use case, such as a mobile wallet, merchant, or acceptance solution. Each requestor is identified so that tokens can be scoped to the requestor and its intended domain.

Token Domain and Domain Restriction Controls

Parameters that constrain where and how a token may be used, for example limiting it to a specific channel, merchant, or transaction type. Domain restrictions are intended to reduce the usability of a token if it is exposed, though they do not by themselves eliminate fraud risk.

Token Vault

The secure repository maintaining the association between payment tokens and their corresponding PANs. Access to the vault for de-tokenisation is limited to authorised parties under defined controls. The vault holds cardholder data (the PAN) and remains subject to applicable protection requirements; it must not be used to store sensitive authentication data after authorization.

Token Assurance and Identification & Verification (ID&V)

Processes performed at or before token provisioning to establish confidence that the requestor is entitled to use the underlying PAN. A token assurance level reflects the strength of this verification. ID&V addresses provisioning-time risk and is separate from transaction-time authentication controls such as EMV chip authentication or 3-D Secure.

Token Cryptogram

A transaction-specific cryptographic value that can accompany a token to help demonstrate that the transaction originated from a legitimate, provisioned token instance. It is intended to help reduce replay and unauthorised use, but it operates at a different point in the flow than cardholder authentication mechanisms.

Common questions

Answers to the questions practitioners most commonly ask about EMV Payment Tokenisation Framework.

Does EMV Payment Tokenisation replace the encryption of cardholder data?

No. Tokenisation and encryption are distinct techniques that transform data differently. Tokenisation substitutes a Primary Account Number (PAN) with a payment token according to the EMV Payment Tokenisation Framework, whereas encryption applies a reversible cryptographic transformation using a key. A token issued under the framework is not simply an encrypted PAN, and deploying tokenisation does not remove the need to protect data in transit or at rest through encryption where applicable. The two are often used together, and their respective effects on PCI DSS scope depend on how each is implemented and validated, not on the label alone.

Does using EMV payment tokens eliminate payment fraud or by itself take a system out of PCI DSS scope?

No. EMV payment tokenisation is intended to help reduce the exposure of the underlying PAN and may mitigate certain risks associated with storing or transmitting account data, but it does not eliminate fraud. It addresses a specific point in the transaction and does not, on its own, address risks handled by other controls such as EMV chip authentication, 3-D Secure, or multi-factor authentication. Any effect on PCI DSS scope depends on the specific implementation, the data actually handled, and how that is validated against the current published standard, rather than on the presence of tokens alone.

What roles are involved when implementing the EMV Payment Tokenisation Framework?

The framework describes roles including token requestors, which request tokens for a defined use, and token service providers, which generate and manage tokens and maintain the mapping between a token and the underlying PAN. Implementations should clarify which entity performs de-tokenisation, how domain controls constrain where a token may be used, and how these roles interact with your acquirer, processor, and the relevant card networks. Responsibilities and available services vary by provider and by card brand rules, which should be confirmed directly.

How does a payment token relate to the token domain restriction controls?

Under the framework, a payment token can be bound to a defined domain of use, so that controls limit the channels, merchants, or transaction types in which the token is valid. When implementing, teams should define the intended domain, confirm how the token service provider enforces those restrictions, and validate that a token intended for one channel is not accepted outside its defined domain. The specific domain control capabilities available depend on the token service provider and applicable network rules.

How should teams treat sensitive authentication data when adopting tokenisation?

Tokenisation of the PAN does not change the rule that sensitive authentication data, such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be stored after authorization, even when encrypted. Implementers should confirm that introducing payment tokens does not create a pathway that retains sensitive authentication data, and should keep tokenisation of cardholder data separate in their design from the handling of authentication data. Confirm applicable storage controls against the current published PCI DSS.

What should be validated before relying on tokenisation to reduce PCI DSS scope?

Teams should map exactly where cleartext PAN enters, exists within, and leaves the environment, and identify every system that can de-tokenise or that stores the token-to-PAN mapping, since those systems typically remain in scope. Any scope reduction should be assessed against the current published standard and confirmed with your assessor or acquirer, because the effect depends on implementation and validation rather than on the use of tokens. Requirement wording and numbering differ between PCI DSS versions, so confirm against the version in force.

Common misconceptions

Payment tokenisation is the same as encryption, so the two terms can be used interchangeably.

Tokenisation substitutes a PAN with a surrogate value maintained through a mapping in a token vault, while encryption transforms data using a key that can reversibly recover the original value. Truncation, masking, and hashing are further distinct techniques. Each reduces or transforms data differently, and the impact on PCI DSS scope depends on the specific implementation and how it is validated, not on which term is used.

Using EMV payment tokens removes all cardholder data from scope and eliminates fraud.

The token vault still maintains the token-to-PAN mapping, so PAN as cardholder data continues to exist and must be protected under defined controls. Scope reduction depends on where PANs are present and how the environment is validated. Tokenisation is intended to help reduce the value of exposed data and constrain misuse, but it does not by itself prevent or guarantee the elimination of fraud.

A payment token and its domain controls provide the same protection as cardholder authentication.

Domain restrictions, token assurance/ID&V, and token cryptograms address provisioning entitlement and constrain token usability, whereas EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in the transaction. These controls are complementary, and no single one should be relied on to address all fraud vectors.

Best practices

Treat any PAN retained in a token vault as cardholder data subject to applicable protection controls, and never store sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, or PINs/PIN blocks) after authorization, even when encrypted.

Do not assume tokenisation alone removes a system from PCI DSS scope; document where PANs and tokens flow and confirm scope reduction through validation appropriate to your implementation and the current published standard.

Apply and regularly review domain restriction controls so that tokens are limited to their intended channel, merchant, or transaction type, reducing usability if a token is exposed.

Establish ID&V and token assurance processes at provisioning that match the risk of the use case, and record the assurance level so downstream decisions can account for verification strength.

Combine token-level controls with appropriate transaction-time authentication (such as EMV chip authentication, 3-D Secure, or strong customer authentication) rather than relying on any single control, and monitor for false-positive and false-negative trade-offs.

Restrict and log de-tokenisation access to the token vault to authorised requestors only, and confirm which specific standards and card brand or network rules apply to your deployment, since requirements and rules vary by version and region and change over time.