MDES + VTS Network Tokenisation Rollout: 92% Coverage and the Auth-Rate Lift That Pays For Itself

Designed and shipped the network-tokenisation programme for a regional acquirer-processor, replacing PAN-on-file storage with scheme-issued tokens via MDES (Mastercard Digital Enablement Service) and VTS (Visa Token Service). Migrated 1,200+ card-on-file merchants across three primary markets, retired three legacy vault providers in favour of a single in-house token broker, and rewired the recurring billing engine around token lifecycle. Delivered +1.8 points portfolio-wide authorisation-rate lift and a 91% reduction in PAN footprint without a single sev-1 or sev-2 incident through the cutover window.

The acquirer carried PAN-on-file across three separate vault providers accumulated over five years of acquisitions and partnerships. Every reissuance event broke a merchant relationship: subscriptions failed silently, account-updater coverage was patchy, and the dispute team was losing Compelling Evidence 3.0 (CE3.0)-eligible disputes because the cardholder identity link was broken across reissuance. PCI scope across three vaults was tripling the audit cost. The next-quarter scheme push on mandatory tokenisation for card-on-file merchants made the gap untenable. The team needed a complete migration with no merchant-visible failure, on a portfolio crossing 1,200 active merchants and ~14M token-able credentials.

• Single in-house token broker: one service owns MDES + VTS lifecycle, exposes a stable internal API to every merchant integration
• Token-state engine: every credential has a state (active, suspended, reissued, deleted) updated from MDES / VTS lifecycle webhooks in real time
• Lifecycle webhook ingestion: ~40k events/day from MDES + VTS, tokenisation, reissuance, account closure, lifecycle suspension, routed to merchant-specific handlers
• Per-merchant migration tool: feature-flag rollout, dry-run mode against a sandboxed copy of the vault, instant rollback per merchant if token issuance failed for that merchant's BIN profile
• Recurring engine rewrite around token lifecycle: token-state-aware retry logic, dunning that respects suspended states, automatic re-trigger on reissuance events
• CE3.0 lookup index: cardholder-indexed transaction store keyed on scheme token, queryable across the 365-day dispute window
• Vault decommissioning sequence: per-vault traffic drain, residual PAN re-tokenisation, audit-evidenced decommissioning

• Token broker sits between the acquirer's transaction switch and the schemes, MDES + VTS lifecycle endpoints behind a stable internal API
• Token-state is the canonical record; the underlying PAN is detokenised only inside the broker and never surfaces to merchant-facing services
• Lifecycle webhooks are idempotent; each event is keyed on the token ID + scheme event ID; replays produce no state drift
• Recurring engine queries token state before every charge; suspended tokens are retried only after the reissuance webhook fires
• CE3.0 evidence path: cardholder identifier = scheme token; lookups span the full lifecycle (including reissuance chains) via the token genealogy table
• Vault decommissioning was per-merchant, not portfolio-wide, every merchant had a documented cutover window with rollback and validation steps

• Weekly token-state review: lifecycle event volume, suspension rates by issuer, reissuance match rate, anomaly detection on per-issuer token rejection
• Weekly auth-rate review per merchant: pre-tokenisation vs post-tokenisation auth-rate delta, decline-reason mix shift, recurring-success delta
• Monthly merchant-rollout review: merchants in flight, merchants completed, merchants paused, residual PAN footprint
• Quarterly scheme certification: MDES + VTS recertification on any new flows; vault attestation closeout for decommissioned vaults

Owned the tokenisation programme end-to-end as Product & Program lead, token broker architecture, lifecycle event design, per-merchant migration governance, recurring-engine rewrite, vault decommissioning sequence, scheme certification, and the auth-rate measurement programme. Direct accountability for migration cadence, post-migration auth-rate delta, PCI scope reduction, and zero-incident cutover record.

• Migrated 1,200+ card-on-file merchants from PAN storage to scheme tokens across three markets in 14 months
• Reached 92% network-tokenisation coverage on card-on-file traffic, ahead of the scheme deadline
• Lifted portfolio-wide authorisation rate by +1.8 points on tokenised traffic, with the largest lift on iOS Safari + cross-border combinations (+3–4 pts)
• Reduced PCI PAN footprint by 91%, three vault providers retired, single in-house broker stood up
• Cut recurring-subscription failure rate on the subscriber cohort from 11–14% to 3.6% by leveraging real-time lifecycle webhooks for reissuance and suspension
• Closed the CE3.0 evidence gap, cardholder-indexed transaction history now persists across reissuance, lifting the win rate on Visa 10.4 (card-absent fraud) disputes by ~40 pts
• Zero sev-1 / sev-2 incidents across the 14-month rollout window

• Chose single in-house token broker over per-merchant vault retention, heavier upfront engineering investment; saved ongoing per-vault PCI cost and produced a single source of truth for lifecycle events
• Migrated per-merchant rather than portfolio-wide, slower headline cadence; removed single-event blast radius; allowed rollback per merchant
• Sequenced vault decommissioning after merchant migration was complete, kept the legacy vaults running in dual-write mode longer than ideal; protected reversibility through the cutover window
• Built lifecycle webhook ingestion as idempotent + replayable from day one, added two weeks of build effort; saved an entire incident class around webhook duplication and out-of-order events

• Tokenisation is a credential-lifecycle programme, not a one-time migration. The webhooks (issuance, reissuance, suspension, deletion) are what make tokens pay back; teams that ship the migration without the lifecycle engine see lifecycle event backlog grow inside 90 days.
• Per-merchant migration governance, feature flag, dry-run, rollback, named ops owner, is the actual product. Portfolio-wide cutovers on credentials are how good engineering teams ship sev-1 incidents.
• Token genealogy (the chain of token IDs across reissuance for the same cardholder) is the single most underrated artefact. CE3.0 lookups, recurring re-trigger, and audit replays all depend on it being clean.
• PCI scope reduction is the headline; the auth-rate lift is the substance. The 91% PAN footprint reduction got the audit team's attention; the +1.8 points auth-rate lift paid the programme back inside six months.
• Vault decommissioning is a separate programme. Building it as the final step of tokenisation produces a clean attestation; building it into the migration plan as 'phase 4' produces an audit observation.

Network tokenisation is no longer optional. Schemes are pushing it to mandatory across every major market; PCI auditors are pricing PAN-on-file storage out of viability; CE3.0 makes prior-cardholder evidence depend on token persistence; recurring success on the subscription economy depends on lifecycle webhooks. The acquirer-processors that ship this programme cleanly, single broker, lifecycle engine, per-merchant migration, recurring rewire, get the auth-rate lift, the PCI cost saving, the dispute win-rate lift and the regulatory posture as one bundle. The ones that ship it badly carry three vaults, a broken recurring engine, and a CE3.0 implementation that looks good on paper and loses disputes in production. This is the playbook for the first.