Tokenisation and card-on-file in India: what the regulator already decided

The architectural decision was taken out of Indian hands on 1 October 2022. From that date no entity in the card payment chain other than a card issuer or a card network may store actual card data. A merchant that wants a saved-card checkout has no alternative to tokens, because the alternative — holding the card number — is prohibited outright.

So the live question here is not should we tokenise but what is still in PCI DSS scope now that we have. Three parts: a real reduction in Requirement 3, no reduction at all in the payment flow, and a residue most purge projects missed.

What the RBI decided, and on which dates

One distinction is worth getting right, because most Indian summaries blur it. Tokenisation is the cardholder’s choice; storing the card number is your prohibition. The 2021 circular requires explicit customer consent with additional factor of authentication before a card is tokenised, and a customer who declines simply checks out as a guest. What is not optional is the other half — you may not answer a declined tokenisation by keeping the PAN.

What genuinely leaves PCI DSS scope

PCI DSS v4.0.1 is explicit that dropping storage drops requirements: “if the entity does not store PAN, then the requirements relating to the protection of stored PAN in Requirement 3 will not be applicable to the entity.” That is a real reduction, and it is the reduction tokenisation buys.

The token store is the second one. “The primary account number (PAN) is the defining factor for cardholder data,” and expiry date, cardholder name and service code become cardholder data when they are “stored, processed, or transmitted with the PAN, or are otherwise present in the CDE”. A table holding a network token, an expiry date, the last four digits and the issuer’s name — with no PAN anywhere in the environment — is not cardholder data.

That conclusion holds only while you cannot reverse the token. Under CoFT the mapping sits with the card network or the issuer acting as token service provider, which is precisely why the scope reduction is real. Run a vault of your own that can return a PAN and the position inverts: v4.0.1 lists “index tokens” as one of the approved methods of rendering stored PAN unreadable under Requirement 3.5.1, alongside truncation, keyed hashing and strong cryptography. A token that maps back to a card number is a Requirement 3 control, not an exit from Requirement 3, and the system performing the mapping is squarely inside the cardholder data environment.

What the purge did not touch

Capture. Card-on-file tokenisation removes storage. It does not remove the moment a customer types a card number into something. PCI DSS applies to entities that “store, process, or transmit” account data and to “system components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data” — a category the standard illustrates with “e-commerce (web) redirection servers”. A checkout page that never receives a PAN can be in scope for having determined where the PAN went. Which questionnaire that leaves you on turns on how the page is assembled, and that is a separate question with its own eligibility table.

Residue. Requirement 3.2.1 is not discharged by a one-off deletion. It requires “a process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable” — a standing quarterly control, as much four years after a migration as during it. Requirement 3.5.1 says where to look: PAN in “non-primary storage (backup, audit logs, exception, or troubleshooting logs)” as well as in databases and flat files. The usual survivors of an Indian CoFT purge are payment application logs, failed-transaction and exception queues, chargeback and refund workflows, database backups predating the cut-over, screenshots attached to support tickets and, wherever there is a voice channel, call recordings. The standard counts “storage of account data in any format (for example, paper, data files, audio files, images, and video recordings)” as a system component.

The T+4 window. The July 2022 circular lets a merchant or payment aggregator handling guest checkout keep card-on-file data for at most T+4 days or until settlement, whichever is earlier — expressly as an interim measure, only to settle that transaction, and purged afterwards. An entity using that allowance stores actual card data. It has a cardholder data environment for four days at a time, with everything Requirement 3 asks of stored PAN, and “we store no card data” is contradicted by its own settlement files.

Moving to tokens is a significant change, and the standard says what follows

Anything that alters where account data is stored, processed or transmitted is a significant change, and PCI DSS attaches four obligations to one:

• 12.5.2 — scope is “documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment”, identifying “all locations where account data is stored, processed, and transmitted”, expressly including any outside the currently defined CDE.
• 11.3.1.3 and 11.3.2.1 — internal and external vulnerability scans after the change. On the external one the standard adds that “scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV)”. The quarterly external scan at 11.3.2 is a different requirement with a different answer.
• 11.4.2 and 11.4.3 — internal and external penetration testing, “at least once every 12 months” and “after any significant infrastructure or application upgrade or change”.
• 11.4.5 — where the smaller environment is held together by segmentation, that segmentation is tested “at least once every 12 months and after any changes to segmentation controls/methods”. Until it is tested it is an assertion.

The characteristic defect after a tokenisation migration is not a missing control. It is a penetration test scoped to the environment that existed before it. The 2022 cut-over collapsed the cardholder data environment for most Indian merchants while expanding the third parties they depend on; test scope often followed neither. Under-scoped is a finding on the report. Over-scoped is an invoice for testing systems that no longer hold anything.

Re-scoping against the environment as it stands today, then Requirement 11.4 penetration testing and segmentation testing against that scope, is the work that closes the gap.

For a regulated payment aggregator there is a further layer: the 2025 Directions make PCI DSS a term the aggregator imposes on merchant infrastructure — clause by clause here.