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. Anyone trying to build a working command of this topic usually starts with a structured Certified Central Bank Digital Currency (CBDC) Expert foundation before comparing the specific architecture models below.

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. Because that ecosystem increasingly overlaps with tokenized deposits and other digital assets, many professionals pair this CBDC study with a Certified Digital Assets Expert background to cover both sides of the picture.

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. Engineers building out this monitoring and resilience layer often round out their skills with a broader Tech Certification, since incident response, key management, and disaster recovery are general infrastructure disciplines applied to a regulated payments setting.

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. And if your role involves presenting one of these architecture choices to leadership, regulators, or partners, a Marketing Certification can help you turn that comparison into a case that actually persuades a non-technical audience.

FAQs

1. What is CBDC architecture?

CBDC architecture is the overall design that determines how a central bank digital currency is issued, distributed, accessed, transferred, recorded, settled, secured, and governed.

It defines the roles of the central bank, commercial banks, payment service providers (PSPs), wallets, ledgers, identity systems, and payment networks.

In simple terms, CBDC architecture answers: who does what, where the money is recorded, and how a payment gets from one user to another without the financial system having an unfortunate afternoon.

2. What are the main CBDC architecture models?

CBDC architectures are commonly discussed using models such as:

Direct CBDC
Intermediated or indirect CBDC
Two-tier CBDC
Hybrid CBDC

These categories describe how responsibilities are divided between the central bank and private intermediaries.

They are separate from technical choices such as centralized databases versus distributed ledgers.

3. What is a direct CBDC architecture?

In a direct CBDC model, the central bank assumes substantial responsibility for providing CBDC services directly to end users.

A simplified structure is:

Central Bank → Individuals and Businesses

The central bank might maintain customer balances, process transactions, and potentially provide account or wallet services.

This offers strong central control but creates a substantial operational burden.

4. What is an intermediated CBDC architecture?

In an intermediated CBDC, regulated private institutions provide most customer-facing services.

The structure might be:

Central Bank → Banks/PSPs → Users

Banks and PSPs can handle wallets, customer onboarding, authentication, compliance, payments, and support while the CBDC remains a central bank liability.

5. What is a two-tier CBDC architecture?

A two-tier model explicitly divides responsibilities between two institutional layers.

Tier 1: Central Bank

Issues CBDC, establishes system rules, and operates or governs core monetary and settlement infrastructure.

Tier 2: Banks and PSPs

Distribute CBDC and provide wallets, payment services, customer verification, and related services.

This model preserves a significant role for the existing financial sector.

6. What is a hybrid CBDC architecture?

A hybrid CBDC combines central-bank control over critical records or infrastructure with private-sector customer services.

For example:

Central Bank → authoritative CBDC records

Banks/PSPs → customer relationships and payments

A hybrid structure can provide safeguards if an intermediary fails while avoiding the need for the central bank to provide every retail service itself.

7. What are the main components of CBDC architecture?

A retail CBDC system could contain:

Core ledger
Issuance and redemption system
Digital wallets
Banks and PSPs
Identity infrastructure
APIs
Payment-routing services
Authentication systems
Fraud and compliance controls
Settlement mechanisms
Offline-payment infrastructure
Cybersecurity systems
Monitoring and recovery services

These components can be organized differently depending on policy and technical choices.

8. What is the CBDC core ledger?

The core ledger or equivalent authoritative record establishes the state of CBDC balances, tokens, or transactions.

Its functions may include:

Issuance → validation → transfer → settlement → redemption

The ledger might use:

Conventional databases
Distributed databases
Distributed ledger technology
Permissioned blockchain
Hybrid systems

CBDC does not inherently require blockchain.

9. What role do digital wallets play?

CBDC wallets provide users with access to digital central bank money.

A wallet may allow users to:

View balances
Send CBDC
Receive CBDC
Authenticate payments
Scan merchant codes
Review transactions
Manage credentials
Make certain offline payments

Depending on the design, the wallet may store actual token-like value or simply credentials controlling funds recorded elsewhere.

10. What role do APIs play?

Application Programming Interfaces (APIs) allow CBDC components and financial institutions to communicate.

They could connect:

Wallets ↔ Banks/PSPs

Banks/PSPs ↔ CBDC Core

Merchants ↔ Payment Providers

Government Systems ↔ CBDC Infrastructure

Standardized APIs are especially important in architectures that permit multiple wallet and payment providers.

11. What are the major CBDC payment layers?

A useful conceptual architecture has six layers:

1. User Layer
Consumers → businesses → merchants

2. Access Layer
Wallets → cards → mobile apps → other devices

3. Intermediary Layer
Banks → PSPs → fintech providers

4. Payment Layer
Authentication → routing → fraud controls → compliance

5. Ledger and Settlement Layer
Validation → balances/tokens → finality → issuance/redemption

6. Governance Layer
Central bank → regulation → privacy → security standards

Actual implementations can combine these layers.

12. How does a CBDC payment move through these layers?

Suppose Alice pays a merchant 40 CBDC units.

A simplified journey is:

Alice's Wallet

↓

Authentication

↓

Alice's Bank/PSP

↓

Payment API and Routing

↓

CBDC Validation/Ledger

↓

Settlement

↓

Merchant's Bank/PSP

↓

Merchant Wallet

Several of these operations could occur simultaneously and within fractions of a second.

13. What is account-based versus token-based architecture?

An account-based CBDC primarily verifies that the person initiating a payment is authorized to use an account or balance.

A token-based CBDC focuses more on validating the digital value and the spender's authority to transfer it.

A useful shorthand is:

Account-based → verify account authority

Token-based → verify value and spending authority

Modern architectures can combine characteristics of both.

14. What is centralized versus distributed architecture?

A centralized architecture maintains authoritative processing or records through centrally controlled infrastructure.

A distributed architecture distributes certain processing, recordkeeping, or validation functions across multiple authorized participants.

Importantly:

Distributed infrastructure ≠ decentralized currency

The central bank can remain the sole issuer and ultimate governing authority even when distributed technology is used.

15. How does identity fit into CBDC architecture?

Identity can be handled separately from the core monetary ledger.

For example:

Identity Layer → Bank/PSP

Transaction Layer → CBDC infrastructure

This separation can support privacy by limiting unnecessary sharing of personally identifiable information.

Identity systems may support:

KYC
Authentication
Credential recovery
Transaction authorization
Compliance
Fraud prevention

16. How does offline CBDC fit into the architecture?

Offline CBDC enables certain payments without immediate connectivity to the core system.

A simplified flow is:

Payer Device → Secure Local Transfer → Recipient Device → Later Synchronization

Offline architecture may require:

Secure hardware
Offline balance limits
Double-spending controls
Device authentication
Transaction counters
Reconciliation procedures

Offline functionality can improve resilience and financial inclusion, but it adds substantial security complexity.

17. How does CBDC architecture support interoperability?

CBDC may need to interoperate with:

Commercial bank accounts
Instant-payment systems
Merchant networks
ATMs
Government payment platforms
Foreign CBDCs
Other digital-asset systems

Interoperability depends on common APIs, messaging standards, identifiers, security protocols, settlement rules, and governance arrangements.

Without those, “interoperability” becomes another pleasant word in a strategy document.

18. What security layers does CBDC architecture need?

Security should operate across the entire architecture.

Potential controls include:

Encryption
Digital signatures
Multi-factor authentication
Hardware security modules
Secure elements
Key management
API security
Network segmentation
Fraud monitoring
Access controls
Incident response
Disaster recovery

CBDC infrastructure could become systemically important, so resilience against both cyberattacks and ordinary technical failures is essential.

19. How do the major CBDC architecture choices fit together?

Design Question	Possible Choices
Distribution	Direct, intermediated, two-tier, hybrid
Representation	Account-based, token-based, hybrid
Ledger architecture	Centralized, distributed, hybrid
User access	Mobile, web, cards, hardware devices
Connectivity	Online, offline-capable
Identity	Full identification, tiered models, intermediated identity
Settlement	Central-bank core, shared infrastructure
Provider model	Central bank, banks, PSPs, multiple providers
Interoperability	Closed-loop or connected to broader payment systems

These choices are not mutually exclusive categories. A CBDC could simultaneously be two-tier, account-oriented, centrally settled, multi-wallet, API-based, and offline-capable.

20. What does a complete CBDC architecture look like?

A simplified end-to-end model is:

Central Bank & Governance Layer
Issuance → monetary rules → oversight → settlement authority

↓

Core CBDC Layer
Ledger → validation → issuance/redemption → finality

↓

Integration Layer
APIs → messaging → interoperability → routing

↓

Intermediary Layer
Banks → PSPs → fintech providers → compliance services

↓

Access Layer
Mobile wallets → cards → hardware devices → merchant terminals

↓

User Layer
Consumers → businesses → government

The most important point is that CBDC architecture is not one technology choice. It is a collection of policy and engineering decisions about issuance, distribution, identity, privacy, ledger design, settlement, security, interoperability, and access.

The best architecture is therefore not automatically “blockchain,” “centralized,” or “two-tier.” It is the architecture that meets the jurisdiction's requirements for security, resilience, privacy, financial stability, inclusion, scalability, and payment efficiency without creating more complexity than the benefits justify.