The essential element of Near Field Communication (NFC) tokenization is replacing a Primary Account Number (PAN) with a token. The token is a randomly generated 16-digit number that replaces the PAN, but it represents that PAN to everyone involved in the transaction. Because the token is simply a random number, and not a genuine PAN, someone listening in on the conversation will get the token, but it’s useless outside the conversation currently taking place.
In addition to the tokenized PAN, the smartphone card-emulation software (either in a secure element or running in phone memory or in the cloud) generates a dynamic card verification value (dCVV, to use Visa’s term for it). This dCVV is a cryptographic value that is unique to the single transaction and can be used only once.
A hacker stealing the token and the dCVV might attempt to use the token for some nefarious deed, but the dCVV’s lifespan is so short that the amount of damage is significantly smaller than if the hacker had gained access to the PAN instead. And because the token is tied to a specific phone, it can’t be used to prepare a counterfeit plastic card and can’t be used to buy things on the web. Any transaction that includes the token but does not originate from the registered phone wallet is declined as fraud.
Payment applications that use NFC to communicate must also use the EMVCo Payment Tokenization standard if they use HCE to store and route payment data according to Payment Network Operator (PNO) requirements. So to summarize, a token is a low-value item that represents a high-value item, akin to a poker chip representing money when playing cards.
Apple Pay uses a proprietary tokenization system; most other NFC wallets rely on the EMVCo Payment Tokenization standard. All current schemes tokenize the 16-digit PAN using a static token value issued by the token authority when the payment card is first registered in the NFC wallet. The token value never changes (unless it is compromised and reissued).
This approach allows merchants and banks to identify particular customers for returns and loyalty programs in the same way they do now by hashing the card PAN. All tokenization schemes prevent anyone but the trusted authority from reversing the tokenization and revealing the true PAN of the card user.
You can use a token with any Cardholder Verification Method (a CVM might include a PIN, signature, or fingerprint). To keep the token from becoming a security problem, it has a specific expiration period, after which no one can use the token to represent the PAN — any new transactions require a different token. And tokens can be further restricted for use at specific merchants (for retail private-label cards or gift cards) or may contain other restrictions verified by the token authority.
Some vendors also use tokens for their private-label card data. For example, you might see tokenization used for gift cards to ensure that the money on the card remains secure.