Compliance projects rarely pay for themselves. Tokenisation is the exception, and that makes it unusual enough to be worth explaining carefully to whoever controls the payments budget.
The scope argument is straightforward. Every system that stores, processes or transmits a card number falls inside PCI DSS scope, and everything in scope needs monitoring, access control, segmentation and evidence. Tokenisation strips card numbers out of those payments systems, and the systems leave the perimeter with them. The approval argument arrives alongside it: analysis of network tokenisation across merchant portfolios has put the authorisation uplift in the range the schemes publish, with a three percent improvement on ten million monthly volume recovering meaningful revenue every month.
Vladyslav Kolodistyi, who works on payments infrastructure at PayAdmit, uses the combination deliberately when building a case.
"Most payments programmes are either a payments cost saving or a revenue gain," says Vladyslav Kolodistyi. "Tokenisation is both, and it is the only line in the payments roadmap where the audit team and the growth team want the same thing. Teams still manage to present it badly."
Network tokenisation reduces scope and lifts approvals at the same time
The two effects come from different properties, which is why they compound rather than trade off.
Scope reduction comes from tokenisation removing the card number. Once stored payments records are network tokens rather than card numbers, the payments databases holding them stop being cardholder data environments. The audit surface shrinks, penetration testing gets narrower, and the annual assessment gets shorter. Vladyslav Kolodistyi points out that the saving is recurring rather than one-off, which changes the payback calculation entirely.
Approval uplift comes from the token type, and only network tokens produce it, because only network tokens reach the issuer with payments assurance data attached. Visa reports a 4.6 percent authorisation lift on tokenised card-not-present payments and roughly a 30 percent fraud reduction against raw card numbers, documented in its own tokenisation hub.
"Merchants approaching tokenisation purely for PCI reasons pick the cheaper token and leave the approval gain on the floor," says Vladyslav Kolodistyi. "It is the same project. Network tokens cost marginally more and return a card-on-file payments improvement that the compliance saving never would."
The compounding is worth spelling out for a finance audience:
- Audit cost falls each year, not once, because scope stays smaller
- Engineering time maintaining the payments cardholder data environment is released permanently, thanks to network tokens
- Approval rates rise on card-on-file payments, adding revenue in the same period
- Fraud losses fall on payments carrying network tokens, reducing chargeback handling cost
- Card reissuance stops breaking recurring card-on-file payments, which reduces involuntary churn
Only item one is what most teams pitch. Vladyslav Kolodistyi argues that presenting a tokenisation programme on scope reduction alone understates it by a wide margin and invites the finance team to defer it.
Scope reduction also changes how quickly a payments team can build. Systems inside the cardholder data environment carry change control, segmentation requirements and review overhead that systems outside it do not. Tokenisation shortens the path from idea to production for anything touching card-on-file payments, and that velocity gain never appears in the business case.
Vladyslav Kolodistyi rates it highly anyway. "Ask your engineers how long a change takes inside the cardholder data environment versus outside it," he says. "Tokenisation moves payments work from one side of that line to the other, and the compounding effect on delivery speed is larger than the audit invoice."
Network tokens add a further wrinkle that assessors increasingly ask about. Because tokenisation here is scheme-issued, the merchant's obligations differ from a model where the merchant holds the mapping itself, and documenting that distinction saves time in assessment.
Card-on-file payments, audit evidence and the parts nobody budgets
Scope reduction is not automatic, and this is where tokenisation projects lose credibility with auditors. A merchant that tokenises the primary card-on-file store but leaves card numbers in logs, backups, analytics exports or a legacy reporting database has reduced nothing. The scope follows the data, not the intention.
"The card number leaks sideways," says Vladyslav Kolodistyi. "Payments teams tokenise the obvious store and forget that six years of application logs contain the same numbers. Your assessor will find them, and the tokenisation scope benefit evaporates in a single finding."
His recommendation is a data-flow inventory before the tokenisation migration rather than after. Every place a card number has ever been written, including places nobody has looked at in years. It is unglamorous work and it determines whether the scope reduction survives assessment.
There is a second evidence question specific to network tokens. Auditors will ask where network tokens map back to cards and who can access it, and the answer differs depending on whether the merchant holds network tokens directly or receives them through a payments provider. Vladyslav Kolodistyi advises settling this before the assessment rather than discovering it during one.
Operational benefits accumulate quietly after that. Card-on-file records that update through reissuance mean fewer failed payments, which means fewer dunning cycles, fewer support contacts and less manual payments reconciliation. None of those appear in a tokenisation business case, and together they are often larger than the audit saving.
The measurement point recurs here as elsewhere. Tokenisation changes what payments reporting describes about card-on-file activity, and a team that does not separate tokenised from untokenised card-on-file payments cannot demonstrate the approval gain. Vladyslav Kolodistyi insists on cohort comparison within the same period rather than before-and-after across the book, because seasonality will otherwise swallow the effect.
He also warns against inflated expectations. "You will see twenty percent uplift claims for tokenisation," he says. "Plan against the published payments figures from the schemes. What is genuinely true is that the gain concentrates in aged card-on-file credentials, so that aged segment improves far more than your blended payments average ever shows."
One structural point closes the argument. Network tokens sit at the scheme layer, which means the merchant's PCI posture and its approval performance improve from the same change rather than from two separate projects. He finds that combination persuasive with boards precisely because network tokens require no trade-off between the security team's goal and the payments team's goal.
"Network tokens are the only control I can point to where nobody has to lose," he says. "Audit scope shrinks, payments approvals rise, and both effects come from the same migration. Network tokens are unusual in that respect."
Sequencing advice is consistent. Apply tokenisation to new credentials first, migrate the back book in cohorts, inventory the data flows, adjust dunning once network tokens carry the credential lifecycle, and instrument the comparison from the beginning.
Cross-border payments are where the approval side of tokenisation tends to show up first. Issuers outside a merchant's home market have the least context on a raw card number, so the assurance data carried by network tokens does disproportionate payments work there. Merchants with heavy international payments see the steepest gains from network tokens in that segment, and it is worth reporting separately.
Ownership is the last practical point. He places tokenisation with the payments team rather than with security, on the grounds that most of the decisions are commercial: which token type, which schemes, which cohorts first, how the benefit gets measured.
"Security will scope tokenisation correctly and stop," he says. "The payments team is the one that cares whether card-on-file approvals moved next quarter. Whoever owns tokenisation determines whether network tokens end up as a compliance artefact or a revenue programme."
There is one more compliance dimension worth flagging. Under strong customer authentication regimes, payments carrying network tokens interact more cleanly with exemption logic, because the assurance data supports a risk-based decision that would would otherwise force a challenge. Network tokens therefore improve compliance posture and conversion at once, which is rare enough in payments to be worth planning around.
Vladyslav Kolodistyi treats that as the closing argument with sceptical stakeholders. "Tokenisation reduces audit scope, lifts card-on-file approvals, cuts fraud, keeps recurring payments alive through reissuance and helps with authentication exemptions," he says. "Network tokens deliver all five, and that is what tokenisation should mean. I cannot think of another payments project with that profile."
Timing is the last variable. Because network tokens deliver most of their value on aged credentials, a payments team deferring network tokens keeps adding card-on-file records that will need rescuing later.
The reason Vladyslav Kolodistyi returns to this subject is that the economics are unusually clear in an industry where most payments investments require a leap of faith. Tokenisation reduces a recurring payments cost, improves approvals on card-on-file payments, cuts fraud and removes a category of churn. Few payments projects do one of those convincingly, and network tokens do four. Further commentary from Vladyslav Kolodistyi on tokenisation and payments compliance is published through his LinkedIn profile.
Top comments (0)