CBDC and Digital Currency Infrastructure

Key Control Areas

When to Use

Central banks in the design, prototyping, or pilot phase of a retail or wholesale CBDC. Commercial banks designated as CBDC intermediaries by their central bank. Payment infrastructure operators building CBDC wallet or distribution platforms. Technology vendors contracted to build CBDC core ledger, gateway, or offline wallet infrastructure. National payment system operators integrating CBDC with existing RTGS or fast payment infrastructure. Central bank technology consultancies advising on CBDC security architecture. Financial stability regulators assessing systemic risk implications of CBDC design choices.

When NOT to Use

Private sector stablecoins (USDC, EURC) — these are commercial instruments with different threat models; see SP-051 Tokenised Asset Security Architecture. Central bank wholesale settlement using existing RTGS infrastructure without a new CBDC ledger. Payment card security for traditional card-present or card-not-present transactions — see SP-026 PCI Full Environment. Digital identity infrastructure that does not specifically handle monetary value — see SP-052 Decentralised Identity. Cryptocurrency exchange or custody operations — see SP-051 Tokenised Asset Security Architecture.

Typical Challenges

The governance challenge is the hardest: CBDC decisions involve central banks, treasury ministries, data protection authorities, financial regulators, and legislatures — each with different risk tolerances and policy objectives. Security architecture decisions (privacy tier boundaries, holding limits, offline capabilities) require political decisions that no technology team can make unilaterally. The security architect's role is to present the technical implications of each policy choice clearly enough that decision-makers understand what they are approving. Offline CBDC represents an unsolved engineering problem for high-value use cases. Secure element hardware provides strong double-spend prevention but at the cost of complexity, device cost, and failure scenarios (lost device = lost funds). Software-based offline wallets offer usability but require periodic online reconciliation and cannot provide the same cryptographic guarantees as hardware. Privacy-enhancing technologies (blind signatures, ZKPs) are computationally expensive and may not scale to national retail payment volumes without significant infrastructure investment. The tension between AML/CFT compliance (which requires transaction traceability) and privacy (which requires unlinkability) cannot be fully resolved — the legal framework must establish where the line is drawn, and the technology must enforce it without creating technical capabilities that exceed the legal mandate. Interoperability between CBDCs across jurisdictions (mBridge, Nexus, Icebreaker experiments) introduces cross-border trust issues: whose rules govern a payment that originates in one CBDC system and settles in another? Supply chain risk for CBDC hardware (secure elements, HSMs) is acute — state-sponsored supply chain attacks on components that protect national monetary infrastructure are a credible threat. Nation-states with advanced semiconductor capabilities could potentially compromise hardware at the manufacturing level.

Threat Resistance

This pattern provides layered defences across the CBDC threat landscape. Core ledger integrity attacks — manipulation of the authoritative balance records — are mitigated through cryptographic signing of all ledger state (SC-12, SC-13), separation of duties preventing single-operator manipulation (AC-05), and an independent audit log protected even from system administrators (AU-02, AU-09). Counterfeiting — generating fraudulent CBDC not issued by the central bank — is defeated by the central bank's cryptographic issuance key hierarchy (SC-12, SC-13, SC-17), which cannot be forged without the private key, protected by FIPS 140-3 Level 4 HSMs. Double-spend attacks — spending the same CBDC unit more than once — are prevented in online mode by real-time ledger checking and in offline mode by secure element hardware that invalidates tokens on first use (SC-12, PE-03). Privacy attacks — mass surveillance of citizen payment patterns — are bounded by the tiered privacy architecture (PT-01, PT-02, PT-03, AC-04) and enforced by cryptographic privacy-enhancing technologies including blind signatures and zero-knowledge proofs. Bank-run amplification — CBDC acting as a crisis accelerant by enabling instant mass deposit flight — is controlled by holding limits enforced as hard constraints in the core ledger (AC-06) and monitored in real-time against macroprudential thresholds (RA-03, PM-09). Offline hardware attacks — extraction of CBDC tokens from a compromised secure element — are mitigated by TEE architecture, tamper-detection, and per-device key isolation (SC-12, SC-28, PE-03). Insider threats from central bank or intermediary staff — the highest-impact actor class for monetary infrastructure — are addressed through separation of duties (AC-05), multi-person authorisation for privileged operations (IA-02), comprehensive audit logging (AU-02), and insider threat programme governance (PM-12). Infrastructure availability attacks — denial of service against national payment infrastructure — are mitigated through active-active alternate processing sites (CP-07), incident response plans tested for crisis-coincident attack scenarios (IR-08), and continuous monitoring with rapid detection (CA-07).

Assumptions

The organisation is a central bank, central bank technology partner, or licensed CBDC intermediary (commercial bank, payment service provider) building or operating CBDC infrastructure. The CBDC architecture follows the hybrid intermediated (two-tier) model where the central bank operates the core ledger and licensed intermediaries handle distribution and end-user wallets. At least one retail CBDC use case exists (consumer-facing digital currency). The organisation is subject to central banking law, payment systems regulation, AML/CFT legislation, and applicable data protection law (GDPR or equivalent) in the operating jurisdiction. Existing payment infrastructure (RTGS, commercial bank core banking, payment card networks) is already in operation and this pattern addresses the CBDC layer that integrates with or runs alongside existing infrastructure. Physical security of data centres and key ceremony facilities meets national critical infrastructure standards (equivalent to ISO 27001 with national security overlay). A security operations capability capable of monitoring national-scale payment infrastructure exists or is being established.

Developing Areas

• Cross-border CBDC interoperability is the most consequential open design problem in digital currency infrastructure. BIS Project mBridge — connecting the central banks of China (PBC), Hong Kong (HKMA), Thailand (BOT), UAE (CBUAE), and Saudi Arabia (SAMA) — achieved minimum viable product in 2024, demonstrating atomic FX-PvP settlement on a shared ledger that eliminates Herstatt risk (the settlement timing gap that has plagued correspondent banking since the 1974 Herstatt Bank failure). However, at least three competing architectural models are under active development: common platforms (mBridge, Dunbar), interlinking arrangements (BIS Nexus connecting domestic instant payment systems), and bilateral corridors (specific central bank pairs). Each model carries different security, sovereignty, and governance implications — a common platform requires shared key management across jurisdictions with potentially divergent geopolitical interests, while interlinking preserves sovereignty but introduces FX settlement complexity. The geopolitical dimension is unavoidable: mBridge enables cross-border settlement outside USD correspondent banking infrastructure, which has implications for sanctions enforcement and financial statecraft that extend well beyond the technical architecture.
• Programmable money poses risks that are unprecedented in monetary history because no previous form of money has been capable of enforcing spending restrictions at the instrument level. China's digital yuan pilots have demonstrated merchant-category restrictions on government disbursements, and the technical capability exists to implement expiry dates, geographic restrictions, income-based spending limits, and real-time taxation — capabilities that would be impossible to implement with physical cash or conventional bank deposits. The ECB has explicitly prohibited spending restrictions on the digital euro (the 'cash-like' principle), but this is a policy commitment, not a technical constraint — the architecture supports programmability, and future political leadership could reverse the commitment. BIS research draws a critical distinction between programmable money (restrictions embedded in the currency itself) and programmable payments (restrictions applied at the payment rail level, as credit card merchant category codes already do) — the former is architecturally novel and politically dangerous, the latter is an extension of existing practice. Security architects must design programmability layers with constitutional and legislative guardrails that cannot be overridden by executive action alone, including formal governance for programme deployment, independent audit of active programmes, and citizen-accessible transparency mechanisms.
• CBDC-induced financial disintermediation — the risk of digital bank runs — is the primary financial stability concern identified by every central bank exploring retail CBDC. If citizens can instantly convert commercial bank deposits to central bank digital currency with a tap, a loss of confidence in a single bank could trigger deposit flight at a speed impossible with physical cash withdrawal (ATM networks process roughly 100-200 transactions per second per bank; a CBDC conversion API could process thousands). The ECB has proposed a EUR 3,000 holding limit; the Bank of England consulted on GBP 10,000-20,000; the design choice has profound implications for CBDC utility versus financial stability. Tiered remuneration — applying penalty interest rates above the holding limit to discourage hoarding — is the complementary approach favoured by several central bank research papers (BIS WP 976, IMF DP/2020/02). From a security architecture perspective, holding limits must be enforced cryptographically in the core ledger (not just at the intermediary layer, which could be bypassed by using multiple intermediaries), and the system must handle burst load from coordinated mass conversion attempts during a stress event without degrading below the RTO target for normal payment processing.
• Privacy-enhancing technologies for CBDC represent the most technically challenging design space because they must satisfy two mathematically contradictory requirements: regulated anonymity for citizens and lawful access for authorities. The ECB's digital euro design proposes tiered privacy: offline low-value payments with cash-like anonymity (no data shared with the intermediary or the central bank), online payments with pseudonymity (intermediary sees the transaction, central bank sees only aggregates), and high-value payments with full KYC. Project Hamilton (Federal Reserve Bank of Boston / MIT DCI) demonstrated Chaumian blind signatures for transaction privacy — the central bank signs a token without seeing the transaction details, providing cryptographic anonymity — but this approach conflicts with AML/CFT requirements above threshold values. Zero-knowledge proofs offer a middle path: a holder can prove their transaction is below the anonymity threshold, their cumulative daily transactions are below a limit, and their wallet is not on a sanctions list — all without revealing their identity, balance, or transaction history to the central bank. Hardware-based privacy (secure element attestation that spending limits are enforced locally, without reporting balances to any server) is being researched by the ECB and SNB, but requires trust in the tamper-resistance of consumer hardware — a strong assumption given the history of secure element side-channel attacks.
• Offline CBDC resilience is identified by the Bank of England, Riksbank (e-krona), and BIS as a top research priority because it addresses a scenario where digital currency must function precisely when infrastructure has failed — natural disasters, grid attacks, military conflict, or remote areas without connectivity. Tamper-resistant secure elements (NXP SmartMX3, Infineon SLC37, Idemia Secure Enclave) can store CBDC value and execute peer-to-peer transfers without network connectivity, but double-spend prevention without a central ledger requires hardware trust: the secure element must be trusted to decrement the sender's balance and increment the receiver's, with no ability to replay or reverse. BIS WP 1123 identifies the maximum offline accumulation limit as a critical policy-security parameter — too low and the offline CBDC is useless for disaster resilience; too high and the double-spend exposure from a compromised secure element becomes unacceptable. Disaster resilience scenarios require mesh-network payment capability (device-to-device transfer chains where no single device has connectivity), which creates reconciliation complexity when connectivity restores: the central bank must process potentially millions of offline transactions, detect any double-spends, and update the core ledger — a burst processing load that must be architected for but occurs only in exceptional circumstances. The security architecture must also address the physical security of offline-capable hardware: unlike a mobile app that can be remotely wiped, a lost or stolen secure element containing offline CBDC value is equivalent to lost cash.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.