Network Tokenisation

Network tokenisation is how a card scheme turns a card number into a token it has issued, and keeps that token working over its life. It is a service, not a piece of data. It has named roles, set steps and its own sign-up rules, and a payment service provider usually sits between a shop and the rest of it. This entry covers how that service runs and who runs it. The token it makes is a separate subject with its own entry, so the focus here stays on the machinery rather than the output.

The reason it needs setting out at all is that several parties touch it. A shop or wallet asks for a token. A named body issues it. The card issuer says whether the ask is good. A reference is made so payments can still be tied back to one account. Each of those roles has a code on a register, and EMVCo runs the registers. None of that shows up in a finished payment, which is why the terms get used loosely. EMVCo's own guide lists 7 settled cases for it, from taps at the till to stored cards and merchant-led billing.

Who Issues The Token

The role is called the Token Service Provider, or TSP. EMVCo's guide to tokenisation use cases says the TSP issues tokens for an approved party, called the Token Requestor, on behalf of the card issuer. So the TSP does the work. The issuer's card is the thing being stood in for. A wallet or a shop is the requestor here, not the issuer, and the gap between those two roles trips people up. EMVCo's guide names several token types that follow from it. Some are tied to one device. Some are tied to one shop. One kind is issued for a single guest purchase and then done with, which suits a shopper who does not want an account.

How The Parties Are Named

Each TSP holds a 3-digit code from EMVCo. Its TSP registration programme says the code is folded into the Token Requestor ID. That ID names the pairing of a requestor with its TSP. So one code tells you both who asked and who issued. Worth noting that EMVCo does not vet or back these firms. It says plainly that it only keeps the list of codes.

The Register Behind The Reference

A second register sits next to it. EMVCo's BIN Controller ID programme gives a 4-character value to the body that runs the Payment Account Reference for a range of card numbers. Those 4 characters are the first 4 of the reference itself. Only card scheme blockholders, or issuers with numbers given to them direct, can hold one. That keeps the register tight and small.

What Happens At Enrolment

The guide sets out the flow. The requestor names itself with its own ID. The issuer then checks who the customer is, as part of what the spec calls token assurance. Once the token exists, the TSP sends it and its data to the requestor. The requestor either stores it or passes it on to wherever the token will live. How much checking is expected turns on the case, so a wallet sign-up and a stored card for billing are not treated alike.

Keeping Tokens Alive

The part that earns its keep is what happens after. A phone is lost, so a token is put on hold or swapped. A card is reissued, so the token carries on while the number under it changes. A shop deletes a stored card, so the token goes too. That upkeep is why a stored token tends to keep billing where a stored card number would have failed, and why it does some of the same work as an account updater service. finera.'s guide to why recurring payments fail and how to recover them covers that in more detail.

The Security Rules On Top

The parties running this are held to their own standard. The PCI Security Standards Council puts out a Token Service Provider standard with security rules for firms that make and issue tokens under the EMVCo spec. Checks against it are done by assessors trained for the job. The council notes that the card brands run the compliance schemes themselves. So what a given TSP must show can differ by scheme. A firm buying this in should ask which brands a provider has been through, not just whether it holds the standard.

How This Differs From Tokenisation In General

Tokenisation as a broad idea covers any swap of sensitive data for a stand-in value. That takes in a provider's own vault. The scheme-run version is narrower, with roles on a register and a reference that works across the network. finera.'s look at tokenisation and encryption sets out how both differ from making data unreadable, which is a third thing again.

What A Business Should Check

The useful questions are about who holds what. Which party is the requestor, since that sets who owns the tie to the customer. Whether the tokens move with you if the firm changes provider. Whether updates over a token's life are passed on or quietly dropped. And whether the reference is shared, since without it the reporting thread breaks. finera.'s merchant guide to Apple Pay shows the wallet end of this, where most shops meet it first.