Central Bank Digital Currencies

Visual overview

Central Bank Digital Currencies at a glance — Digital Rupee, e-CNY, wholesale vs retail CBDCs.

Digital Rupee, e-CNY, and the Future of Sovereign Money

Central bank digital currency is a digital form of central-bank money whose design and access model are determined by the issuing central bank and applicable law. Unlike unbacked cryptocurrencies, a CBDC is a liability of the central bank rather than a privately issued speculative asset. Many central banks have researched, tested, piloted or implemented retail and wholesale CBDC concepts, but project counts and stages change frequently and should be taken from current central-bank or authoritative sources. The potential impact depends on design choices involving distribution, privacy, bank funding, settlement and cross-border use.

A CBDC is issued as a liability of the central bank and is denominated in the national unit of account. Legal-tender status, access and acceptance rules depend on the jurisdiction and specific instrument, so it is not safe to state that every CBDC must always be accepted for every debt. CBDC does not require blockchain; centralised, distributed and hybrid technical models are possible. Its value is intended to remain at par with the corresponding central-bank currency. Payment systems such as UPI are rails that move commercial-bank money, while a CBDC changes the form of money being transferred.

Comparing CBDC with other forms of money illuminates its unique position in the monetary hierarchy and the roles that different types of money play in the economy. Physical cash issued by central banks is not digital and cannot be programmed for specific uses or tracked electronically, providing privacy but limiting functionality. Bank deposits are digital but issued by commercial banks rather than the central bank, carrying credit risk of the issuing bank, and offer limited programmability through existing banking systems. UPI and similar payment systems move bank deposits but do not introduce new forms of money themselves—they are payment rails, not currencies, that transfer claims on banks. Stablecoins issued by private companies are digital and programmable but lack sovereign backing and legal tender status, creating credit risk for users who must trust the issuer's reserves. Cryptocurrencies are decentralized digital assets with no central issuer and volatile values unsuitable for stable unit of account or contract denomination. CBDCs combine the sovereign backing and stability of physical cash with the digital functionality and potential programmability of modern payment systems.

CBDCs come in two primary varieties serving different purposes and user bases with distinct design requirements. Wholesale CBDCs are accessible only to banks and financial institutions for interbank settlement and securities settlement applications that require high performance and institutional controls. They enable faster, cheaper settlement between banks while remaining inaccessible to the general public, focusing on improving financial market infrastructure rather than retail payments. Canada's Project Jasper and Switzerland's Project Helvetia represent leading wholesale CBDC initiatives that have demonstrated the technical feasibility and efficiency gains of digital settlement between financial institutions. Retail CBDCs, by contrast, are available to the general public and businesses for everyday payments, functioning essentially as digital cash that complements or potentially replaces physical currency in circulation. They promote financial inclusion by providing central bank money access to those without bank accounts and reduce the costs of cash management for both central banks and users who currently handle physical notes and coins. China's e-CNY, India's Digital Rupee, and the Bahamas' Sand Dollar are prominent retail CBDC examples currently in operation or advanced pilot phases.

India's Digital Rupee, denoted as e₹, entered pilot phases in late 2022 and represents a significant milestone in the country's digital payment evolution and monetary history. The wholesale pilot launched in November 2022 for interbank transactions, followed by the retail pilot in December 2022 for consumer and merchant use in select cities. The system uses digital currency issued under the Reserve Bank of India's authority, with participating banks distributing e₹ through approved wallets and interfaces. Users obtain e₹ through the participating distribution model and can make payments via supported QR codes or transfers to other wallet users. Offline capability and the set of supported use cases are design and implementation questions whose current status should be taken from RBI material rather than assumed from early pilot descriptions.

The Digital Rupee is commonly described as a two-tier distribution model: the RBI is the issuer of the central-bank-money liability, while participating intermediaries provide customer-facing distribution, wallets and support. A customer converting a commercial-bank deposit into e₹ changes the form of the customer's monetary claim; it should not be taught as the RBI taking over or holding the customer's commercial-bank deposit. The exact wallet, settlement and accounting entries depend on the RBI's current design and participating-bank procedures. This model uses existing distribution capability while avoiding the need for the central bank to operate every retail relationship directly.

UPI and the Digital Rupee should be compared as payment rail and form of money. UPI enables customers of participating institutions to transfer commercial-bank money, while e₹ represents central-bank money under the RBI's CBDC design. Interbank UPI settlement follows NPCI and RBI settlement arrangements and should not be simplified to one end-of-day event. Offline capability and privacy features for e₹ are areas of design and testing whose current status should be taken from RBI material. A CBDC can reduce issuer credit risk relative to a commercial-bank deposit, but customer experience, operational risk, wallet security and legal protections still depend on the implementation.

China's e-CNY is a major retail CBDC initiative and has been tested and expanded across many use cases, but wallet counts, transaction values, participating applications and offline features evolve and should be checked from current People's Bank of China or other authoritative material. Chinese authorities have described a privacy model that seeks limited anonymity for smaller-value use while retaining lawful compliance capability. Other jurisdictions may choose different privacy architectures based on their legal and policy frameworks.

Central banks explore CBDC for different reasons, including preserving access to central-bank money in a digital economy, improving payment resilience or inclusion, supporting innovation in market settlement, and studying cross-border interoperability or competition from private digital money. Possible monetary-policy or programmability features are design choices rather than inherent CBDC functions, and many central banks have been cautious about features that could alter the basic properties of money. Financial-crime traceability and privacy also involve trade-offs that depend on legal architecture. The policy objective should therefore be taken from the issuing central bank rather than assumed from a generic list.

However, CBDC implementation carries significant concerns and risks that central banks must carefully address through design choices and policy frameworks. Bank disintermediation represents perhaps the greatest risk to financial stability—if individuals hold CBDCs instead of bank deposits, banks lose their primary funding source and their role in financial intermediation is diminished, potentially reducing credit availability and economic growth. Privacy concerns are substantial, as government-issued digital currency could enable unprecedented surveillance of financial transactions if not properly designed with privacy protections that limit government access. Cyber risk escalates dramatically when a nation's currency exists primarily in digital form, making the infrastructure a prime target for attacks that could disrupt the economy and destroy confidence. Technology readiness questions include achieving offline capability, ensuring scalability to handle national transaction volumes comparable to existing payment systems, and maintaining resilience against failures or attacks that could paralyze commerce. Adoption challenges arise in markets like India where UPI already works well for most purposes, raising questions about why consumers would switch to CBDC and what unique value it would provide beyond existing options.

The future of CBDCs will be shaped by how successfully these challenges are addressed through both technical design and policy choices that balance competing objectives. India's Digital Rupee pilot continues to expand with additional banks and use cases, with offline functionality representing a crucial milestone for rural adoption and financial inclusion goals. China's e-CNY provides a template for large-scale retail CBDC deployment, though its surveillance implications raise concerns in democratic contexts about government tracking of transactions that may be unacceptable to citizens. Wholesale CBDCs for interbank settlement are likely to see earlier widespread adoption than retail variants due to fewer concerns about privacy and bank disintermediation that complicate retail designs. The coming years will determine whether CBDCs become a fundamental transformation of money or a specialized tool for specific use cases where their unique characteristics provide clear advantages over existing payment systems.

Central Bank Digital Currency — Money Design, Banking Impact, and Operating Reality

CBDC is a form of central bank money, not simply a faster payment app

A central bank digital currency is a digital liability of a central bank made available under a defined design to eligible users or institutions. This places it in the monetary system differently from a commercial bank deposit. A bank deposit is a claim on a commercial bank. A CBDC is a claim on the central bank under the legal and operational structure established by that central bank.

The distinction matters even though both can appear as numbers on a screen. A mobile banking application may move commercial bank deposits instantly through a payment system, while a CBDC application transfers central bank money. The customer experience can be similar, but the balance-sheet and settlement meaning is different.

CBDC should therefore be taught as both money and infrastructure. Product design, wallet architecture, distribution, privacy, financial inclusion, bank funding, settlement finality and monetary policy can all be affected depending on the chosen model.

Retail and wholesale CBDC solve different problems

Retail CBDC is designed for use by individuals and businesses, potentially serving some of the functions of cash in digital form. Wholesale CBDC is designed primarily for financial institutions and market infrastructures, where central bank money can support interbank or securities settlement.

The technology, scale and policy questions differ. Retail systems may need very large transaction volumes, accessible wallets, consumer support, offline use and privacy design. Wholesale systems can operate with known regulated participants and focus more on liquidity, atomic settlement, market integration and operating hours.

A central bank can explore both without assuming one design must evolve into the other. They address different layers of the financial system.

CBDC does not need blockchain to be a CBDC

Some pilots use distributed-ledger technology, while others use more conventional centralised or hybrid architectures. The defining feature is the central bank liability, not the database structure.

Technology should follow the policy objective. A retail system may prioritise throughput, resilience and offline functionality. A wholesale platform may value programmable settlement with tokenised securities. A centralised architecture can still provide digital central bank money, while a DLT architecture can still be centrally governed.

This distinction avoids the common mistake of treating CBDC as a government cryptocurrency. It is sovereign monetary infrastructure whose technology can vary.

The two-tier model preserves a role for commercial banks and payment providers

Many retail CBDC designs use intermediaries for distribution and customer service. The central bank issues the monetary liability while commercial banks or approved payment providers handle wallets, onboarding, transaction services or support under the scheme rules.

This leverages existing customer relationships and operating capability. It can also reduce the need for the central bank to become a direct retail service provider for millions of people.

The exact split matters. Who performs KYC? Who provides the wallet? Who stores transaction history? Who handles a lost device or disputed transfer? Who bears operational loss if the intermediary makes an error? These responsibilities should be explicit in the scheme and participant model.

Token-based and account-based descriptions refer to different verification models

CBDC is sometimes described as token-based or account-based. The distinction is not always absolute, but it helps explain how ownership or authority is established.

An account-based model focuses on verifying the identity or authority of the person accessing an account record. A token-style model can focus more on possession or control of a digital value object or credential, though practical systems still need mechanisms for wallet security, recovery and compliance.

Real implementations can combine elements of both. A wallet may hold token-like units while the intermediary still knows the customer and maintains account-like records for service and compliance.

CBDC and UPI should be compared as money versus payment rail

UPI is a payment system that allows participating institutions to move bank-account money using interoperable interfaces. It does not itself create a new monetary liability. A digital rupee changes the form of money being transferred.

This does not mean one automatically replaces the other. A country can have excellent instant-payment infrastructure and still explore CBDC for cash-like digital properties, offline payments, programmable settlement experiments or future tokenised-finance use cases.

Customer adoption will depend on practical value. If existing bank-payment methods are already fast, inexpensive and convenient, CBDC needs a clear use case rather than relying only on novelty.

Conversion between bank deposits and CBDC affects bank balance sheets

When a customer converts a commercial bank deposit into retail CBDC, the monetary claim changes. Depending on system design, the commercial bank can lose a deposit liability while central bank money moves into the CBDC structure.

At small scale this may have little effect. At large scale it can influence bank funding and liquidity. If customers move substantial balances into CBDC, banks may need alternative funding or may adjust deposit pricing.

Central banks therefore consider holding limits, remuneration, tiering or other design features when assessing retail CBDC. The objective can include preserving monetary and financial stability while still providing useful digital central bank money.

Disintermediation risk becomes sharper during stress

In ordinary conditions, customers may keep money in commercial bank deposits because those accounts provide payments, interest and other services. During concern about a bank's solvency, a widely accessible CBDC could offer a rapid route to move funds into a central bank liability.

Digital channels already make bank transfers fast, so CBDC is not the only source of run risk. But the existence of a directly accessible central-bank-money alternative can change behaviour at the margin.

Risk analysis should therefore consider normal and stressed conditions separately. Limits or design features that seem unnecessary during calm periods may have a stability purpose during crisis.

CBDC remuneration changes the economic meaning

A non-interest-bearing CBDC can behave more like digital cash. An interest-bearing CBDC would become a closer substitute for bank deposits and could potentially become an additional monetary-policy transmission channel.

Remuneration can also be tiered, with different treatment above certain holdings. These are policy decisions rather than inherent features of CBDC.

Banks should not assume every CBDC will pay zero interest forever or that interest-bearing CBDC is inevitable. The central bank's mandate, financial structure and policy objectives determine the design.

Privacy design exists on a spectrum

Physical cash can provide strong practical privacy for many face-to-face transactions. Digital systems create records somewhere in the processing chain. CBDC design therefore needs to decide which parties can see which information and under what legal authority.

Privacy does not have to mean complete anonymity or complete surveillance. Small-value transactions can be designed with stronger privacy characteristics while higher-risk activities may require greater identification or reporting. Data can be partitioned among intermediaries so the central bank does not necessarily hold every customer detail.

The exact approach depends on law and policy. The important banking lesson is that privacy must be engineered into the architecture and governance rather than promised as a marketing adjective.

Offline CBDC is a separate engineering problem

Offline payments aim to allow value transfer when one or both devices cannot reach the central ledger in real time. This can improve resilience and access in areas with unreliable connectivity.

The challenge is preventing double spending. If a device can spend the same offline value twice before reconnecting, the system can create loss. Designs may use secure hardware, limited offline balances, transaction counters, expiry or later reconciliation.

Offline risk should be bounded. The system may allow only small amounts or a limited number of offline transfers before requiring synchronisation. Lost-device and fraud treatment should also be defined.

Accessibility determines whether CBDC supports inclusion

A retail CBDC can support inclusion only if people can actually use it. Smartphone-only design may exclude customers without compatible devices, stable connectivity or digital confidence.

Alternative interfaces, simple user experience, assisted channels and offline functionality can expand access. Accessibility also includes people with visual, motor or cognitive impairments.

Financial inclusion should be measured by sustained useful access rather than the number of wallets created. A dormant wallet does not prove that the customer gained meaningful financial capability.

Wallet recovery must balance cash-like properties with customer protection

Physical cash lost from a wallet may be unrecoverable. Digital users often expect account-style recovery after losing a phone or forgetting credentials. CBDC design must decide which expectation applies.

A fully recoverable wallet generally requires some identity or backup relationship. A highly anonymous bearer-style model can make recovery difficult. Intermediated models can offer customer support while preserving stronger privacy for transaction data.

The recovery process should resist social engineering. If a criminal can reset a CBDC wallet using weak information, the system has traded one kind of loss risk for another.

Merchant acceptance is more than displaying a QR code

For CBDC to work in everyday commerce, merchants need integration, reconciliation and accounting. A payment acceptance interface should provide a reliable transaction reference, amount, timestamp and status.

Merchants may want automatic conversion into a bank deposit rather than holding CBDC. The system should define settlement or conversion, fees if any, and how refunds work.

Reconciliation between point-of-sale records and wallet receipts remains necessary. A QR payment can be instant and still require the merchant's finance team to match thousands of sales at day end.

Refunds and reversals need explicit scheme rules

A CBDC transfer may be final at the monetary layer, but commercial transactions can still be refunded. The refund is normally a new transfer, not the erasure of the original payment.

This distinction preserves audit history and legal clarity. Fraud, mistaken transfer and merchant dispute processes should identify when a participant can initiate a new compensating transaction and when recovery depends on recipient cooperation or legal process.

Users should not assume central-bank issuance means every mistaken payment can be reversed centrally.

Financial-crime controls follow the access and transaction model

CBDC can change where KYC, sanctions, transaction monitoring and suspicious-activity controls operate. In an intermediated retail design, banks or payment providers may perform many customer-facing controls. Wholesale participants are already regulated institutions with established compliance frameworks.

The system can use transaction data to support monitoring, but data collection should follow legal and privacy requirements. A centralised record of every citizen's purchase is not an automatic requirement of CBDC.

Cross-border CBDC would add country-specific sanctions, capital-control and transfer-data requirements, making interoperability a policy issue as well as a technical one.

Programmability can refer to money or to payments

The phrase programmable money is often used loosely. A central bank may not want the monetary unit itself to contain restrictive conditions that change its general acceptability. Instead, payment logic can be programmed around the transfer through smart contracts or conditional payment services.

For example, a subsidy programme can trigger payment when an eligibility condition is met without making every unit of currency permanently restricted. Wholesale systems can synchronise cash and securities settlement without changing the value of the currency.

Separating programmable payment from programmable money helps analyse policy implications more precisely.

Expiring money is a policy choice, not an inherent CBDC feature

A digital currency can technically support conditions that physical cash cannot, but that does not mean central banks will use them. Proposals such as expiration, geographic restrictions or purpose limits raise legal, monetary and public-trust questions.

Banking education should distinguish technical possibility from adopted policy. A pilot demonstrating a programmable voucher is not evidence that ordinary CBDC balances will expire.

Wholesale CBDC can support delivery-versus-payment

In securities settlement, the asset and cash legs should complete together to reduce principal risk. If tokenised securities are transferred on a DLT platform, wholesale central bank money can provide a high-quality settlement asset in compatible designs.

The practical challenge is interoperability. The cash and asset may live on different platforms, and settlement logic must ensure one leg does not complete without the other. Central banks and market infrastructures have explored different synchronisation and common-ledger approaches.

Shorter settlement can reduce counterparty exposure but may change intraday liquidity needs. Treasury impacts should be assessed alongside technology benefits.

Wholesale CBDC is not the only form of tokenised settlement money

Commercial bank money, tokenised deposits and regulated private settlement assets can also support digital-asset markets. The appropriate instrument depends on participants, systemic importance, access to central bank accounts and legal framework.

CBDC can provide direct central-bank credit quality, but universal direct access may not be necessary for every market use case. A layered monetary system can continue in tokenised form.

Cross-border CBDC raises currency and sovereignty questions

Connecting CBDCs across countries could reduce some correspondent and settlement friction, but cross-border use is not only a messaging problem. Foreign-exchange conversion, capital controls, sanctions, local access rules, liquidity and monetary sovereignty all matter.

One model may connect domestic CBDC systems through interoperability. Another may use a common multi-currency platform. Either way, central banks need agreement on participant access, legal finality, data and foreign-currency holdings.

A technically instant transfer can still be economically unattractive if FX liquidity is poor or compliance processing remains manual.

Foreign CBDC access can affect domestic monetary systems

If residents can easily hold a stable foreign CBDC, demand for domestic currency or bank deposits can change, particularly in countries with volatile currencies. Central banks may therefore restrict non-resident access or foreign holdings.

This demonstrates that CBDC design is not simply a payment-technology decision. It can influence capital flows, currency substitution and policy transmission.

Cybersecurity becomes part of the monetary trust model

A national CBDC platform would be critical infrastructure. Attackers could target wallets, intermediaries, APIs, cryptographic keys, denial-of-service vulnerabilities or supply chains.

Security should therefore use layered controls, strong identity for privileged access, protected key management, monitoring, resilient architecture and recovery. A central bank may operate the core while intermediaries remain responsible for customer applications, creating a shared-security model.

A wallet compromise affecting one customer is different from compromise of issuance authority. Architecture should isolate these failure domains.

Cryptographic agility matters for long-lived monetary infrastructure

CBDC systems may remain in operation for decades. Cryptographic standards can evolve, and future migration to new algorithms may be necessary.

Systems should know where cryptography is used and support controlled key and algorithm changes. Hard-coding one scheme permanently into every wallet can make future security upgrades difficult.

Operational resilience should include degraded modes

A retail CBDC does not need every feature available during every outage. The system may prioritise transfer and balance functions while analytics or optional services are disabled.

Recovery should define authoritative transaction state. If an intermediary loses connectivity after sending a transfer, it needs a status mechanism before retrying. Offline payments add another reconciliation layer when devices reconnect.

Central bank, intermediaries and technology providers should practise incident roles so responsibility is clear before a national-scale event.

CBDC does not eliminate commercial banks

A two-tier system can preserve banks as distributors, credit providers and deposit institutions even when customers have access to CBDC. Banks still perform lending, maturity transformation, risk assessment, financial advice, transaction services and customer support.

The competitive effect depends on CBDC design. Holding limits and non-remuneration can make retail CBDC less attractive as a savings asset, while strong interoperability can let banks integrate CBDC into existing channels.

The more useful question is how CBDC changes bank funding and payment roles, not whether it automatically removes banks.

Commercial banks need CBDC accounting and reconciliation

A participating bank may exchange reserve balances or other central bank positions for CBDC inventory or facilitate customer conversion according to the scheme design. Finance and operations need to understand the resulting balance-sheet entries.

Customer wallet activity, CBDC platform records and bank accounts should reconcile. If customers convert deposits into CBDC, the bank must avoid showing both balances simultaneously as spendable money.

Reconciliation is particularly important during outages, reversals and offline transactions.

Treasury teams need to model CBDC-driven liquidity flows

Customer conversion into CBDC can create intraday or structural funding movement. Banks should observe patterns by time, customer segment and stress scenario.

If CBDC becomes popular for merchant settlement, daily liquidity flows may differ from existing instant-payment rails. Treasury may need new forecasts and buffers.

Pilot volumes are not sufficient evidence of future steady-state behaviour. Stress testing should consider adoption scenarios rather than extrapolate directly from early users.

A practical retail scenario: deposit converted to CBDC

A customer chooses to move part of a bank deposit into a digital-rupee wallet. The bank authenticates the customer and submits the conversion under the CBDC scheme. The customer's deposit balance decreases, and equivalent CBDC value becomes available in the wallet.

The bank should record a unique reference linking the account debit and CBDC issuance or distribution event. If the wallet update fails after the account debit, operations need an exception process that proves whether CBDC was created before reversing or retrying.

Later, the customer transfers CBDC to a merchant. The merchant's wallet receives the value according to the CBDC system, while the original bank no longer needs to move a deposit through an interbank payment for that transaction.

A practical wholesale scenario: tokenised security settlement

Two financial institutions agree to settle a tokenised bond trade. The buyer needs wholesale central bank money; the seller needs to deliver the bond token. The platform locks or prepares both assets and executes the transfers under a delivery-versus-payment mechanism.

Once settlement is legally final, both institutions update custody, cash and accounting records. If the platform fails before finality, the trade state should show whether neither leg moved, both moved, or a controlled recovery is needed.

The value comes from synchronising asset and cash, not merely from labelling the cash token a CBDC.

CBDC metrics should focus on use, reliability and policy outcomes

Wallet counts and transaction values can show adoption, but they do not reveal whether CBDC solves a policy problem. Better questions include whether users can pay reliably, whether offline use works safely, whether merchant reconciliation is practical, whether inclusion improves, and whether banking-system funding remains stable.

Central banks may deliberately treat pilots as learning exercises rather than growth competitions. Low early volume does not necessarily mean failure if the objective is to test architecture, privacy or interoperability.

CBDC policy will differ by country

Countries have different cash usage, banking penetration, instant-payment systems, legal frameworks and policy goals. A design that makes sense in one country may add little value in another.

For that reason, counts of countries “exploring CBDC” should be interpreted cautiously. Research, proof of concept, pilot and live issuance are very different stages. Projects can pause, change direction or focus only on wholesale use.

Current status should be taken from central banks or authoritative trackers when needed rather than embedded permanently in foundational teaching.

The mature view is monetary architecture, not digital novelty

CBDC matters because it asks how central bank money should function in an increasingly digital economy. It can affect retail payments, market settlement, privacy, inclusion, bank funding, monetary policy and cross-border infrastructure depending on design.

The strongest analysis therefore begins with the monetary claim and policy objective, then examines technology. A CBDC succeeds not because it uses blockchain or has millions of wallets, but because it provides a trusted form of central bank money that solves a real economic or operational need without creating unacceptable stability, privacy or resilience risk.

CBDC Deepening — Banking Operations, Risk, Treasury, and Settlement Design

CBDC design should begin with the monetary claim

A central bank digital currency is important because of who owes the money, not because of the screen or database used to display it. A commercial-bank deposit is a liability of the bank. A CBDC is a liability of the central bank under the design adopted for that currency. This distinction affects credit risk, settlement, accounting, liquidity and customer expectations. Two applications can look almost identical while the money represented inside them is legally and economically different. Banks evaluating CBDC therefore need to map the monetary claim through every customer and operational flow before debating wallets, QR codes or distributed-ledger technology.

Retail and wholesale CBDC require different operating models

Retail CBDC is intended for use by individuals and businesses, which means onboarding, wallets, accessibility, merchant acceptance, customer support, fraud and privacy can become major design areas. Wholesale CBDC is generally focused on financial institutions and market infrastructures, where the key issues can be settlement finality, liquidity, tokenised assets, access eligibility and integration with treasury systems. The two models may share technology, but they should not be treated as one product with different transaction limits. A retail platform may need millions of user credentials and low-value exception handling, while a wholesale platform may have fewer participants but much larger transaction and systemic consequences.

A two-tier model preserves regulated intermediaries

Many CBDC designs envisage a central bank issuing the monetary liability while commercial banks or approved intermediaries provide customer-facing services. This can preserve existing roles in KYC, wallets, servicing, fraud management and distribution. The split must be explicit. The scheme should define who opens the wallet, who authenticates the customer, who stores transaction history, who resolves complaints and who bears loss after an operational error. Ambiguity creates risk because the customer may assume the central bank is responsible for every service issue while the central bank may expect the intermediary to manage the relationship. Clear participant responsibilities are as important as technical connectivity.

Converting deposits into CBDC changes bank balance sheets

When a customer exchanges a commercial-bank deposit for CBDC, the customer is moving from a claim on the bank to a claim on the central bank. The precise accounting depends on the scheme, but the commercial bank can experience a reduction in deposit funding. At small scale the effect may be modest. At large scale, sustained migration could influence bank liquidity, funding costs and deposit pricing. Treasury teams therefore need adoption scenarios rather than treating CBDC as only a payment-channel project. The relevant question is not simply how many transactions occur, but how much value customers hold outside commercial-bank deposits and how quickly those balances can move during normal and stressed conditions.

Holding limits can be a financial-stability tool

Retail CBDC designs may use holding limits, tiered remuneration or other measures to reduce large-scale migration from bank deposits. These controls should be understood as monetary and financial-stability design choices, not merely wallet configuration. A holding limit can also create operational scenarios: what happens when an incoming payment would exceed the limit, whether excess value is automatically moved to a bank account, and how the customer is informed. The bank and wallet platform need deterministic rules so funds are not trapped or silently rejected. Limits should also be reflected in testing, customer support and reconciliation.

Remuneration changes how CBDC competes with deposits

A non-interest-bearing CBDC can behave more like digital cash, while an interest-bearing design can become a closer substitute for bank deposits. Tiered remuneration can change incentives at different balance levels. Banks should therefore consider not only the existence of CBDC but its economic design. If customers receive materially different returns on central-bank money, deposit behaviour can change. Product and treasury teams need to understand whether CBDC is intended primarily for payments, savings or broader monetary-policy transmission. The design can influence the scale and persistence of funding outflows from banks.

Wallet architecture determines recovery and customer responsibility

A retail CBDC wallet may be account-like, token-like or combine features of both. The operating model should define what a customer must protect, how a lost device is handled and whether value can be recovered. A highly cash-like design may prioritise bearer-style control, while a service-oriented design may offer stronger recovery through identity and intermediary records. Neither is automatically superior. The trade-off is between privacy, recoverability, fraud resistance and operational support. Banks distributing CBDC need clear procedures for device replacement, credential reset, suspected compromise and deceased-customer handling.

Offline CBDC creates a distinct risk boundary

Offline payments are valuable where connectivity is unreliable or resilience is a policy objective, but they introduce the problem of preventing the same value from being spent more than once before systems reconnect. Designs can use secure hardware, transaction counters, limited balances or other controls to bound the risk. Banks should treat offline capability as its own product mode with limits and reconciliation. When devices reconnect, the platform must determine authoritative state and identify invalid or conflicting transactions. Customer support also needs to explain whether offline payments are final immediately or subject to later synchronisation rules.

Merchant acceptance needs settlement and reconciliation, not only a QR code

A merchant can accept a CBDC payment through a simple interface, but finance operations still need transaction references, timestamps, amounts, status and settlement records. Some merchants may wish to retain CBDC, while others may prefer automatic conversion into a bank deposit. Refunds, partial refunds and failed transactions need defined rules. The point-of-sale system must reconcile to wallet or account records at day end. If customer payment succeeds but the merchant's accounting system does not receive confirmation, operations need a reliable way to establish whether value moved before retrying or refunding.

Refunds should normally be treated as new value movements

Even when a CBDC transfer is final at the monetary layer, a commercial purchase can still be cancelled or refunded. The clean operational approach is often to preserve the original payment record and create a linked compensating transfer for the refund. This keeps the audit trail intact and allows both merchant and customer to understand what happened. Scheme rules should define who can initiate a refund, whether recipient consent is required for mistaken payments, and how disputes differ from technical reversals. Central-bank issuance should not be described as a guarantee that every customer mistake can be centrally undone.

Fraud controls move with the wallet and distribution model

CBDC does not eliminate familiar fraud types. Criminals can still use social engineering, stolen devices, false identities, mule accounts or merchant deception. The location of fraud controls depends on the architecture. An intermediary may authenticate the customer and monitor wallet activity, while the core CBDC platform enforces scheme-level limits or network rules. Fraud teams need access to relevant identity, device and transaction context without collecting more personal data than necessary. A transfer that is technically valid can still be fraudulent if the customer was deceived into authorising it.

Financial-crime controls need clear participant ownership

Banks and other intermediaries may retain responsibility for customer due diligence, sanctions controls, monitoring and suspicious-activity processes according to the applicable framework. The CBDC platform may provide additional transaction data, but data visibility should not be confused with compliance ownership. Scheme design should identify which participant knows the payer, payee and underlying purpose, and how information can be shared lawfully during investigation. Cross-border use increases complexity because different jurisdictions can apply different screening, capital-control and data requirements.

Privacy should be engineered as layered access

Digital payments create records somewhere in the processing chain. CBDC privacy therefore depends on which entity can see which fields, under what purpose and legal authority. A retail intermediary may need customer identity for onboarding while the central platform may only need pseudonymous transaction information for settlement. Investigators may receive additional data under defined conditions. Small-value transactions can potentially receive stronger privacy treatment than high-risk activity, depending on policy. The important design principle is separation: the system should avoid giving every participant complete visibility simply because the data exists digitally.

CBDC accounting must distinguish customer money from the bank's own assets

A bank distributing CBDC needs a precise accounting model for customer conversions, intermediary positions, fees and settlement with the central bank. Operational wallets, customer entitlements and central-bank settlement records should reconcile. The institution must avoid double counting when a bank deposit is debited and equivalent CBDC becomes available. If one side completes and the other fails, the bank needs an exception process that proves whether CBDC was issued or transferred before reversing the deposit entry. Finance teams should be able to trace the entire conversion without relying on manual interpretation of wallet screenshots.

Reconciliation needs a common reference across deposit and CBDC systems

A customer may move value from a bank account into a CBDC wallet, pay a merchant, receive a refund and later convert remaining value back to a bank deposit. These events can cross several systems. Common references or reliable mapping are essential so operations can connect the commercial-bank ledger, wallet platform, CBDC core and customer statement. Reconciliation should distinguish pending, completed, failed and reversed states. A mismatch should create an actionable exception rather than a generic balance difference. This is especially important during outages or batch recovery when many status updates arrive late.

CBDC can change intraday liquidity patterns

If customers convert deposits into CBDC throughout the day, banks may need to fund those movements using central-bank balances or another settlement arrangement. Merchant conversion back into deposits can create opposite flows. The timing may differ from current payment rails, particularly if CBDC operates continuously. Treasury teams need visibility into conversion volumes, wallet holdings and expected peaks. Liquidity management should consider both normal customer behaviour and stress scenarios where many customers prefer central-bank money. A successful retail pilot with low balances does not by itself reveal the steady-state liquidity effect at scale.

Wholesale CBDC can support delivery-versus-payment

Tokenised securities and other digital assets create demand for a settlement asset that can move in synchronisation with the asset leg. Wholesale CBDC can provide central-bank money within or alongside such platforms. The objective is to reduce principal risk by ensuring cash and asset transfer together. Banks should still analyse liquidity, participant access, legal finality and interoperability. Faster atomic settlement can reduce counterparty exposure but may increase the need for prefunded intraday liquidity if netting opportunities are reduced. Treasury and market-infrastructure teams therefore need to evaluate the full settlement design, not only the technical elegance of a shared ledger.

Interoperability should preserve monetary meaning

A CBDC may need to interact with bank deposits, payment systems, securities platforms or foreign CBDCs. Interoperability is not only a technical bridge. It should preserve identity, transaction purpose, currency, finality and the legal claim represented by the money. When value moves between systems, each participant needs to know whether it is holding central-bank money, commercial-bank money or another instrument. Conversion rates, fees and settlement timing should be explicit. A seamless customer interface should not hide a change in underlying monetary claim that matters for accounting or risk.

Cross-border CBDC is a policy and FX problem as well as a technology problem

Connecting CBDC platforms could reduce some correspondent and settlement friction, but foreign-exchange conversion, liquidity, sanctions, local access rules, capital controls and monetary sovereignty remain. A common technical network cannot resolve these questions automatically. Banks participating in cross-border pilots should map which jurisdiction governs each leg, who performs customer controls, where FX liquidity comes from and when settlement becomes final. The design may still involve commercial intermediaries even if central-bank money is used for settlement. Cross-border CBDC should therefore be evaluated as market infrastructure rather than presented as a simple replacement for every existing correspondent relationship.

Cybersecurity becomes part of monetary trust

A retail CBDC platform would be critical infrastructure. Attackers could target customer wallets, intermediary APIs, privileged administrators, signing keys, software supply chains or availability. Security architecture should separate these failure domains so compromise of one wallet does not threaten issuance authority. Strong identity, protected key management, monitoring and recovery are essential. Banks distributing CBDC also need responsibility boundaries with the central platform. If the bank's mobile application is compromised while the central ledger remains secure, customers still experience financial loss and service disruption. Shared security governance should define incident notification and evidence preservation before such an event occurs.

Cryptographic agility matters because monetary systems are long-lived

CBDC infrastructure may operate for decades, while cryptographic standards and threats evolve. Systems should know where keys, signatures and algorithms are used and support controlled migration. Hard-coding one cryptographic approach into millions of devices can make future security upgrades difficult. The architecture should also define how compromised credentials are revoked and how historic transactions remain verifiable after algorithms change. This is a long-term infrastructure concern rather than a short-term product feature.

Operational resilience should define degraded modes

A CBDC service does not need every nonessential feature to remain available during every incident. The system can define priority functions such as balance access and essential transfers while analytics or optional services are suspended. Intermediaries should know what to do when they lose connection to the core after submitting a transaction. Status inquiry should precede retry so duplicate payments are not created. Offline functionality adds another recovery layer when devices reconnect. Incident exercises should include the central bank, intermediaries and major technology providers because failures can cross organisational boundaries.

Customer support needs a clear ownership model

A customer who cannot access a CBDC wallet should know whom to contact. The support organisation should be able to determine whether the problem lies in identity, device binding, intermediary service, central platform or transaction status. Generic messages such as “CBDC unavailable” are not enough for operational resolution. Support should have references that allow escalation without exposing sensitive data. Complaint ownership also needs clarity when the customer relationship belongs to an intermediary but the underlying monetary platform is operated elsewhere. Simple customer experience depends on explicit internal responsibility.

A practical scenario: deposit conversion followed by merchant payment

A customer converts part of a bank deposit into CBDC and immediately pays a merchant. The bank first authenticates the customer and records the deposit debit. The CBDC distribution process makes equivalent central-bank money available in the wallet. The customer then authorises the merchant transfer, and the merchant receives a transaction reference. If the wallet update fails after the deposit debit, the bank must determine whether CBDC was actually created before reversing or retrying. If the merchant receives CBDC but its point-of-sale system misses the confirmation, it should query status rather than asking the customer to pay again. This single journey shows why CBDC needs disciplined state management across banking, wallet and merchant systems.

CBDC should be judged by the problem it solves safely

A CBDC can support new forms of central-bank money access, offline resilience, tokenised settlement or future payment designs, but adoption alone is not the measure of success. Banks and policymakers should examine whether the design improves a real economic or operational problem without creating unacceptable funding, privacy, fraud, cyber or resilience risk. The strongest architecture keeps the monetary claim, customer responsibility, intermediary role and settlement state clear at every stage. Technology matters, but trusted money depends on governance and operating discipline as much as software.