How to Design a CBDC Pilot for Financial Inclusion

A Central Bank Digital Currency (CBDC) is a digital form of a country's sovereign currency, issued directly by the central bank. While the concept is straightforward, designing a pilot that genuinely promotes financial inclusion presents a distinct set of technical challenges. It requires moving beyond a simple digital replica of cash to architect a system that is accessible, resilient, and usable for populations currently excluded from the formal banking system. This includes individuals without smartphones, those in areas with poor connectivity, and people with low technical literacy.

The primary technical hurdle is the offline capability or resilience. A truly inclusive CBDC must function during power outages, network failures, or in remote regions. This is not a feature of most blockchain or distributed ledger technology (DLT) systems, which require network consensus. Solutions being explored include hardware-based wallets with secure elements for offline transaction signing, asynchronous transaction protocols that sync when connectivity is restored, and hybrid architectures that balance online verification with offline usability, similar to the approach researched in Project Hamilton by the Boston Fed and MIT.

Another critical design consideration is identity and privacy. A system that requires stringent Know Your Customer (KYC) checks can exclude those without formal identification. However, complete anonymity raises concerns about illicit finance. Technical designs must navigate this spectrum, potentially using tiered accounts (low-value, pseudo-anonymous wallets with higher-value, identified wallets) or privacy-enhancing technologies like zero-knowledge proofs to validate transaction rules without revealing personal data. The European Central Bank's digital euro exploration includes analysis of such privacy-preserving techniques.

Finally, interoperability with existing financial and payment rails is non-negotiable. An inclusive CBDC cannot exist in a silo. It must technically integrate with mobile money platforms (like M-Pesa), point-of-sale systems, and traditional bank accounts. This requires robust Application Programming Interfaces (APIs), standardized protocols for value transfer, and potentially the use of programmable payment conditions to enable social disbursements or conditional transfers directly on the ledger, reducing administrative overhead and leakage.

Before writing a single line of code, define the pilot's primary objective. For financial inclusion, this typically means targeting the unbanked or underbanked population. Key questions include: What specific barriers to access will the CBDC address? Is it offline functionality for areas with poor connectivity, low transaction costs to compete with cash, or simplified identity requirements? The objective dictates the technical architecture. A pilot aiming for offline use will require a fundamentally different design—potentially using secure hardware elements or novel consensus mechanisms—than one focused on seamless integration with existing digital payment rails.

The choice of underlying distributed ledger technology (DLT) is a foundational technical decision. Options range from permissioned blockchains like Hyperledger Fabric or Corda to a more centralized real-time gross settlement (RTGS) system with a DLT layer. For inclusion, consider scalability for high transaction volumes at low cost, the ability to function in intermittent connectivity (if offline is a goal), and interoperability with existing mobile money platforms like M-Pesa. The ledger must support the required transaction privacy model, whether through zero-knowledge proofs, confidential transactions, or designating the central bank as the sole transaction data processor.

Design the user access layer for your target demographic. This often means a mobile-first, low-data-usage application. The wallet must be intuitive for users with low digital literacy, potentially using USSD menus or simplified graphical interfaces. Critical features include the ability to convert cash to CBDC easily via authorized agents (like local shopkeepers), and clear transaction limits for different user verification tiers (e.g., tiered KYC). The pilot must also define the role of intermediaries: will banks and non-bank financial institutions act as wallet providers, or will the central bank interface directly with users?

Establish clear legal and regulatory sandbox parameters. A pilot operates in a temporary, controlled environment with relaxed certain regulations. You must define the legal status of the pilot CBDC, liability frameworks for lost funds or technical failure, and compliance with anti-money laundering (AML) rules. This often requires new legislation or executive orders. Engage regulators early to co-create the sandbox rules, ensuring they allow for testing inclusion features—like higher thresholds for anonymous transactions—while maintaining oversight.

Finally, define Key Performance Indicators (KPIs) that measure inclusion, not just technical throughput. Technical KPIs like transactions per second (TPS) and settlement finality are important. However, for an inclusion pilot, track metrics such as: cost per transaction for the end-user compared to alternatives, the percentage of transactions occurring offline, adoption rates within the target demographic, and user satisfaction scores on accessibility. These metrics will determine the pilot's success and inform the decision to proceed to a full-scale launch.

Financial inclusion requires a payment system that functions in areas with intermittent connectivity or no connectivity at all. A successful CBDC pilot must support offline transactions between two devices, such as smartphones or specialized hardware wallets, without requiring real-time validation from a central ledger. This is fundamentally different from online systems and introduces unique challenges around double-spending prevention, transaction synchronization, and security. The core design must assume that a user's device holds a local balance that can be spent peer-to-peer, with settlement finalized later when connectivity is restored.

The most common architectural pattern for offline CBDC is the deferred net settlement model. In this system, each device stores a secure, tamper-resistant balance. When User A pays User B offline, the transaction is cryptographically signed and stored locally on both devices. The actual transfer of value is not reflected on the central ledger until one of the devices later goes online and synchronizes the pending transactions. To prevent double-spending, protocols often implement value limits on offline wallets, time-bound validity periods for transactions, or hardware-based security modules (HSMs) that physically prevent balance manipulation. The eNaira, for example, uses a tiered wallet system with strict offline transaction limits.

From a technical implementation perspective, developers must choose a synchronization protocol. One approach uses a store-and-forward mechanism, where transactions are passed through a mesh network of devices until they reach an online node. Another employs asymmetric cryptography: the payer signs a transaction with their private key, and the payee receives a verifiable proof of payment that they can later submit. Smart contracts on a blockchain ledger can be designed to process batched offline transactions, resolving conflicts based on cryptographic proof and timestamps. Code for a basic offline transaction might involve generating a signed message object containing the amount, recipient address, and a unique nonce.

Security is paramount. An offline system must guard against replay attacks, where a valid transaction is submitted multiple times, and balance forgery. Solutions include using monotonic counters in secure hardware to sequence transactions, or implementing a challenge-response protocol during the sync phase where the central ledger verifies the cryptographic chain of custody for each unit of value. The Bank for International Settlements (BIS) Project Tourbillon explores advanced cryptography like blind signatures to enhance privacy in offline CBDC scenarios, ensuring that even the central bank cannot link transactions during the offline phase.

Designing the user experience (UX) for intermittent connectivity is equally critical. The interface must clearly communicate the device's connection state (online, offline, syncing) and the available balance for offline spending. Users need intuitive ways to manually trigger synchronization and receive clear confirmations when offline transactions are finally settled. Pilots should be tested in real-world environments with poor network coverage to iterate on these designs. The ultimate goal is a system that feels seamless and reliable, building the trust necessary for widespread adoption among unbanked and underbanked populations.

Financial inclusion requires a CBDC system accessible to users with feature phones (non-smartphones) and limited internet connectivity. A pilot must prioritize offline functionality and USSD/SMS-based interfaces alongside smartphone apps. The core design principle is progressive enhancement: a basic, universally accessible layer (like a USSD menu) provides essential transaction functions, while smartphone users gain access to advanced features like QR codes and detailed transaction history. This ensures no citizen is excluded based on device capability.

Technical architecture must be lightweight and modular. For the ledger, consider a permissioned blockchain like Hyperledger Fabric or Corda, which can be optimized for lower transaction throughput and storage requirements compared to public chains. Node software should run efficiently on modest hardware. Transaction logic should be designed for asynchronous finality, allowing operations to complete even with intermittent connectivity. Critical user data, like balance and transaction limits, can be cached locally in an encrypted form on the user's SIM card or device.

The user interface for low-cost devices relies on established telecom protocols. USSD (Unstructured Supplementary Service Data) sessions allow menu-driven interactions without a data plan. SMS can deliver transaction confirmations and one-time passwords (OTPs). For example, a user could send *144*1*<recipient>*<amount># to initiate a transfer, receiving a confirmation SMS with a token to finalize it. This model, used successfully in systems like M-Pesa, requires tight integration with mobile network operators (MNOs) but delivers maximum reach.

Security for offline and low-bandwidth transactions presents unique challenges. Implement double-spend protection through hardware-secure elements in SIM cards (SIM-based wallets) or time-bound offline transaction limits that must sync with the network periodically. Use lightweight cryptography like Ed25519 for signatures to reduce computational overhead. The system should employ a tiered authentication model, where low-value transfers use a PIN, but higher values require biometric verification or a second factor when online.

Testing and deployment must reflect real-world conditions. Pilot in regions with documented low smartphone penetration and poor network coverage. Use device simulators for thousands of feature phone models to ensure UI compatibility. Performance benchmarks should include metrics like transaction success rate over 2G networks and time-to-first-byte for USSD responses. Partner with local fintechs and MNOs who understand the on-ground infrastructure constraints and user behavior.

A successful pilot provides a blueprint for scale. Document the cost per transaction across different device types and network conditions. Analyze the data to decide on the long-term mix of USSD, app, and card-based access points. The goal is a CBDC system that is not just technologically sophisticated, but practically ubiquitous, turning every mobile phone—regardless of its age—into a gateway for secure digital currency.

The primary goal of a financial inclusion-focused CBDC pilot is to move beyond technical validation and measure real-world socioeconomic impact. This requires defining metrics across three core dimensions: adoption, usability, and impact. Adoption metrics track user growth and transaction volume among the target unbanked or underbanked population. Usability metrics, gathered through surveys and session analytics, assess the user experience (UX)—factors like transaction success rate, time-to-completion, and perceived ease of use. Impact metrics are the most critical, measuring changes in users' financial health, such as increased savings, reduced transaction costs, or improved access to credit.

To collect this data, you must establish structured feedback loops. These are systematic processes for gathering, analyzing, and acting on user input and system data. A robust loop integrates quantitative data from the CBDC ledger and wallet applications with qualitative data from user interviews, focus groups, and support tickets. For example, if usability metrics show a high drop-off rate during the onboarding KYC process, qualitative feedback can reveal whether the cause is documentation requirements, language barriers, or digital literacy issues. This combination allows for root-cause analysis.

Implementing these loops requires instrumenting the pilot platform. Developer teams should embed analytics to log key events: wallet creation, transaction initiation, success/failure states, and feature usage. Simultaneously, design researchers should conduct periodic sprint reviews with pilot participants. The feedback loop is closed when insights from these reviews directly inform the next iteration of the wallet's design, educational materials, or agent training protocols. This agile approach is exemplified by projects like the Digital Rupee pilot in India, which iterated on offline functionality based on rural user testing.

Key technical metrics for developers to implement include transaction finality time, offline transaction success rate, and API latency for ancillary services. For financial inclusion, business metrics must track the reduction in average remittance cost and the percentage of users conducting their first digital savings transaction. Setting specific, measurable targets for each KPI—such as "achieve a 95% successful onboarding rate for users with basic feature phones"—is essential. These targets form the basis for the pilot's go/no-go decisions for broader rollout.

Ultimately, the defined metrics and feedback loops must answer critical policy questions: Does the CBDC meaningfully lower barriers to entry? Does it empower users economically? Without this rigorous measurement framework, a pilot risks being merely a technology demonstration rather than a tool for inclusive financial system transformation. The data collected guides not only technical refinements but also future policy on interoperability, programmability, and the role of private-sector intermediaries in the CBDC ecosystem.

A successful pilot requires moving from design to deployment. Begin by finalizing your Minimum Viable Product (MVP) scope. This should focus on the core use cases identified in your research, such as offline-enabled government-to-person (G2P) transfers or low-fee micro-payments. Select a single, well-defined geographic region or demographic group for the initial test. Assemble a cross-functional team with expertise in blockchain development, central bank operations, financial regulation, and user experience design. Establish clear Key Performance Indicators (KPIs) upfront, measuring not just transaction volume but also user adoption rates, cost savings for end-users, and system resilience.

For technical implementation, choose a development path. You could fork and customize an existing open-source CBDC platform like the BIS Project Tourbillon privacy framework or the Digital Currency Monetary Authority's (DCMA) Universal Monetary Unit specification. Alternatively, build on a permissioned blockchain such as Hyperledger Fabric or Corda, which offer granular privacy controls essential for a central bank ledger. The core system must integrate with existing national payment rails (like RTGS) through secure APIs. Rigorous testing in a sandbox environment is non-negotiable; this includes load testing, security audits by firms like Trail of Bits or OpenZeppelin, and penetration testing to identify vulnerabilities before launch.

The pilot's execution must be accompanied by continuous monitoring and a structured learning agenda. Use the data collected to answer critical questions: Does the offline transaction protocol function reliably in areas with poor connectivity? Are the privacy safeguards sufficient and understandable to users? How does the CBDC impact local liquidity and the role of existing financial intermediaries? Publish transparent progress reports and a final evaluation. This documentation is vital for building public trust and informing policymakers. The next steps involve analyzing the pilot data to decide on scaling, iterating on the design, or halting the project, ensuring every phase contributes to the overarching goal of creating a more inclusive financial system.