Central bank digital currencies: design choices and economic trade-offs

A CBDC is defined by its issuer and liability

A central bank digital currency is a digital form of central bank money. The defining economic feature is the liability: the holder has a claim on the central bank under the applicable framework. A payment app, a bank deposit and a privately issued stablecoin can all look digital without creating the same claim. This distinction comes before questions about blockchain, wallets or transaction speed. Central banks already provide digital settlement balances to eligible institutions in many monetary systems, so digital central bank money is not itself an entirely new idea. Retail CBDC proposals ask whether broader public access should take a new form. Wholesale proposals focus on institutional settlement arrangements. Evaluating either requires identifying the actual change in access, legal structure or functionality, rather than assuming that a different interface creates a fundamentally different economic asset.

Retail and wholesale designs serve different users

Retail CBDC generally refers to money accessible for everyday use by households and businesses. Wholesale arrangements concern eligible financial institutions and activities such as interbank payments or securities settlement. The problems being solved therefore differ. Retail design must address merchant acceptance, accessibility, consumer support and frequent small payments. Wholesale design must address institutional eligibility, settlement finality, liquidity and integration with financial-market infrastructure. A successful wholesale experiment does not establish that the same architecture would serve millions of retail users well. Nor does a convenient retail wallet demonstrate suitability for complex institutional settlement. Researchers should specify the intended population and transaction type before comparing projects. They should also separate the settlement asset from the transfer mechanism: some proposed improvements in wholesale payments may be achievable through new platforms using existing central bank balances, without requiring a new category of central bank liability.

Distribution determines who performs the customer-facing work

A central bank can issue the monetary liability while private or public intermediaries provide wallets, identity checks and customer support. Other architectures distribute responsibilities differently. The public-versus-private distinction is therefore not a simple choice between the central bank doing everything and commercial institutions disappearing. A workable design must allocate account recovery, fraud handling, onboarding, dispute resolution and service availability. It must also explain how intermediaries are compensated and held accountable. An intermediary failure should not be confused with failure of the underlying central bank liability, yet it can still disrupt access to funds. That makes portability and recovery arrangements important. For analysis, map the service chain from issuance to the user's device and identify the institution responsible at each step. This is more informative than describing an entire system as centralized or decentralized without explaining its operating responsibilities.

Privacy is a set of design and governance choices

CBDC privacy cannot be evaluated through a single promise that transactions are anonymous or visible. Relevant questions include what data are collected, who can connect them to an identity, who can access them, how long they are retained and which legal process governs disclosure. The central bank, wallet provider and other authorized parties may see different information. Privacy-enhancing technology can reduce exposure, but institutional rules and accountability remain necessary. Offline payments may allow different privacy properties from online payments, depending on the design. Published proposals illustrate possible approaches; they do not establish a universal feature shared by every CBDC. A useful assessment distinguishes privacy from commercial data exploitation, confidentiality from other users, and access by authorities under law. Each dimension requires explicit treatment. The strongest privacy claim is one supported by architecture, enforceable limits and independent oversight rather than marketing language alone.

Offline payments trade connectivity dependence for other constraints

Offline functionality can help payments continue when internet access is unavailable, but it is not a simple switch that removes all infrastructure dependence. Devices still need a means to store value securely and prevent the same value being spent twice. Designs may limit transaction amounts, balances or the duration before reconnection. They must address lost devices, damaged hardware and reconciliation after connectivity returns. Some approaches support payment when one participant is offline; others aim to support both participants being disconnected. Those are different technical objectives. Offline capability can improve resilience and inclusion, yet its value depends on real usage conditions and available devices. A field test should examine power, usability and recovery, not merely whether two laboratory devices exchange a payment message. Claims of cash-like operation should specify which cash properties are reproduced and which remain dependent on digital safeguards.

Deposit substitution can change bank funding

If households move balances from bank deposits into CBDC, banks may need to adjust their funding mix or asset holdings. The scale and consequences depend on design, demand and banks' responses. A hypothetical bank with 100 units of deposits that experiences a 10-unit transfer to CBDC faces a change in funding of ten units; this does not mechanically imply that lending must fall by exactly ten units. The bank might use liquid assets, obtain other funding or change deposit pricing, subject to constraints and costs. During stress, the speed of transfers into central bank money could matter differently from normal payment use. Policy analysis should therefore distinguish everyday substitution from concentrated outflows. It should also examine how funding costs, liquidity buffers and credit supply interact. A claim that CBDC either destroys banking or has no banking impact ignores these conditional mechanisms.

Holding limits and remuneration shape incentives

A CBDC design may include holding limits, transaction limits or a remuneration policy to influence how it is used. These are separate choices. A balance cap limits the stock held, while a transaction restriction limits particular flows; neither should be assumed from the other. Paying interest could affect demand relative to deposits and other safe assets, while a non-interest-bearing design might emphasize payment use. Limits can also create operational questions, such as how incoming payments are handled when a wallet is already near its ceiling. Linking a wallet to another account can offer one solution, but that changes dependencies and accessibility. The relevant evaluation is whether the incentive structure matches the stated objective without creating unnecessary friction. No specific threshold is universally optimal: the trade-off depends on local payment habits, banking structure and the policy purpose of the proposed system.

Inclusion and resilience require more than an app

A payment system is not inclusive merely because downloading its software is free. Identity requirements, device ownership, disability access, language, digital literacy and merchant acceptance can all limit practical use. Assisted access and alternative devices may matter as much as the core ledger. Resilience likewise extends beyond the central platform: communications networks, wallet providers, payment terminals and support processes can fail independently. A CBDC should be assessed against existing alternatives, including improvements to conventional payment systems and continued access to cash, rather than against an unrealistically poor baseline. The important question is which unmet need the design addresses and how success would be measured. Examples include reliable access during an outage or easier participation for people without suitable bank services. These are testable objectives; simply counting wallets created does not demonstrate that users can depend on the system when they need it.

Stablecoins, tokenised deposits and programmable payments differ

A stablecoin generally relies on a private arrangement intended to maintain value relative to a reference, while a tokenised deposit remains connected to a commercial bank liability under its legal structure. A CBDC is a central bank liability. Sharing a ledger technology does not erase these distinctions. Programmable payments are another separate concept: a user can authorize a payment when a condition is satisfied without changing the monetary unit's fundamental nature. Whether authorities can impose restrictions, and what safeguards govern that power, depends on law and design rather than on the mere presence of software. Cross-border use introduces further questions about foreign access, currency conversion and interoperability. It should not be assumed to follow automatically from domestic issuance. Clear terminology prevents debates about one instrument's risks from being applied uncritically to another instrument that carries different claims and institutional responsibilities.

Evaluate a proposal through explicit objectives and trade-offs

A disciplined CBDC assessment begins with the problem to be solved, the intended users and the existing alternatives. It then identifies the liability, distribution model, privacy arrangements, offline scope and impact on bank funding. Operational testing should cover exceptional conditions as well as normal transactions, while legal analysis clarifies rights, access and accountability. Research, a prototype, a pilot and an authorized public rollout are different stages and must not be described interchangeably. This guide makes no assumption that any particular proposal has launched or that every jurisdiction will choose the same design. The useful output is a conditional judgment: which benefits are plausible under specified features, what costs accompany them, and what evidence remains missing. That approach supports a serious discussion of public digital money without treating technological novelty as proof of necessity or treating every possible design as an identical policy choice.

Explore the data and markets