A Central Bank Digital Currency is a digital form of sovereign money issued by a central bank. It may be designed for wholesale use between financial institutions or for retail use by businesses and consumers. The implementation model determines its impact on banks, payments, and monetary policy.
What CBDC Means in Practice
A CBDC is not just a new payment rail, it is a sovereign money design choice. The practical meaning shifts depending on whether the currency is wholesale or retail, and whether access is mediated through banks, payment providers, or direct central-bank interfaces.
That design choice affects settlement speed, interoperability, offline usability, transaction traceability, and who bears the operational burden for onboarding, fraud handling, customer support, and continuity. Those are not abstract policy issues, they shape how the currency behaves in real payment flows.
In many discussions, CBDC is compared with deposits, card payments, stablecoins, and instant payment systems. The comparison is useful, but CBDC is distinct because the liability sits with the central bank rather than a commercial issuer, which changes trust, finality, and the structure of the payment ecosystem.
How CBDC Changes the Money and Payments Stack
Wholesale CBDC would primarily affect interbank settlement, treasury operations, and market infrastructure. Retail CBDC would extend the design into consumer and merchant payments, where scale, privacy expectations, and user experience become far more important.
The implementation model determines whether CBDC sits alongside commercial bank money or disintermediates parts of the banking layer. That matters because the same term can describe very different architectures, from token-based models to account-based models, and each has different implications for resiliency and supervision.
For practitioners, the important point is that CBDC introduces a new trust boundary. Even where distribution is intermediated, the central bank, payment service providers, banks, and wallet operators must all be clearly separated in responsibility, because control failures can emerge at the handoff points.
Because these systems depend on digital access, signing, and transaction authorization, controls around keys, authentication, and transaction integrity become core design concerns. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control vocabulary for the access control, audit, and system integrity dimensions that a CBDC programme would need to formalise.
Security, Privacy, and Trust Implications
CBDC concentrates high-value transaction infrastructure into a digitally mediated system, so the main security questions are availability, fraud resistance, privacy, and operational trust. If the architecture is weak, the result is not only financial loss but also loss of confidence in the currency itself.
Privacy is especially sensitive in retail designs. A CBDC can support stronger traceability than cash, but that same traceability can create surveillance concerns if data access, retention, and lawful access controls are not carefully bounded. NIST Privacy Framework is relevant where the design must balance financial integrity with data minimisation and governance.
Identity and authentication also matter because payment legitimacy depends on proving who may initiate or receive value. NIST SP 800-63 Digital Identity Guidelines is relevant wherever CBDC access relies on digital onboarding, assurance levels, or phishing-resistant authenticators.
Operationally, the system also depends on secure software delivery and infrastructure hardening. Where wallet software, APIs, or payment middleware are in scope, controls around API exposure, build integrity, and baseline hardening become part of the trust model rather than optional implementation details.
How to Read CBDC as a Governance Term
CBDC is best understood as a governance term as much as a technology term. It sits at the intersection of monetary policy, payments infrastructure, financial stability, and digital trust, so the most important questions are usually about design choices rather than the acronym itself.
Why practitioners should care: CBDC design can alter payment intermediation, data visibility, and operational responsibility across the financial stack. Those choices affect banks, fintechs, supervisors, and end users differently, so the term should always be read in its implementation context.
What to watch for: The biggest source of confusion is treating all CBDCs as the same. Retail and wholesale models, account and token designs, and direct and intermediated distribution each produce different security and governance requirements.
For programme owners, the useful question is not whether CBDC is “good” or “bad”, but which trust assumptions it introduces, which existing payment controls it replaces, and which new controls become mandatory because sovereign money now depends on digital infrastructure.
Risk and Threat Considerations
CBDC creates material risk around availability, privacy, and systemic trust because it can become a critical payment dependency. If the architecture is poorly governed, outages, compromised wallet access, fraud, or overbroad transaction visibility can quickly move from a technical issue to a financial and public-confidence issue.
Failure mechanism: Attackers or failures can target the wallet layer, transaction APIs, identity proofing, key management, or central payment infrastructure, then exploit those weaknesses to disrupt payments, impersonate users, or expose transaction data.
Impact: The result can be payment interruption, fraud, loss of confidentiality, regulatory pressure, and reduced trust in the currency model itself, especially if the system scales into retail use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC — Access Control | CBDC systems depend on strong access decisions for wallet, operator, and payment functions. |
| IA — Identification and Authentication | CBDC access, onboarding, and transaction initiation depend on verified digital identity and authenticators. | |
| AU — Audit and Accountability | CBDC needs traceable transaction and administrative activity for fraud detection and governance. | |
| Recommendation — Enforce least privilege across CBDC operators, wallet services, and payment interfaces. Apply strong authenticator and identity assurance controls for CBDC participants and service operators. Log and retain CBDC administrative and transaction events for monitoring and investigation. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, and Federation Assurance | CBDC onboarding and access depend on assurance levels for identity proofing and authentication. |
| Recommendation — Set assurance requirements for CBDC onboarding, authenticators, and federated access paths. | ||
| SOC 2 (AICPA) | Security — Security | CBDC platforms require security controls that protect infrastructure, access, and transaction integrity. |
| Privacy — Privacy | Retail CBDC designs can materially affect transaction visibility and personal data handling. | |
| Recommendation — Implement security controls that preserve CBDC confidentiality, integrity, and availability. Limit CBDC data use and access to preserve privacy expectations and lawful processing. | ||
Practitioner Guidance
Governance implication: CBDC programmes should define ownership across the central bank, intermediaries, and wallet operators before implementation choices are locked in. The operating model, not just the technology, determines who is accountable for authentication, recovery, customer protection, and incident response.
Common misunderstanding: CBDC is often discussed as if it were a single architecture. In practice, the security and governance profile depends on whether it is wholesale or retail, account or token based, and whether distribution is direct or intermediated.
Practitioner takeaway: Treat CBDC as a trust-design problem first, and a payments feature second, because the design determines the controls you will need to make it safe at scale.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
