Wallets & Alternative Rails / Learning brief
How network tokenisation protects a card
Your notes
In simple terms / 01
What this means in plain language
Network tokenisation replaces a card's real number with a device- or merchant-specific stand-in, the DPAN, that only the network can turn back into the real account. Because the token carries domain controls, a copied token is close to worthless outside the device and merchant it was minted for. This is how a stored card can be safer than the number printed on the plastic.
Network tokenisation replaces a card's real number (the PAN, or primary account number) with a stand-in called a DPAN (device primary account number) that only the card network can turn back into the real account. The DPAN is bound to a specific device and, through domain controls, to the context it was minted for, and every payment carries a one-time cryptogram that proves the token is being used on its own device. Because of that binding, a token copied by an attacker is close to worthless away from the device and merchant it belongs to: presenting it elsewhere fails the domain check. This is why a card stored as a token can be safer than the number printed on the plastic — the value moves from keeping the number secret to controlling where and how the token may be used.
Key takeaways / 03
Three things to remember
- 01
A DPAN is a real, separate number; the network's token vault holds the mapping back to the underlying PAN, and the issuer still authorises on the real account.
- 02
Domain controls and a per-transaction cryptogram, not secrecy, are what make a stolen token hard to reuse.
- 03
The remaining weak point is enrolment: adding someone else's card to an attacker's device, which is why issuers apply step-up authentication when a card is first provisioned.
Practical use cases / 04
Where you would use this
A fraud team decides where to concentrate controls, focusing on the provisioning step rather than on protecting the token in transit.
An issuer designs its step-up authentication for card enrolment into a wallet, since that is where provisioning fraud lands.
A merchant storing cards on file evaluates a network token as a safer alternative to holding the raw PAN.
Worked example / 05
Put the idea into a real situation
(SYNTHETIC / TRAINING ONLY) Maya Chen provisions her Bank Alfa card into her phone. Bank Alfa applies a step-up check, then the network's token service issues a DPAN and stores the DPAN-to-PAN mapping in its vault. Suppose an attacker later captures that DPAN. When they try to use it from a different device, the payment carries no valid device cryptogram and fails the token's domain check, so it is declined — the number alone buys them nothing. The real exposure was never the token in flight; it was the enrolment moment, which is why Bank Alfa authenticated Maya before the DPAN was ever activated.
Evidence & review / 07
Evidence & review
Card network tokenisation for device wallets and merchant card-on-file; the mechanics apply across schemes, though naming differs.
What this brief simplifies: Cryptogram generation and key management are described in outline, not in cryptographic detail. Scheme-specific token vault operations are generalised. The DPAN and all card values are synthetic.
Sources for this brief3
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements · Definitions: payment token, tokenisation
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · RTS on SCA: dynamic linking and possession factors
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Token-requestor and domain-control framing; synthetic examples
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.