Payment Tokenisation Assurance
Card-network tokenisation is a different discipline from asset tokenisation. The account number is replaced by a domain-restricted token, minted under a registered requestor identity, provisioned through a verification decision the issuer owns, and carrying its own lifecycle. Each of those is a control surface. This module states where the obligation sits at every hop, what fails in practice, and what a reviewer should be able to prove from held evidence.
We assure and evidence controls over payment tokenisation. We do not operate a token service, hold a token requestor identity, or claim any scheme certification, accreditation or endorsement. Scheme and standards bodies are referenced only through their own published programmes and specifications.
The token estate, hop by hop
A network token, an acquirer token and a gateway vault token are three different objects with three different owners. Most control failures we see start with a programme that treats them as one.
Issuer credential of record
Holds the funding account and the primary account number the token stands for, and authorises or declines the token-initiated transaction.
Obligation carried
Cardholder data protection over the credential of record, token-to-account mapping integrity, and lifecycle propagation when a card is reissued, blocked or closed.
First question asked
When the card was reissued, which tokens updated automatically, which required cardholder action, and which are still pointing at a credential that no longer exists?
Network token service
Issues the network token, holds the mapping, applies domain restriction, and generates the cryptogram that proves the transaction came from the provisioned device or channel.
Obligation carried
For the participant, not the operator: evidencing that token requests were made under a registered requestor identity and that domain restrictions match the acceptance channel actually in use.
First question asked
Can you produce the registered token requestor identifiers in use across your estate, and show that none are shared across entities or channels that were never approved?
Provisioning and identification-and-verification
Binds a credential to a device or wallet, with an identification-and-verification step that decides whether the provisioning attempt is genuine.
Obligation carried
Issuers set and own the identification-and-verification decision. Step-up must be evidenced, and approve-rate pressure must not silently weaken the standard.
First question asked
What proportion of provisioning attempts were approved without step-up in the period, and can you show the decision rule that was in force on each date?
Token requestor
Requests tokens on behalf of a wallet, merchant, processor or platform, and is the identity the network holds accountable for how those tokens are used.
Obligation carried
Registration currency, scope of use, and separation between entities, a requestor identity is a control boundary, not a technical convenience.
First question asked
Which legal entity owns each requestor identity, and what happens to the tokens if that entity's relationship ends?
Acquirer and processor
Carries the token, cryptogram and transaction-type indicators through authorisation, clearing and dispute handling.
Obligation carried
Faithful transmission of token and authentication data, correct transaction-type indication, and dispute handling that reflects the liability position the data creates.
First question asked
Where indicators were dropped or defaulted in transmission, who absorbed the resulting dispute liability, and was that priced?
Merchant and gateway vault
Stores gateway or vault tokens for repeat billing and orchestration, which are not network tokens and do not travel between providers.
Obligation carried
Scope substantiation for cardholder data environment reduction, key custody, and a migration position, vault tokens are usually provider-specific lock-in.
First question asked
If the gateway relationship ended tomorrow, could recurring billing continue, and on what legal and technical basis would the credentials move?
What actually fails
Not the cryptography. The joins between systems, the decisions taken under approval-rate pressure, and the scope claims nobody re-tested after the last migration.
Provisioning fraud through a weakened verification standard
SevereA stolen credential is provisioned into a wallet on an attacker's device because the identification-and-verification decision was relaxed to protect approval rates, or because the step-up channel was a one-time code delivered to a number the attacker controlled.
How we test it: Reperform the provisioning decision on a sample of approved attempts against the rule in force on that date, and reconcile step-up channel to the contact record as it stood before the attempt.
Orphaned tokens after reissue, closure or portfolio migration
HighTokens survive the credential they were minted against. Some update silently, some fail, and some sit in a state where a transaction can still be attempted against an account that has been closed or moved.
How we test it: Reconcile the active token population to the active credential population and age every mismatch. The population is the full token set, not a sample.
Dispute liability assumed rather than evidenced
HighTeams assume a token-initiated transaction carries a favourable liability position. The position depends on indicators actually present in the authorisation message, and those indicators are frequently dropped in transmission or defaulted by an intermediary.
How we test it: Sample disputes lost in the period and trace the authorisation message field by field to establish whether the expected indicators were present when the transaction was authorised.
Vault and key custody without a tested recovery path
SevereThe token vault is treated as a product feature rather than a cryptographic system. Key custody, rotation and split knowledge are documented, and never exercised. Recovery is theoretical until the day it is not.
How we test it: Inspect key ceremony records, rotation evidence and custodian separation, then observe a recovery rehearsal against the documented procedure.
Compliance scope reduction claimed but not substantiated
HighTokenisation is presented as having taken systems out of the cardholder data environment, without a current data-flow diagram showing that no system in the reduced scope can retrieve or reconstruct the account number.
How we test it: Walk the data flow against live configuration and confirm that de-tokenisation capability, wherever it exists, sits inside the asserted scope boundary.
Single-provider concentration inside the token estate
ElevatedCredentials sit in a vault operated by one provider, with no portability mechanism and no tested exit. The commercial relationship becomes the operational resilience position.
How we test it: Assess substitutability against the third-party register, and confirm an exit plan that has been tested rather than drafted.
Agent-initiated commerce against a credential-on-file token
ElevatedSoftware agents transacting on a cardholder's behalf use tokens minted for a different purpose. Mandate, limit and revocation evidence sits outside the payment record, so the institution cannot prove the transaction was authorised as instructed.
How we test it: Trace a sample of agent-initiated transactions to the mandate that authorised them, including limit, expiry and the revocation path.
C39: Payment tokenisation and credential integrity
A new domain on the unified control spine, with 12 atomic controls that test like every other control we ship: a stated requirement, a named population, the evidence, and what counts as failure, written before the test is run.
| Control | Requirement | Population | Failure |
|---|---|---|---|
C39.01 Token estate register completeness quarterly · inspection | Every token type in production — network token, gateway or vault token, processor token — is registered with its owning legal entity, requestor identity and accountable owner. | All acceptance channels and all stored-credential flows; full population. | Any production token type absent from the register, or registered against an entity or owner that no longer exists. |
C39.02 Token requestor identity governance semi-annual · inspection | Each token requestor identity is registered to one legal entity, scoped to approved channels, and re-confirmed on change of relationship or ownership. | All registered requestor identities. | A requestor identity shared across entities, used outside approved scope, or with no accountable owner. |
C39.03 Provisioning identification and verification evidenced quarterly · reperformance | The identification-and-verification decision rule is versioned, and the rule in force on any past date can be reproduced with the outcomes recorded against it. | All provisioning attempts in the period, sampled by outcome and by channel. | An approval that cannot be reproduced from the rule in force, or step-up delivered to a contact detail changed inside the exposure window. |
C39.04 Lifecycle event propagation continuous · automated | Reissue, block, close, suspend and portfolio-migration events propagate to every affected token inside the stated service level, with exceptions aged and owned. | All lifecycle events in the period; full population. | Any token still transactable against a credential that was closed, blocked or reissued outside the stated window. |
C39.05 Token-to-credential reconciliation monthly · automated | The full active token population reconciles to the active credential population, with every mismatch investigated rather than netted off. | All active tokens and all active credentials; no sampling. | A reconciliation performed on a sample, or a break carried forward without cause or owner. |
C39.06 Domain restriction and authentication data verified quarterly · reperformance | Domain and transaction-type restrictions match the acceptance channels actually in use, and authentication data accompanying a token is verified rather than assumed. | All acceptance channels; production sample per channel. | A token accepted outside its approved domain, or accepted where the required authentication data was absent or invalid. |
C39.07 De-tokenisation enumerated and scope substantiated semi-annual · inspection | Every system and identity able to retrieve or reconstruct an account number is enumerated, access is recertified, retrievals are logged to an accountable user, and the asserted compliance scope boundary contains that capability. | All systems inside and adjacent to the asserted scope boundary. | De-tokenisation capability outside the asserted boundary, an unlogged retrieval, or a diagram that does not match live configuration. |
C39.08 Vault key custody and tested recovery annual · observation | Token vault keys are held under split knowledge with evidenced rotation, and recovery has been exercised against the documented procedure within the last twelve months. | All vaults holding token-to-account mappings. | Rotation not evidenced, custody held by a single individual, or a recovery that has never been exercised. |
C39.09 Dispute liability position evidenced from live messages quarterly · reperformance | The liability position for each acceptance channel is documented against indicators actually observed in production authorisation messages, not inferred from a scheme summary. | All disputes lost in the period, sampled by channel and reason code. | A liability assumption contradicted by the message data, or indicators dropped in transmission with no owner for the resulting exposure. |
C39.10 Token provider concentration and tested exit annual · inspection | Each vault or token service dependency has a criticality assessment, a substitutability position and a migration path that has been tested, not merely drafted. | All vault and token service providers. | A critical token dependency with no tested migration path, or credentials that cannot be moved without cardholder re-entry. |
C39.11 Fraud telemetry separated by token path monthly · reperformance | Fraud and dispute rates are reported separately for token-initiated, credential-on-file and agent-initiated flows. | All transactions in the period. | A blended rate presented to management where a single path is deteriorating inside it. |
C39.12 Agent mandate retrievable with the transaction quarterly · inspection | Where software agents transact against a stored credential, the mandate — scope, limit, expiry and revocation path — is retrievable alongside the transaction record. | All agent-initiated transactions in the period. | An agent-initiated transaction with no retrievable mandate, or one executed outside a stated limit or after expiry. |
Token estate readiness
Fifteen questions an issuer, acquirer, processor or merchant should be able to answer from held evidence. The output is a named gap list, not a number to put on a slide.
Position
0
Not assessable
There is not yet enough held evidence to state a position. Start with the token estate register and the de-tokenisation enumeration; nothing else can be relied on before those exist.
Token estate inventory
Is there one register of every token type in use, network tokens, gateway vault tokens, processor tokens, with the owning entity and requestor identity named for each?
Requestor governance
Is every token requestor identity mapped to a legal entity, an approved channel scope and a named accountable owner in post today?
Provisioning verification
Can the identification-and-verification rule in force on any past date be reproduced, together with the approval and step-up outcomes recorded against it?
Lifecycle propagation
Do reissue, block, close and portfolio-migration events propagate to every token within a stated service level, with exceptions aged?
Token-to-account reconciliation
Is the full active token population reconciled to the active credential population on a stated cadence, rather than sampled?
Domain restriction
Are domain restrictions and transaction-type controls set to the acceptance channels actually in use, and tested against attempted use outside them?
Cryptogram and authentication integrity
Is authentication data verified rather than assumed, with declines evidenced where the cryptogram or indicator set was absent or invalid?
Dispute and liability position
For each acceptance channel, is the liability position documented against the indicators actually observed in production authorisation messages?
Vault and key custody
Are vault keys held under split knowledge with rotation evidence and a recovery rehearsal completed within the last twelve months?
De-tokenisation control
Is de-tokenisation capability enumerated by system and identity, with access recertified and every retrieval logged to an accountable user?
Scope substantiation
Is the reduced cardholder data environment supported by a current data-flow diagram validated against live configuration, not against design intent?
Third-party concentration and exit
For each vault or token service dependency, is there a criticality assessment, substitutability position and a tested exit or migration path?
Fraud telemetry by token path
Is fraud measured separately for token-initiated, credential-on-file and agent-initiated flows rather than blended into one rate?
Agent and mandate evidence
Where software agents transact, is the mandate, scope, limit, expiry, revocation, retrievable alongside the transaction record?
Board and supervisory reporting
Does the board see the token estate position, coverage, orphan ageing, provisioning fraud, scope status, with evidence beneath each figure?
What this is not
- Not a token service. We do not mint, hold or map tokens to account numbers.
- Not a token requestor. We hold no requestor identity and request nothing on a client's behalf.
- Not a certification. Scheme and standards compliance is asserted by the institution and assessed by its qualified assessor.
- Not scheme-confidential content. Everything here rests on public specifications and published developer documentation.
Public references
- EMVCo: Payment Tokenisation Specification, Technical FrameworkThe public specification defining payment tokens, token requestors, domain restriction and lifecycle states.
- PCI Security Standards Council: PCI DSS v4.0.1Requirements governing the cardholder data environment, key management and scope determination.
- PCI SSC: Tokenisation Product Security GuidelinesGuidance on token generation, mapping protection and de-tokenisation controls.
- Visa: Visa Token Service developer documentation (public)Public description of token provisioning, lifecycle management and token requestor registration.
- Mastercard: Digital Enablement Service developer documentation (public)Public description of digitisation, identification-and-verification methods and lifecycle events.
- American Express: Token Service developer documentation (public)Public description of tokenised credential handling for card-not-present acceptance.
State the estate, then defend it
A token estate review runs against held evidence and closes with a gap list, an owner per gap and a test schedule. Engagements are scoped and quoted individually.