India's card-on-file rule has barred everyone except card networks and issuers from storing card data since 1 October 2022. A subscription business holds 900,000 saved cards in its own vault with 4% monthly churn, and must move to network tokens with a payment aggregator acting as token requestor without losing recurring collections. Sequence the migration and name the point of no return.

The constraint that shapes everything

The RBI's restriction on storage of actual card data says that from 1 October 2022 no entity in the card transaction or payment chain other than card issuers and card networks may store card-on-file data, and that data stored previously had to be purged. Replacement is a network token issued to a token requestor: the aggregator or the merchant, registered with the networks. Razorpay's TokenHQ is a documented example of the aggregator-as-requestor model, built with Mastercard, RuPay and Visa.

The detail that decides the migration plan: tokenising a card needs the cardholder's consent and an additional factor of authentication. So this is not a database transformation. It is a re-authentication campaign, and the only cheap moment to run it is a payment the customer is already authenticating.

The sequence

1. Dual-write the new path. Every new card save creates a token through the requestor; the vault becomes read-only. One day's work, and it stops the problem growing.
2. Tokenise on the next successful cycle. For monthly billing at 4% churn, roughly 96% of active mandates are touched within one cycle and about 85% within three, so the bulk clears in a quarter without a single prompted migration. Record token_present on the mandate so the share is a query, not an estimate.
3. Dual-read with a measured fallback. Charge the token; fall back to the vault only while the vault exists, and alert on the fallback rate. A fallback rate that stops falling is your residual population.
4. Campaign the residual. Dormant and annual mandates will not be touched by a billing cycle. They need a prompted re-entry flow, and some will not come back. Price that churn into the plan and tell the business the number before you start.
5. Purge the vault. This is the point of no return: after it, an un-tokenised customer can only be recovered by typing the card in again. Gate it on the tokenised share of active mandates crossing an agreed threshold and on the re-entry flow being live, not on the project date.

Where data diverges and how you notice

The vault and the token store disagree whenever a token creation succeeds at the network and the response is lost. Reconcile daily on mandate id rather than on card number, since you will not have card numbers; a mandate with two live tokens is the benign case and a mandate with none that billed yesterday is the one to page on.

What you give up

A card-on-file token is issued to a token requestor, so the PAN disappears as a join key. Velocity rules keyed on card number, duplicate-account detection and chargeback matching against historical records all lose their identifier, and changing aggregator later means re-tokenising unless the merchant holds the requestor role itself. Ask the networks what account-reference identifier is available to you before you design around its absence, and decide the requestor question as a strategic one: aggregator-as-requestor is faster to ship and harder to leave.

When this is the wrong answer

If repeat purchase is rare and there are no recurring mandates, do not own tokenisation at all. The provider's hosted checkout with guest payment removes the vault, the migration and the storage obligation in one move, and the saved-card convenience you lose is worth little when most customers buy once.