How Central Banks Are Designing CBDC Infrastructure

The first architectural decision for any CBDC is whether it is direct (the central bank holds every citizen's account directly) or indirect/two-tier (the central bank issues to commercial banks, who hold retail accounts).

Direct CBDC is simpler technically but politically and operationally problematic. Central banks are not equipped to manage hundreds of millions of retail accounts, handle customer service, or make credit decisions. Most CBDC pilots have moved away from this model.

Two-tier CBDC maintains the existing banking system. The central bank issues digital currency to commercial banks, who distribute to retail customers. The customer's wallet is with their bank, but the underlying asset is a central bank liability rather than a commercial bank deposit.

A middle model — often called "synthetic CBDC" or "platform model" — has the central bank provide the infrastructure and settlement layer while private entities handle the customer relationship. This is closer to what China's e-CNY and several European pilots are exploring.

CBDC privacy is the most politically sensitive technical decision. A fully transparent CBDC gives the central bank (and potentially other government agencies) complete visibility into every transaction of every citizen. This is unacceptable to most populations in democratic countries.

The technical solutions range widely. Cash-like anonymity (small transactions unlinkable, no transaction data retained) at one end. Full transparency for law enforcement at the other. Most realistic designs are somewhere in the middle: transactions are pseudonymous rather than anonymous, with law enforcement access available via judicial process.

Zero-knowledge proofs offer a technically elegant solution: users can prove they have sufficient balance without revealing it, and transactions can be verified as valid without exposing the parties or amounts. The e-CNY pilot has explored ZK-proof based anonymity for small transactions. The challenge is computational overhead and auditability — regulators need to be able to audit for AML purposes without accessing individual transaction data.

The design choice here is fundamentally political, not technical. Engineers can implement any privacy model — the question is which trade-off governments and citizens will accept.

One of CBDC's potential advantages over physical cash is programmability — the ability to attach conditions to money. Government payments that can only be spent on specific categories. Subsidies that expire if unused. Automated tax withholding at the point of transaction.

The use cases are compelling but the precedent is concerning. Programmable money represents an unprecedented level of government control over individual economic activity. The design question is not whether programmability is technically possible — it obviously is — but which entities get to define the conditions, and what constraints prevent abuse.

Most central bank CBDC designs limit programmability to specific use cases (targeted stimulus, government benefit programs) while keeping general-purpose retail CBDC non-programmable. This is a reasonable middle ground for initial deployments.

The technical infrastructure is essentially the same as any smart contract platform: the CBDC base layer handles settlement and custody, with a programmability layer on top. The difference is that the central bank controls the programmability layer entirely.

A world with 50+ national CBDCs and no interoperability standard creates fragmented digital currency islands. Cross-border payments — already slow and expensive — become a patchwork of bilateral agreements between incompatible systems.

The BIS has been working on several CBDC interoperability projects: Project mBridge (multi-CBDC platform involving Hong Kong, Thailand, UAE, China, and the BIS), Project Icebreaker (Nordic countries), and Project Nexus (ASEAN).

The technical approaches vary. Atomic swap models exchange CBDCs between systems without a central intermediary. Hub-and-spoke models route cross-border payments through a shared settlement platform. Relay chain models (similar to the Polkadot model for public blockchains) create a common communication layer.

The governance challenge is larger than the technical one. Getting sovereign nations to agree on a shared settlement infrastructure involves political considerations that dwarf the engineering complexity.

Central banks are looking for the same capabilities that enterprise blockchain engineers have been building for years: permissioned access, programmable settlement, privacy-preserving transactions, high throughput at low cost, and integration with existing financial infrastructure.

The technology stacks being evaluated for CBDC — R3 Corda, Hyperledger Fabric, Quorum, and purpose-built systems — are the same ones used for enterprise DeFi and trade finance applications. Engineers with deep experience in these platforms are well-positioned to work on CBDC infrastructure.

The regulatory environment for CBDC development is moving fast. If you are building financial infrastructure for any institution that may be involved in CBDC pilots — central banks, commercial banks, payment networks, or financial market infrastructure — now is the time to develop expertise in the relevant technology stacks.