CBDC architecture is not just a database choice. It is the operating model for public digital money: who issues it, who serves users, where settlement happens, how identity is checked, and how payments move across existing rails. The serious designs now being studied by central banks usually point in one direction. A layered, two-tier CBDC system where the central bank controls the core ledger and regulated intermediaries handle wallets, onboarding, merchant services, and customer support.

That matters if you work in digital assets, banking, payments, or public-sector technology. A CBDC is not another stablecoin. It is central bank money, and its architecture has to satisfy policy, security, privacy, resilience, and operational requirements at national scale.

What CBDC Architecture Means

CBDC architecture describes the technical and institutional structure behind a central bank digital currency. It covers the ledger, issuance rules, payment interfaces, compliance controls, user access channels, and integration points with banking systems.

The Bank for International Settlements, IMF, World Bank, and ITU increasingly frame CBDC as part of a wider payment ecosystem rather than a standalone app. That ecosystem includes users, banks, payment service providers, digital identity systems, communication networks, retail payment rails, and settlement infrastructure.

In plain terms, a CBDC system has to answer five questions:

Who holds the claim, the user directly or an intermediary?
Who operates the ledger?
Who performs KYC, AML, and customer service?
How does the CBDC connect to existing payment rails?
What data is visible to the central bank, intermediaries, and law enforcement?

Core CBDC Architecture Models

Direct CBDC Model

In a direct model, users hold CBDC directly with the central bank. The central bank maintains accounts or token balances and processes transactions itself.

The appeal is clear. The central bank has maximum control over issuance, settlement, and system integrity. There is no intermediary credit risk because the claim sits directly on the central bank.

The problem is just as clear. A direct retail CBDC turns the central bank into a mass-market technology operator. It would need to handle onboarding, wallets, call centers, fraud disputes, cyber defense, uptime, and recovery for millions or even hundreds of millions of users. To be blunt, that is not how most central banks are built.

This model can work in narrow environments, but for large retail CBDC systems it creates heavy operational and cybersecurity exposure.

Intermediated or Two-Tier CBDC Model

The two-tier CBDC model is the design most often favored in policy and technical papers. The central bank issues CBDC and operates the core settlement infrastructure. Commercial banks and payment service providers distribute CBDC and offer customer-facing services.

You still get central bank money at the base layer. But users interact through familiar channels: bank apps, payment wallets, merchant terminals, or government payment portals.

This model fits existing financial systems better. Banks already perform identity checks, AML screening, account recovery, fraud monitoring, and customer support. PSPs already know how to build user interfaces and merchant tools. The central bank can focus on monetary issuance, settlement finality, rules, and oversight.

The trade-off is third-party risk. If intermediaries manage wallets or process payment instructions, the architecture needs strong access controls, audit trails, certification, and supervisory rules. A weak intermediary can still become a weak point.

Hybrid CBDC Model

A hybrid CBDC architecture sits between direct and intermediated designs. The central bank may keep a record of retail holdings, while intermediaries provide front-end access and some transaction processing.

This can preserve central bank-backed settlement and improve data integrity, while still letting private firms build useful payment services. Hybrid models appeal where policymakers want a direct claim on the central bank but do not want the central bank to run every retail function.

Indirect CBDC Model

In an indirect model, users hold claims on intermediaries rather than directly on the central bank. The central bank may only maintain wholesale accounts for those intermediaries.

This reduces the operational burden on the central bank, but it weakens one of the main arguments for CBDC: direct access to central bank money in digital form. For many retail CBDC goals, indirect designs start to look more like regulated e-money than true CBDC.

Main Components in a CBDC System

Different jurisdictions may use different platforms, but CBDC reference architectures usually share the same building blocks.

Issuance and Distribution

This module creates, destroys, and allocates CBDC units. It also supports policy rules such as holding limits, tiered remuneration, or transaction caps. These choices are not cosmetic. A wallet cap can reduce bank deposit flight during stress, while tiered remuneration can influence how users treat CBDC compared with deposits or cash.

Identity, Access, and Compliance

A retail CBDC needs identity and access management. That covers KYC, authentication, role-based permissions, sanctions screening, AML monitoring, and counter-terrorist financing controls.

Privacy is the hard part. If every low-value payment creates a fully visible state record, public trust will suffer. Many designs now explore tiered identity, where small payments may carry more privacy and higher-value transfers require stronger disclosure.

Ledger and Settlement Layer

The core ledger records ownership and processes transfers. It may use distributed ledger technology, a conventional database, or a hybrid design. The label matters less than throughput, finality, resilience, auditability, and governance.

DLT is not automatically the better choice. If one authority controls issuance, validator membership, rules, and final settlement, a well-engineered centralized ledger may be simpler and faster. Permissioned DLT makes more sense when multiple trusted institutions need shared state and independent verification.

Transaction Management

This layer validates payment instructions, checks balances, orders transactions, and records final state. It may also support atomic transfers, conditional payments, offline payments, and dispute workflows.

A practical detail: two-phase commit designs look elegant in diagrams, but timeout handling is where teams get burned. If a coordinator fails after locking inputs but before final commit, your recovery logic decides whether users see a clean retry or a mysterious stuck balance. OpenCBDC research from the Federal Reserve Bank of Boston and MIT paid close attention to partitioning, validation, and commit flow for exactly this reason.

Wallets and User Interfaces

Wallets are the access layer. They may come from banks, fintech firms, government agencies, or approved payment interface providers. Wallets handle balance display, QR payments, merchant acceptance, transaction history, authentication, and account recovery.

For developers, this is where CBDC starts to resemble payment API work. Expect strong rules around permissions, logging, transaction signing, and fraud controls.

Operations, Monitoring, and Resilience

CBDC is critical national infrastructure. It needs monitoring, incident response, disaster recovery, key management, penetration testing, and business continuity planning. A denial-of-service attack against a national retail CBDC would not be a normal outage. It would be a public confidence event.

CBDC Payment Layers Explained

Legal and Institutional Layer

This layer defines what the CBDC is. Is it a direct liability of the central bank? What law governs settlement finality? Who resolves disputes? Who is responsible for data protection?

The BIS CBDC pyramid places these legal and institutional questions at the base, because the technology cannot fix an unclear claim structure.

User and Payment Solutions Layer

This is where individuals, businesses, government departments, and merchants initiate or receive payments. It includes mobile wallets, point-of-sale systems, invoices, merchant apps, and government disbursement tools.

If CBDC is meant to support financial inclusion, this layer has to work for users with low-end phones, weak connectivity, limited documentation, or accessibility needs.

Payment Infrastructure Layer

CBDC will rarely replace all payment rails. Most serious designs integrate with existing systems such as real-time gross settlement systems, automated clearing houses, card networks, fast payment systems, and national switches.

That integration is essential. A merchant does not want five disconnected balances. A bank does not want a reconciliation nightmare. CBDC has to move cleanly between deposits, wallets, and settlement accounts.

Connectivity and Digital Identity Layer

CBDC systems rely on secure networks, APIs, authentication services, device binding, and digital identity frameworks. In many countries, CBDC architecture is becoming part of broader digital public infrastructure, alongside instant payments and national identity systems.

Programmability in CBDC Architecture

Programmable payments come up often in CBDC design, but the safest approach is usually to keep complex logic out of the core ledger. Put conditional payments, escrow, spending rules, and automated compliance in the service or application layer, where they can be updated without threatening settlement stability.

This mirrors good smart contract architecture. Keep the base layer simple. Move business logic to controlled modules. If you are learning this area, Blockchain Council's Certified Blockchain Developer™ and Certified Smart Contract Developer™ are useful learning paths for understanding ledgers, token logic, and secure transaction design. For policy and architecture roles, Certified Blockchain Expert™ and Certified Blockchain Architect™ are relevant next steps.

Cross-Border and Multi-CBDC Designs

Cross-border payments are one of the strongest reasons central banks study CBDC. BIS research describes three broad multi-CBDC models:

Compatible systems: national CBDCs use aligned standards but stay separate.
Interlinked systems: national CBDCs connect through shared interfaces or bridges.
Single shared system: multiple central banks operate on a common platform.

The deeper the integration, the harder the governance. Exchange rates, sanctions, settlement finality, liquidity, operating hours, and dispute rules all have to be agreed. A shared platform may cut friction, but it also demands trust between central banks and clear legal arrangements.

What CBDC Architecture Is Becoming

The direction is fairly clear. CBDC architecture is moving toward modular, layered, two-tier systems. The central bank runs the core monetary and settlement layer. Regulated intermediaries handle access, wallets, compliance, and payment services. Existing payment rails stay part of the system.

The winning designs will not be the most exotic. They will be the ones that settle reliably, protect privacy, scale under stress, recover from failure, and fit the legal framework of the country using them.

Want to build expertise here? Start by mapping one CBDC design into four layers: legal claim, settlement ledger, intermediary services, and user access. Then compare a DLT version with a conventional database version. That exercise will teach you more than any diagram. After that, deepen the technical foundation with Blockchain Council certifications in blockchain architecture, smart contracts, and digital assets.

CBDC Architecture Explained: Models, Components, and Payment Layers