Tokenisation and 3D Secure get bundled into the same conversation often enough that the distinction between them, and how they need to work together, gets lost. Tokenisation replaces a Primary Account Number (PAN) with a surrogate value so the real card number is rarely exposed. 3DS authenticates the person making the transaction. A token proves the credential is protected; it says nothing about whether the person using it right now is who they claim to be. Issuers need both working together, with tokenisation data actively feeding the 3DS risk decision, not sitting alongside it unused.
GPayments has developed 3D Secure technology since 1999 and provides ActiveAccess to issuers across 33 countries. This explains the terminology issuers frequently conflate, what EMVCo’s token-3DS integration actually requires, and where the risk decision can go wrong if token data isn’t used properly.
EMV Payment Token vs Network Token: The Same Thing, Different Names
This is less a technical distinction than a naming one. ‘EMV Payment Token’ is EMVCo’s formal term, defined in the EMV Payment Tokenisation Framework, for a surrogate value that replaces the PAN across the payment ecosystem. ‘Network token’ is the term used in day-to-day industry conversation for the same thing, since these tokens are issued and managed by the card networks through their token services. Both terms describe a numeric value resembling a PAN, restricted to specific domains such as a merchant, device, or channel, and detokenised only by the issuer or an authorised Token Service Provider (TSP). Issuers evaluating vendor documentation should treat the two terms as interchangeable rather than assuming they refer to different technologies.
This is distinct from merchant-specific or acquirer tokens, which are proprietary to a single processor or merchant and don’t interoperate across the payment network the way EMV Payment Tokens do.
How Token Data Integrates With EMV 3DS
EMVCo published the EMV 3DS Payment Token Message Extension specifically to close a gap: without it, a 3DS authentication request carrying a token gave an issuer’s risk engine less context than one carrying the underlying PAN, because token-related data elements weren’t part of the standard message. The extension defines how payment-token-related data can be included in the 3DS authentication request, giving issuers the token assurance level, the identity and verification method used at provisioning, and related metadata to fold into the risk decision. The extension supports EMV 3DS versions 2.1 and 2.2 as an optional addition, and its capabilities were folded into the core specification from 2.3 onward.
Practically, this means an ACS that isn’t specifically built to read and score token-related data elements is treating a tokenised transaction with less information than it should have available, even though the token itself is technically flowing through the authentication request. Whether an ACS actually uses this data in its risk model, rather than just passing it through, is a fair question to ask of any ACS vendor.
Token Assurance Level: The Field Issuers Should Be Weighing
Token Assurance Level (TAL) reflects the confidence in the binding between a token and the underlying PAN, based on the identity and verification (ID&V) method used when the token was provisioned. A token provisioned through a rigorous ID&V process, such as one that included a successful 3DS authentication at provisioning time, carries a higher assurance level than one provisioned through a weaker method. Higher assurance levels typically come with fewer transaction restrictions from the network. For an issuer’s RBA engine, TAL is a genuinely useful risk signal precisely because it reflects how the token came into existence, not just that a token exists.
The important caveat: token provisioning validates identity at a single point in time. Devices change, controls drift, and the assurance established at provisioning ages as the token’s usable life continues. This is exactly the gap ongoing 3DS risk-based authentication is designed to cover on every subsequent transaction, rather than relying on provisioning-time assurance indefinitely.
Where the Two Technologies Genuinely Complement Each Other
|
What Tokenisation Does |
What 3DS Does |
|
Protects the credential itself; the real PAN is rarely exposed to the merchant |
Authenticates the person making the transaction, on every transaction |
|
Reduces PCI DSS scope for merchants storing payment credentials |
Provides liability shift on successful, authenticated fraud disputes |
|
Assurance is established once, at provisioning |
Risk is assessed continuously, transaction by transaction |
|
Works out of the box with an existing 3DS Server; no reconfiguration required to accept a token instead of a PAN |
Uses token metadata (TAL, provisioning method) as an additional risk input, if the ACS is built to read it |
Neither replaces the other. Industry commentary on tokenised transaction volumes has cited meaningful approval-rate uplift and fraud reduction when network tokens are used at scale, but that uplift depends on the transaction still carrying a genuine, well-populated 3DS authentication alongside the token, not the token substituting for authentication.
|
Where GPayments Fits ActiveAccess’s RBA engine is built to score the transaction data an issuer receives, including EMV 3DS Payment Token Message Extension fields where merchants and networks provide them, rather than treating a tokenised transaction as a lower-information event. Issuers integrating network tokens into their 3DS flow should confirm with their ACS vendor exactly which token-related fields are actively scored versus simply passed through. |
Frequently Asked Questions
Is there a technical difference between an EMV Payment Token and a network token?
No, they refer to the same technology. EMV Payment Token is EMVCo’s formal term, defined in the EMV Payment Tokenisation Framework, while network token is the common industry term for the same surrogate value, since these tokens are issued and managed by card networks through their token services. Both are distinct from proprietary merchant or acquirer tokens, which don’t interoperate across the wider payment network.
How does payment tokenisation relate to 3D Secure?
Tokenisation protects the payment credential by replacing the PAN with a surrogate value, while 3D Secure authenticates the person making the transaction. They solve different problems: a token proves the credential is protected, but says nothing about whether the current transaction is legitimate. EMVCo’s 3DS Payment Token Message Extension lets token-related data feed into the 3DS risk decision so issuers get the benefit of both.
What is Token Assurance Level (TAL)?
Token Assurance Level reflects the confidence in the binding between a token and the underlying PAN, based on the identity and verification method used when the token was provisioned. A token provisioned with a rigorous method, such as one confirmed through a successful 3DS authentication, carries a higher assurance level and typically fewer transaction restrictions than one provisioned through a weaker method.
Does using a network token remove the need for 3DS authentication?
No. Network tokens work directly with an existing 3DS Server without additional configuration, and merchants using network tokens still perform 3DS authentication and retain liability-shift protection in the same way as with a raw PAN. Token provisioning validates identity at a single point in time; 3DS provides the ongoing, per-transaction risk assessment that tokenisation alone doesn’t provide.
Which EMV 3DS versions support the Payment Token Message Extension?
The EMV 3DS Payment Token Message Extension was published as an optional addition supporting EMV 3DS versions 2.1 and 2.2. Its capabilities were incorporated into the core specification from EMV 3DS 2.3 onward, based on industry demand for standardised support of payment token data in the authentication process.
How does GPayments’ ActiveAccess use token data in risk decisions?
ActiveAccess’s risk-based authentication engine is built to score available transaction data, including EMV 3DS Payment Token Message Extension fields where merchants and networks provide them, rather than treating a tokenised transaction as lower-information by default. Issuers should confirm directly which specific token-related fields are actively scored in their deployment versus simply passed through unused.
|
Integrating Network Tokens Into Your 3DS Risk Engine? Talk to GPayments about how ActiveAccess scores token assurance and provisioning data: gpayments.com/contact |