Decoding CBDC — Taxonomy of Architectural Design Options

Physical media such as smart cards, SIM cards in feature phones, or hardware wallets that operate without requiring any additional software installation, tying access to the physical device itself.

Not tied to any specific device — involves installed apps on any user's device. Most flexible interface, supporting all transaction types. The dominant approach in global CBDC pilots including the Digital Euro and e-CNY.

Enables users to access CBDC services directly through a browser, without any software installation. Maximises reach and accessibility across devices, though may offer fewer features than native applications.

Users enter transaction details themselves — such as the recipient's address — via SMS or by typing into an application. Universal fallback that works on basic phones, but error-prone for long cryptographic addresses.

Users start a transaction by scanning visual elements like QR codes or barcodes, offering a faster and more convenient alternative to manual entry. Requires a camera-equipped device; widely used in existing payment systems.

Enables contactless payments through Bluetooth or NFC. Fastest in-store UX and supports full offline capability. Requires NFC-capable hardware — the approach adopted for Digital Euro offline payments.

Comprehensive identity verification through in-person or remote methods such as video identification for all users. The ECB requires intermediaries to use existing KYC data or conduct a full new KYC process for the Digital Euro.

Links the extent of identity information required to usage limits. For example, a user might only need a phone number to access basic functions with low daily transaction limits, while higher tiers require full KYC. Used in China's e-CNY pilot.

Central banks and intermediaries have full data access to all transactions and user identities. Simplest architecture but raises significant public acceptance concerns around financial surveillance.

Intermediaries process KYC data for regulatory purposes but use privacy-enhancing technologies (PETs) such as blind signatures to conceal user identities before forwarding transactions to the CB. Reflects the Digital Euro's online transaction design.

Protects both identity and transaction details from the CB using tools like homomorphic encryption. Selected intermediaries or regulatory bodies retain access to unencrypted data to conduct required regulatory checks.

Maximum privacy — restricts access for both CB and intermediaries. Relies on self-custody mechanisms combined with PETs such as zero-knowledge proofs (ZKPs) for threshold-based regulatory checks. Applied for Digital Euro offline transactions.

Requires users to prove knowledge of a secret, such as a password or a verification code received on another device in a two-factor authentication process. Universal and low-cost, but vulnerable to phishing and theft.

Uses unique physical characteristics such as fingerprints or facial features as identifiers. High security and convenience, but raises serious privacy concerns — biometric data is irrevocable if compromised.

Combines several authentication methods in parallel to enhance both security and usability — for example, a PIN combined with a facial scan. The ECB appears to favour this approach for the Digital Euro for security purposes.

Both verification (balance checks, valid signatures) and validation (global ledger state check) are conducted in real-time via internet through authorized third parties. The most secure approach — prevents double-spending with highest certainty.

Verification occurs locally on the user's device without connectivity; validation takes place once the device reconnects or during periodic synchronization. Applied for Digital Euro offline transactions — supports intermittent connectivity.

Both steps occur locally, often within secure hardware elements (TEE/SE). Complete offline capability — ideal for disaster resilience. Considered less secure due to absence of real-time ledger synchronization; creates risk of undetected manipulation.

Targets individual users for everyday consumer payments. Constitutes a direct claim on the central bank, offering state-backed safety in a natively digital format. Examples: Digital Euro, e-CNY, eNaira — the most common CBDC type globally.

Designed for interbank payments — restricts access to financial institutions and authorized authorities. Modernizes large-value payment systems by enhancing efficiency, programmability, and interoperability. Examples: Project Helvetia, mBridge.

Supports both retail and wholesale use cases on a single platform. One implementation involves wholesale CBDCs issued to financial institutions, which are then converted into retail CBDCs for end users. Maximum flexibility; highest architectural complexity.

Users hold a direct claim on the CB, which is responsible for issuing, managing, and storing all retail-level data. Conceptually simple but often considered impractical due to the high operational burden it places on the central bank.

Delegates issuance and management entirely to intermediaries, who must fully back CBDCs with central bank reserves. Users hold claims against intermediaries, not the CB. Resembles the familiar two-tier commercial banking model.

The CB issues the CBDC and users hold a direct claim against it, while intermediaries handle retail operations. The CB stores only aggregated wholesale data — making individual claim verification more costly if an intermediary fails.

The CB issues CBDC with direct user claims and periodically retains a full retail ledger, enabling efficient fund recovery if an intermediary fails. Intermediaries handle all retail operations. The Digital Euro's current design indicates this model.

Functions like traditional digital money — carries no embedded logic or restrictions. Simplest design with lowest risk of unintended constraints. The ECB has clearly communicated that the Digital Euro will be non-programmable money.

Conditional execution where predefined rules — such as time-based triggers or event confirmations — are applied after CBDC issuance via smart contracts. Automates settlement and reduces counterparty risk. The ECB will allow this for the Digital Euro.

Conditions are built into the CBDC itself at the time of issuance — restricting where it can be used or defining a limited validity period. One use case: crisis-issued interval CBDCs designed to expire and encourage spending. Deeply controversial; risks undermining fungibility.

All data maintained in a conventional central database, such as those used in Real-Time Gross Settlement (RTGS) systems. Highest efficiency and central control, but creates a single point of failure. The most common approach across CBDC pilots.

Data is partitioned and distributed across multiple physical locations for resilience and efficiency purposes. Improves fault tolerance compared to centralized storage without the full overhead of distributed ledger synchronization.

All data replicated across multiple independent nodes, each maintaining a synchronized copy of the full ledger. Replication is a core architectural feature ensuring consistency, transparency, and fault tolerance — not merely a backup mechanism.

Ownership established by linking user identity to an account holding all CBDC balances. Transfers reduce the sender's balance and credit the recipient's. Requires continuous online connection — multiple verification steps must pass through a financial institution.

Ownership tied to the digital token itself, which carries cryptographic ownership information. Verification performed locally — enables offline P2P transactions without network connectivity. Resembles physical cash in its bearer-instrument logic.

Combines account-based and token-based structures. Users hold account balances and can convert portions into tokenized units — similar to how bank deposits are exchanged for cash today. The ECB's approach: accounts for online, tokens researched for offline transactions.

A predetermined authority — typically the central bank — has exclusive responsibility for rule-setting and ledger updates within a single-writer architecture. Preferred by the Eurosystem: the ECB and national central banks will be responsible for all settlement.

A predefined group of entities shares responsibility for verification and ledger updates. Protocols like Proof of Authority, PBFT, or Raft enable fault-tolerant consensus among known trusted participants. Common in cross-border mCBDC arrangements (mBridge, Project Dunbar).

No central authority — any participant can take part in validation following open consensus rules (PoW, PoS). Consensus achieved through economic incentives rather than predefined roles. Considered unlikely in the highly regulated CBDC environment.

Isolated system that cannot exchange data with other infrastructures or support cross-CBDC transactions. Common in early-stage pilots but not a viable long-term strategy given the growing demand for cross-border payment capabilities.

Independent systems connected via external components like bridges, clearing houses, bilaterally negotiated API gateways, or oracles to translate data formats between systems. Flexible but operationally complex at scale — each link requires custom translation.

Participating entities adopt common standards such as ISO 20022 messaging format or IBC protocols, enabling efficient data exchange without structural changes. The ECB's approach for the Digital Euro — defining data standards within its rulebook.

All participating CBDCs operate under a fully standardized architecture, often through a shared ledger. Referred to as multi-CBDC (mCBDC) arrangements — as explored in Project Dunbar. Maximum integration but requires extraordinary cross-border governance consensus.

Increases system capacity by upgrading hardware or optimizing resource usage on existing infrastructure. In distributed systems, this can involve protocol-level improvements enabling faster block creation or reduced latency. Simpler to implement but subject to physical limits.

Distributes tasks across multiple nodes to reduce load on any single component and increase overall throughput. In blockchain solutions: multi-chain architectures (Polkadot), Layer 2 rollups, payment channel networks, and sidechains — all offloading or parallelizing transaction processing.