What Is Central Bank Digital Currency? Definition & Examples

A central bank digital currency is a digital form of sovereign money issued by a central bank. It is distinct from private stablecoins because it carries public monetary authority and policy implications. In policy discussions, it often raises questions about financial system design, privacy, access, and the balance between innovation and control.

Expanded Definition

A central bank digital currency, or CBDC, is a digital liability of the state that sits alongside cash and reserves rather than replacing commercial bank deposits by default. Its defining feature is sovereign issuance: the currency is backed by the central bank’s monetary authority, so its design is shaped by policy, settlement, and legal-finality decisions as much as by technology.

The term is often used differently across policy debates. In some jurisdictions it refers to a retail instrument for public use; in others, it describes a wholesale settlement asset for banks and financial market infrastructure. That distinction matters because the operational model changes the privacy profile, the access model, and the resilience requirements. A common misunderstanding is to treat CBDC as a single product category. In practice, design choices such as token-based versus account-based access, offline capability, and intermediary participation define what the currency can and cannot do.

For a standards-oriented overview of the policy and design questions, the BIS general principles for CBDC are a useful authority because they frame the term through public-policy, interoperability, and trust requirements rather than vendor implementation detail.

Examples and Use Cases

CBDC appears in practice as a design choice inside payment modernization, monetary policy, and financial inclusion programmes. The same term can describe very different systems depending on whether the goal is retail access, bank settlement, or cross-border transfer.

Retail wallet models where individuals hold a direct claim on the central bank through approved intermediaries.
Wholesale settlement models used by financial institutions for high-value transfers and liquidity management.
Offline payment designs intended to support resilience when connectivity is limited or unavailable.
Programmable payment experiments that test conditional transfers, though this remains a contested policy area rather than a settled standard.
Cross-border pilot concepts that explore faster settlement, reduced reconciliation overhead, and tighter atomicity between institutions.

The implementation tradeoff is usually between control and openness. Stronger identity verification and transaction traceability can improve oversight, but they can also narrow privacy and reduce the cash-like properties that many CBDC debates are trying to preserve.

Security Implications

CBDC changes the security conversation because it concentrates trust in a state-backed digital rail rather than in a purely commercial payment stack. If the underlying wallet, identity, or transaction architecture is misdesigned, failure is not limited to one payment app. It can affect settlement integrity, public confidence, continuity of payment services, and the credibility of the monetary instrument itself.

One practical consequence is that design flaws can create disputes about who may transact, who may be excluded, and what level of transaction data is visible to intermediaries or the state. Weak access controls, poor cryptographic design, or fragile offline reconciliation can also create double-spend risk, reconciliation gaps, or service denial under load or outage conditions. For a public monetary system, even limited availability loss can become a policy issue because citizens may not distinguish technical downtime from institutional failure.

Practitioners should also note the boundary between privacy and recoverability. A system that is too opaque may hinder fraud investigation and compliance, while a system that is too observable may erode trust and reduce adoption.

Domain and Governance Relevance

CBDC is primarily a monetary-policy and payments-infrastructure term, but it has clear governance overlap with cybersecurity and identity. The moment a CBDC uses wallets, intermediaries, credentials, APIs, or controlled access tiers, questions of assurance, authentication, and recovery become operationally material. That is especially true for retail designs, where millions of users may depend on the same identity and payment architecture.

For NHI and identity governance, the relevant change is scale. A CBDC ecosystem may involve service accounts, integration keys, device-held credentials, and machine-to-machine settlement services that must be inventoried, scoped, rotated, and monitored. Those are not incidental details. They shape whether the system can be trusted as a public utility and whether operational control remains intact during incident response, outage recovery, or policy change.

In short, CBDC is not just about money representation. It is about how sovereign value is authenticated, transferred, supervised, and kept available under public scrutiny.

Risk and Threat Considerations

CBDC introduces material risks around concentration, surveillance, availability, and trust. Because it is a sovereign payment instrument, weaknesses in design or operations can have system-wide effects rather than isolated product impact. The risk surface expands when identity, wallet access, and settlement logic converge in one ecosystem.

Failure mechanism: Centralised authentication, ledger access, or intermediary dependency can create single points of failure. Adversaries may target wallet credentials, transaction APIs, or settlement infrastructure to steal value, disrupt availability, or abuse trusted access paths. Poor offline reconciliation or privacy controls can also produce integrity gaps or unwarranted transaction visibility.

Impact: The result can be payment disruption, loss of public confidence, compromised transaction data, fraud exposure, or governance pressure to tighten controls in ways that reduce usability and inclusion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV — Govern	CBDC is a public trust and governance system with policy, accountability, and oversight implications.
Recommendation — Define ownership, risk tolerance, and oversight rules for CBDC operations and policy changes.
CIS Controls v8	5 — Account Management	CBDC wallets and operator consoles depend on strong account lifecycle control and access governance.
	6 — Access Control Management	CBDC access paths must be tightly scoped to reduce fraud, misuse, and administrative overreach.
	8 — Audit Log Management	CBDC systems need strong logging to support investigation, reconciliation, and oversight.
Recommendation — Enforce account lifecycle controls for wallet users, administrators, and settlement operators. Restrict CBDC access paths to the minimum permissions required for each role and service. Record and protect transaction and admin logs to support dispute handling and fraud detection.
NIST SP 800-63	IAL2 — Identity Assurance Level 2	Retail CBDC use cases often depend on identity proofing strength for wallet access decisions.
Recommendation — Set identity proofing assurance to match the transaction value and account recovery risk.
OWASP Non-Human Identity Top 10	NHI-01 — NHI Inventory and Ownership	CBDC platforms rely on machine credentials, API keys, and service identities that need ownership.
Recommendation — Inventory and assign owners for CBDC service identities, keys, and integration credentials.

Central Bank Digital Currency