Central Bank Digital Currencies (CBDCs): A Practical Guide to the Infrastructure Behind Digital Money

Central bank digital currency (CBDC) is often discussed as if it were simply “cash on a phone.” The engineering reality is broader. A usable CBDC needs an issuance and settlement layer, rules for who can access it, interfaces for banks and payment providers, user wallets or other payment instruments, privacy controls, fraud defenses, operational resilience, and—in some designs—offline capability. The technology is therefore better understood as a payment ecosystem than as a single app or ledger.

CBDC work remains widespread. In the Bank for International Settlements’ survey covering 2024 and published in August 2025, 85 of 93 surveyed central banks—91%—said they were exploring a retail CBDC, a wholesale CBDC, or both. Wholesale work was generally more advanced. See the BIS 2024 CBDC survey results.

CBDC basics: what is actually being digitized?

A CBDC is central bank money represented in digital form. The most important distinction is not whether it uses blockchain, but who the money is for and how claims, records, and access are organized.

The practical takeaway is simple: “digital” does not imply “blockchain.” The BIS has long noted that CBDC infrastructure can use a conventional centrally controlled database or distributed ledger technology (DLT). The right choice depends on policy goals, operating model, resilience requirements, throughput, and governance rather than on a preference for a particular buzzword.

The CBDC infrastructure stack

1. Issuance, redemption, and the core ledger

The core system must represent how much CBDC exists, who or what is entitled to move it, and when transfers become final. A central bank remains responsible for issuance and redemption even when private intermediaries handle customer-facing services.

A useful reference model from the BIS Consultative Group on Innovation and the Digital Economy describes four core retail processes: enrolling users, creating CBDC through “cash-in,” destroying CBDC through “cash-out,” and transferring value within the ledger. Its proposed architecture uses a hybrid model that divides responsibilities between the central bank and private intermediaries. See the BIS retail CBDC architecture proposal.

The ledger design must answer operational questions such as transaction ordering, duplicate-payment prevention, settlement finality, recovery after failure, reconciliation, and auditability. Those requirements matter whether the implementation uses a traditional database, a permissioned DLT, or another architecture.

2. Intermediaries and the two-tier model

Many retail CBDC designs do not expect a central bank to become the everyday service desk for millions of users. Instead, banks or payment service providers can perform customer onboarding, wallet distribution, fraud monitoring, account recovery, and front-line support while the central bank operates or controls the monetary core.

This two-tier pattern preserves room for private-sector competition while keeping the underlying money a central-bank liability. It also reduces the need for a central bank to collect every piece of customer information. However, it creates interface and governance work: intermediaries need consistent rules for identity, sanctions screening, transaction messages, error handling, dispute processes, and service availability.

3. Identity, access, and compliance services

CBDC infrastructure must decide how a person or institution proves the right to open, fund, use, recover, or close a wallet or account. In retail systems, this usually intersects with know-your-customer (KYC), anti-money-laundering (AML), sanctions, fraud, and consumer-protection requirements.

Identity does not have to mean that the central bank sees every user’s real-world identity. Architectures can separate identity data held by a payment provider from transaction identifiers used by the settlement system. The exact privacy model is a policy and legal choice as much as a cryptographic one.

4. APIs and the service layer

Application programming interfaces (APIs) are the connective tissue between the monetary core and the services users actually touch. A well-designed API layer can let multiple banks, wallets, merchants, and fintech providers connect without each needing a custom integration into the central-bank ledger.

BIS Innovation Hub’s Project Rosalind tested this idea using a two-tier retail CBDC model. Its prototype exposed 33 API endpoints across six functional categories and tested more than 30 use cases. The project concluded that an API layer can abstract differences in underlying ledger designs, but it must be consistent with the CBDC’s privacy and operating model. See the Project Rosalind report.

5. Wallets, cards, merchant acceptance, and other endpoints

For a retail CBDC, the endpoint may be a banking app, a dedicated wallet, a smart card, a feature phone flow, a point-of-sale terminal, a QR code, or another form factor. The endpoint is not the currency itself; it is an access mechanism to the CBDC system.

Designers must consider accessibility, lost-device recovery, authentication, merchant acceptance, transaction receipts, limits, accessibility for people with disabilities, and support for users who do not own modern smartphones. A technically strong ledger can still fail as a public payment system if these endpoints are difficult to use.

6. Offline payments

Offline CBDC is one of the hardest infrastructure problems because the system may need to transfer value when neither device can reach the online ledger. That raises the risk of double spending, device compromise, stale balances, and inconsistent state.

The BIS Project Polaris handbook emphasizes that there is no one-size-fits-all offline design. Solutions can involve secure hardware, stored value, device-to-device transfer protocols, risk limits, and later synchronization with the online system. See the Project Polaris offline CBDC handbook. The IMF’s 2025 review of limited-connectivity solutions similarly covers stored-value cards and device-to-device approaches and stresses tradeoffs among form factor, cybersecurity, privacy, and usability; see the IMF limited-connectivity CBDC review.

7. Cybersecurity, resilience, and operational control

Because CBDC can become critical national payment infrastructure, resilience cannot be added at the end. The system needs defense in depth: strong key management, network segmentation, secure software development, vulnerability management, privileged-access controls, transaction monitoring, backup and recovery, disaster-recovery sites, incident response, and regular testing.

Availability targets also need to cover dependencies outside the central ledger: telecom networks, identity services, cloud or data-center infrastructure, intermediary systems, merchant acceptance, and hardware security modules. A CBDC that depends on one fragile external component is not resilient merely because its ledger is replicated.

8. Data architecture and privacy

Privacy is an infrastructure property, not just a policy statement. Designers must decide what data are created, where they are stored, how long they are retained, which parties can link transaction records to identities, and what can be disclosed under law.

Useful techniques include data minimization, pseudonymous identifiers, separation of identity and transaction data, encryption, access logging, and role-based data visibility. More advanced privacy-enhancing technologies may be appropriate in some designs, but they must still support fraud controls, legal obligations, performance, and operational recovery.

9. Interoperability and cross-border links

A CBDC rarely exists in isolation. Domestic infrastructure may need to connect with commercial-bank money, instant-payment systems, card networks, securities platforms, or other CBDCs. Interoperability therefore involves more than message formatting: it can require compatible identity rules, operating hours, liquidity arrangements, foreign-exchange mechanisms, legal frameworks, and settlement models.

For wholesale and cross-border use, experiments such as BIS Project mBridge and Project Icebreaker have explored shared platforms and interlinked domestic systems. These are experiments rather than universal blueprints, but they show why cross-border design choices are easier to address early than to retrofit after national systems are already fixed.

Centralized database or DLT?

The important point is that neither architecture is automatically more “digital.” A CBDC can be technologically advanced without using blockchain, and a DLT-based system still needs conventional infrastructure for identity, APIs, monitoring, devices, support, and governance.

How a retail CBDC payment can flow

1. Enrollment: a bank or approved payment provider verifies the user and creates the required wallet, account, alias, or credentials.
2. Funding: the user converts commercial-bank money or cash into CBDC, causing the corresponding CBDC balance or value representation to be created or allocated under the system’s rules.
3. Payment: the user authorizes a transfer. The intermediary and core infrastructure validate the request, apply limits and controls, and settle the transfer with finality.
4. Notification and records: payer and payee receive status information while the system records only the data required by the chosen architecture and legal framework.
5. Redemption: the user can convert CBDC back into another form of money, reducing or destroying the corresponding CBDC representation as required.

An offline payment changes step three substantially because final online validation may not be available at the moment of transfer. That is why offline functionality requires dedicated risk, hardware, synchronization, and recovery design rather than a simple “offline mode” switch.

Practical checklist for evaluating CBDC infrastructure

• Liability and governance: Who issues the CBDC, who operates each component, and who is accountable when something fails?
• Ledger and settlement: What constitutes finality, and how are duplicates, reversals, and recovery handled?
• Distribution model: Which responsibilities belong to the central bank versus banks and payment providers?
• Identity and compliance: Who performs KYC/AML checks, and what information reaches the central bank?
• Privacy: Is data minimized and separated by role? Can identities be linked to transactions, and by whom?
• Performance: Can the system meet expected peak transaction volumes and latency requirements?
• Resilience: Are there multiple failure domains, disaster-recovery arrangements, and tested continuity procedures?
• Offline capability: Is it required? If so, what secure hardware, value limits, synchronization, and fraud controls are needed?
• Interoperability: Can the CBDC work with existing payment rails, banks, merchants, and possibly foreign systems?
• Access channels: Are smartphones, cards, feature phones, or assisted channels supported for the intended population?
• Vendor strategy: Can components be replaced or upgraded without locking the central bank into one supplier?
• Operational observability: Are monitoring, audit logs, incident detection, reconciliation, and support processes designed from the start?

What current projects reveal about the direction of CBDC infrastructure

Current projects point toward modular ecosystems rather than a single universal CBDC stack. The BIS technical-requirements work highlights interoperability, scalability, user-centered design, security, and data privacy as high-level requirements; see the BIS high-level technical requirements. The IMF’s CBDC Virtual Handbook, updated in November 2025, likewise treats CBDC as a combined policy, operational, technology, privacy, cyber-resilience, and adoption challenge.

The digital euro project offers a current example of how this modular thinking is being applied. After its preparation phase ended in October 2025, the Eurosystem moved into further technical work. Its published architecture work covers areas such as offline functionality, secure exchange of payment information, fraud and risk management, apps and software development kits, resilience, and privacy-preserving processing. In August 2026, the ECB said work on offline functionality was examining secure hardware in smartphones, including embedded Secure Elements and eSIMs, ahead of a pilot planned for the second half of 2027. See the ECB digital euro progress page and the ECB’s August 18, 2026 offline-standards update. These plans remain subject to the European legislative and decision process, so they should be read as project design work rather than proof of a final issued system.

The main lesson: CBDC infrastructure is a system of systems

The ledger is important, but it is only one layer. A production CBDC must coordinate monetary issuance, settlement, intermediaries, identity, privacy, APIs, user devices, merchant acceptance, cybersecurity, offline risk, recovery, and legal governance. The most credible designs therefore start with requirements and operating roles, then choose technology that fits those requirements—not the other way around.

For readers comparing CBDC proposals, the most useful questions are concrete: Who operates the ledger? Who sees user identity? What happens if a bank or network is unavailable? Can users recover funds after losing a device? How does the system prevent double spending offline? Can multiple providers connect through common interfaces? And can the architecture evolve without compromising the integrity of central-bank money? Those questions reveal far more about the quality of a CBDC design than whether the project uses the word “blockchain.”