Who is accountable when a national payment system rolls out tokenization across banks, wallets, and merchants?

Why This Matters for Security Teams

National payment tokenization is not just a technical change to card or wallet data. It creates a shared trust model across the token service provider, issuing banks, wallets, acquirers, and merchants, where one weak integration can undermine the whole ecosystem. Security teams often assume the token itself lowers risk enough to simplify governance, but operational accountability is what keeps the token model trustworthy under change, exception handling, and incident response.

This matters because tokenization shifts the security boundary. Instead of protecting only primary account numbers, organisations must protect token lifecycle controls, detokenization paths, key management, and partner onboarding. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames accountability around control ownership, evidence, and continuous monitoring rather than vague shared responsibility. In the payment ecosystem, that discipline is essential when banks, wallets, and merchants each make local design choices that can affect the same transaction flow.

NHIMG research on the Guide to the Secret Sprawl Challenge shows why distributed environments fail when sensitive material spreads across multiple systems and teams without clear ownership. In practice, many security teams encounter token misuse only after a partner integration, exception rule, or support workflow has already expanded the blast radius.

How It Works in Practice

Accountability follows the control plane, not just the transaction path. The national payment operator usually owns the token model, scheme rules, lifecycle policy, and interoperability requirements. Issuing banks typically own customer identity binding, token approval for their users, risk decisions, and revocation logic. Wallet providers and merchants are accountable for secure storage, display, use, and protection of tokens in their environment. Technology partners may operate infrastructure, but they do not inherit the business accountability of the institutions that authorise token use.

That means a workable governance model needs named owners for each stage: token issuance, provisioning, storage, use, suspension, renewal, detokenization, and dispute handling. Current guidance suggests documenting these responsibilities in contract language, control matrices, and incident playbooks so that a token failure can be traced quickly to the responsible party. For sensitive integration work, the pattern should resemble the controls discussed in Salesloft OAuth token breach: credentials and delegated access become high-value assets when they are reused across systems without strong lifecycle governance.

• Define one accountable owner for the token policy and one for each participant’s implementation.
• Require cryptographic and operational logging for token issuance, changes, and revocation.
• Use approval workflows for onboarding banks, wallets, and merchants into the token ecosystem.
• Test fallback, exception, and recovery paths as part of the payment change process.

For implementation detail, the 2025 State of NHIs and Secrets in Cybersecurity reports that 44% of NHI tokens are exposed in the wild, which is a useful reminder that token-like credentials fail when ownership and handling are unclear. These controls tend to break down when multiple processors, nested wallet providers, or cross-border settlement partners each interpret the same token lifecycle differently because revocation and exception handling become inconsistent.

Common Variations and Edge Cases

Tighter token governance often increases integration overhead, requiring organisations to balance speed of rollout against the cost of stronger assurance. That tradeoff is real in national payment systems, where interoperability pressure can encourage broad exceptions, but exceptions are also where accountability becomes blurred.

There is no universal standard for every payment ecosystem design, so current guidance suggests distinguishing between policy accountability and technical operation. A bank may be accountable for approving a token for its customer, while a platform vendor may be responsible for uptime and secure processing. Merchants often control only acceptance and storage boundaries, but they still need clear duties for replay protection, token display, and fraud escalation. The lesson from the JetBrains GitHub plugin token exposure is that access artifacts become risky when they move outside the intended control boundary.

For payment networks with multiple domestic and international participants, the edge case is not the normal transaction. It is migration, fallback routing, wallet re-provisioning, and dispute reversal. Those events must have an explicit accountable owner, because a token ecosystem that works on the happy path can still fail badly when one participant changes formats, policies, or revocation timing without coordinated oversight.

Related resources from NHI Mgmt Group

• Who is accountable for enforcing AI data-sharing policy across the organisation?
• Who is accountable when automated threat hunting triggers remediation actions across SOC and engineering workflows?
• How should security teams make NHI best practices usable across the business?
• Who remains accountable when wallet-based identity is used across banks and fintechs?