Who Owns the Loss

Tokenisation worked. That is the awkward starting point. The card networks set out to stop the reuse of stolen account numbers, and by and large they succeeded. The number that used to sit in a merchant database now sits in a network vault, and what the merchant holds is a surrogate that is worth very little anywhere else.

The trouble is what the success displaced. Attackers do not stop; they move to whichever part of the chain still yields. In this case they moved upstream, to the moment a credential is placed into a wallet, and to the identity assurance standing behind that moment. An institution that has cut card-present counterfeit losses to near zero and is watching provisioning fraud climb has not solved a problem. It has relocated one.

Meanwhile the estate itself grew without an owner. Network tokens, acquirer tokens, gateway vault tokens and legacy card-on-file records accumulate across wallets, processors and regions, each with its own lifecycle semantics and its own reconciliation gap. Ask a bank how many distinct token types it holds and against which requestor identities, and the honest answer is usually that the question has not been asked in that form.

This brief sets out what a network token actually is, where the obligations sit at each hop, why provisioning behaves like a credit decision, how lifecycle failures go undetected, and why dispute liability is an evidentiary problem long before it is a legal one. It closes with the twelve controls we test under domain C39 and the assessment we run against them.

A network token is not encryption and it is not an alias. It is a separately issued value, minted by a token service against a registered requestor, restricted to a domain, and accompanied at transaction time by a cryptogram proving the presenter is entitled to present it. Four properties, and each one carries a control.

The registration property means every token traces to a party that asked for it. That party accepted obligations at registration, and those obligations did not expire when the token was issued. An institution that cannot enumerate its requestor identities cannot evidence that chain, which is the first thing a serious assessor will ask for.

The domain property is what makes a stolen token less useful than a stolen number. It is also routinely weakened in practice, because a restriction that blocks a legitimate transaction generates a customer complaint, and complaints get resolved by loosening the restriction. Nobody records that as a control change. It shows up as a service improvement.

The cryptogram property is the strongest of the four and the least interesting from a governance standpoint, because it either verifies or it does not. The mint property, the existence of a vault holding the mapping back to the account number, is the most sensitive, and it is where key custody arrangements deserve considerably more attention than they typically receive.

Institutions organise around functions, and the token estate cuts across all of them. The wallet relationships belong to digital. The acquiring relationships belong to payments operations. The gateway vault belongs to engineering, or to whichever vendor engineering selected. Fraud carries the losses. Compliance carries the assessment. No single function can describe the whole, and no committee has been asked to.

What that produces is not chaos, the payments run fine, but blindness at the joins. A suspension applied in one system does not propagate to another. A merchant deprovisioned in the acquiring relationship still holds live gateway tokens. A regional migration leaves two vaults running in parallel because the cut-over was scheduled and then deprioritised. None of these appear on a risk report, because none of them belongs to anyone.

The remedy is unglamorous and effective: one inventory, current, with a named owner per hop and a stated obligation at each. It takes weeks, not quarters, and it reliably surfaces between three and ten material findings in institutions that consider the area well run. The inventory is the control. Everything downstream depends on it being true.

When an issuer approves a provisioning request, it is asserting that the person placing a credential into a wallet is the person entitled to that credential. That assertion is made in milliseconds, on thin evidence, under commercial pressure to keep approval rates high. It has the structure of a credit decision and almost none of the governance.

The scheme frameworks give issuers a three-way outcome: approve, decline, or route to step-up. The middle path is where the risk concentrates, because step-up is only as strong as the channel carrying it, and the most common channel remains a one-time passcode sent to a number an attacker may already control. Every institution knows this. Not every institution reports on it.

The diagnostic question is simple. What proportion of provisioning requests took the yellow path last quarter, what proportion of those cleared, and what proportion of cleared yellow paths were subsequently associated with fraud? Three numbers. In our experience, most institutions can produce the first, some can produce the second, and very few can produce the third, because the join between provisioning outcome and later fraud outcome was never built. Without the third number the control is unmeasured, and an unmeasured control is an assumption with a policy document attached.

There is a second-order effect worth naming. Provisioning approval rates are a product metric. Somebody is rewarded for raising them. Unless the fraud outcome is joined back to the provisioning decision, the incentive structure quietly pushes toward looser verification and there is no counterweight in the reporting.

Card reissuance used to break every stored payment relationship a customer had. Token update fixed that, and it is a genuine improvement: the network can push a refreshed credential to merchants holding tokens against the old card, and the subscription keeps working. The mechanism functions. The reconciliation around it frequently does not.

Pushing an update is not the same as confirming it was consumed. Institutions that measure the first and not the second discover the gap when a compromise event forces a mass reissue and a proportion of merchants keep presenting stale credentials. The declines look like a merchant integration problem. They are a propagation control problem, and the evidence to distinguish the two did not exist beforehand.

Suspension carries a related weakness. A suspended token is reversible; a deleted one is not. Systems that flatten both into a single internal status cannot later prove what state a credential was in on a particular date, which matters precisely when it is contested. If a customer disputes transactions in a window during which the institution believes the credential was suspended, the institution needs a record that survives the question. A status field that has been overwritten does not.

Dispute liability on a tokenised credential turns on the authentication path taken at the moment of the transaction. The rules assigning that liability are published and, taken on their own terms, reasonably clear. The losses institutions actually book are rarely the result of misreading the rules.

They are the result of not being able to prove which path was taken. The authentication signal existed at authorisation, travelled through three systems, and was not retained in a form the dispute team can retrieve ninety days later. So the institution accepts a loss the rules would have assigned elsewhere, and it records that loss as fraud rather than as an evidence-retention failure. The categorisation matters, because fraud losses get a fraud response and evidence failures need a data-retention fix.

Delegated authentication sharpens the point. Where a wallet or merchant authenticates on the issuer's behalf, the arrangement is only worth what the institution can demonstrate about it: the contractual basis, the technical evidence per transaction, and the retention window matched to the dispute window. Firms claiming the commercial benefit of delegation without holding that evidence are carrying an exposure that has not been priced and, in a European context, a conduct question as well.

The instruction to a board is short. Take last year's tokenised dispute losses, split them by whether the authentication evidence was retrievable, and look at the second column. That number is a control failure, and it is recoverable.

Tokenisation is often sold internally on scope reduction, and the logic is sound: if account data no longer transits a system, that system falls outside the assessed environment. The saving is real and it is one of the better arguments for the investment.

Scope, though, is a factual question, and facts decay. The integration changes. A fallback path is added for a processor outage and quietly stays. A batch file carrying account data for reconciliation is introduced by a team that was not part of the original design. The scope claim made at project close remains in the documentation and stops being true.

What an assessor wants is not the claim but the substantiation behind it: current data-flow evidence, dated, showing where account data does and does not go, with the fallback and exception paths included rather than assumed away. Under version 4.0.1 the expectation for maintained, current documentation is explicit. An institution that re-establishes scope annually against real flows will find this straightforward. One that has carried the same diagram for three years will not.

We added a domain to the control spine for this: C39, payment tokenisation and credential integrity, twelve atomic controls written the way we write all of them, a stated requirement, a named population, the evidence expected, and the definition of failure fixed before the test runs.

They cover the estate inventory and requestor register; provisioning decision quality and step-up integrity; the yellow-path outcome join; lifecycle propagation and consumption reconciliation; suspension and deletion state integrity; vault key custody and dual control; de-tokenisation authorisation; dispute evidence retention against the dispute window; delegated authentication substantiation; scope re-establishment; third-party concentration where a processor holds the estate; and board-level reporting that includes the provisioning-stage numbers rather than only the transaction-stage ones.

The module at payment tokenisation assurance carries the estate map, the failure modes, the full control table and a fifteen-question readiness assessment that produces a named gap list rather than a score to put on a slide.