CBDC Consultancy: Security, Privacy, and Operational Resilience

A practical playbook for decision‑makers to design CBDCs that are quantum‑resilient, privacy‑preserving, and operationally robust—mapped to current regulations, pilots, and production‑grade lessons from 2024–2025. Expect concrete architecture choices, testable controls, and adoption data you can use in board materials today.

TL;DR (description)

Central banks and enterprises are moving from CBDC experiments to regulated pilots; this post distills the latest standards, privacy models, cross‑border findings, and resilience requirements into an implementable blueprint you can adopt with or without a CBDC mandate. (bis.org)

Why security, privacy, and resilience must be designed together

Regulation now enforces resilience across the whole supply chain. In the EU, DORA applies from January 17, 2025 and extends oversight to “critical” ICT providers; regulators are actively designating cloud and market infrastructure vendors for direct supervision. (eiopa.europa.eu)
CBDCs will be treated like FMIs: CPMI‑IOSCO cyber guidance expects a two‑hour recovery time objective (2h RTO) for critical operations—even under extreme but plausible scenarios. That target drives architecture, testing, and fallback design from day one. (bis.org)
Privacy expectations are getting codified. The ECB’s digital euro preparation work specifies cash‑like privacy offline and pseudonymised, encrypted identifiers online; the Bank of England commits that neither the Bank nor Government would access personal data in a digital pound’s core infrastructure. (ecb.europa.eu)
Cryptography is shifting: NIST approved PQC standards in August 2024 (FIPS 203/204/205). Migration planning must start now for long‑lived CBDC ledgers and wallets. (nist.gov)

Security: what “good” looks like in 2025

1) Crypto and key management: build for post‑quantum, keep agility

Mandate crypto‑agility and hybrid key exchange today. Adopt TLS profiles that combine classical (e.g., X25519) and PQC (FIPS 203 Kyber KEM) while inventorying cryptography and setting rotation SLAs. NIST’s SP 800‑131A guidance and draft Rev.3 emphasize transitions to ≥128‑bit security and PQC. (csrc.nist.gov)
HSM baseline: FIPS 140‑3 validation for new modules; plan upgrades before the FIPS 140‑2 sunset (all 140‑2 certs move to the historical list by September 21, 2026). This directly affects CBDC custody nodes, issuance services, and offline hardware. (csrc.nist.gov)
Signature/attestation roadmap: phase in ML‑DSA (FIPS 204) for ledger change control and wallet attestation; use hash‑based signatures (FIPS 205) for long‑term audit anchors and root‑of‑trust. (nist.gov)

Practical control set to include in your RFPs:

PQC‑ready KMS with hybrid KEM/TLS and crypto inventory dashboards (SP 800‑131A mapping). (csrc.nist.gov)
Dual‑admin ceremonies, M of N approvals, and deterministic builds for all release artifacts (see SSDF). (csrc.nist.gov)

2) Wallet security—including offline

China’s e‑CNY app enables NFC “tap‑to‑pay” without power, with user‑set caps and code‑free quotas—an example of dual‑offline UX and risk control. Design your policy engine around amount/attempt limits, rapid revocation, and delayed reconciliation. (nfcw.com)
ECB is evaluating deployment of an offline digital euro on secure elements (eSE, iSE, eSIM) with talks held with device makers in late 2024; integrate those options into procurement to avoid vendor lock‑in. (ecb.europa.eu)
Research direction: protocols that place minimal computation in the secure element (delete‑only tokens plus signatures) reduce attack surface while supporting double‑spend detection on reconnection. (eprint.iacr.org)

Checklist:

Require secure element attestation, tamper‑resistant counters, and offline balance ceilings per persona.
Define a reconciliation SLA and double‑spend evidence pipeline (signed transcripts) for offline events.

3) Ledger, API, and software supply chain hardening

Use an API layer with standardised functions across wallets and services—as demonstrated by BIS/BoE Project Rosalind (33 retail CBDC APIs)—and gate each endpoint with rate‑limits, consent, and PETs hooks. (bis.org)
Adopt ISO 20022 messaging on synchronisation rails to interoperate with RTGS and asset ledgers (Meridian), not just DLT‑to‑DLT. (bis.org)
Enforce SSDF practices and SBOMs. Require suppliers to provide SBOMs in SPDX/CycloneDX and VEX attestations; CISA’s 2025 Minimum Elements draft is the reference for fields and coverage expectations. (csrc.nist.gov)

Privacy by design: implementable patterns from live programs

Digital euro: offline “cash‑like,” online pseudonymous

Offline payments: transaction details known only to payer and payee; online transactions pseudonymised and encrypted so the Eurosystem cannot directly link payments to individuals. AML data access is minimised to intermediaries. Bake these constraints into your data model and audit trails. (ecb.europa.eu)

Digital pound: platform model with PETs and no central access to personal data

BoE and HM Treasury confirm core principles: the Bank and Government would not access users’ personal data; platform model with intermediaries (PIPs/ESIPs) handling KYC and consent; exploration of DIDs/VCs for an alias service to reduce personal data sharing across the ecosystem. (bankofengland.co.uk)

Apply immediately:

Implement an alias service that resolves to rotating, unlinkable identifiers (DID/VC) rather than static IDs, and expose granular consent scopes to PIPs. (bankofengland.co.uk)

PETs and selective disclosure

BIS Project Tourbillon shows a workable design for payer anonymity (cash‑like for the payer, not the payee), limiting data exposure while keeping compliance paths for merchants. Use its pattern for high‑privacy retail scenarios. (bis.org)
BIS Project Aurora demonstrates collaborative analytics using PETs and network analysis to improve AML effectiveness without centralising raw personal data. This is the right model for suspicious‑pattern detection across intermediaries. (bis.org)

Operational resilience that auditors will sign off

Map to PFMI, DORA, and threat‑led testing

Engineer to CPMI‑IOSCO’s two‑hour RTO for critical operations and ability to complete settlement by end‑of‑day. Document your degraded modes and manual fallbacks as part of recovery plans. (bis.org)
Align your red‑team programme with TIBER‑EU; the framework was updated in 2024–2025 to align with DORA’s threat‑led penetration testing RTS and supports mutual recognition across the EU. (ecb.europa.eu)
Treat third‑party concentration as a first‑class risk: the ESAs and national authorities have begun designating critical ICT providers with direct oversight under DORA; build exit strategies and multi‑region, multi‑cloud portability into your architecture. (esma.europa.eu)

Offline as a resilience strategy

BIS Project Polaris provides a security and resilience framework and an offline handbook; use it to define threat models, device classes (SE, cards, wearables), and fraud/abuse mitigations for extended outages. (bis.org)

Concrete controls to implement in year one:

Multi‑region active‑active core with deterministic replay, cryptographic state anchoring, and pre‑approved kill‑switches for compromised wallet classes.
Quarterly sector‑style exercises: cross‑border incident runbook with central bank, intermediaries, and critical ICT providers (TIBER‑EU style). (ecb.europa.eu)

Interoperability and cross‑border readiness: what the latest pilots show

Synchronising with RTGS and across jurisdictions (wholesale)

Project Meridian FX (2025) showed that RTGS systems can interoperate via a synchronisation operator for PvP FX, connecting to multiple Eurosystem prototypes. This enables atomic settlement across heterogeneous infrastructures without rebuilding RTGS. (bis.org)
Fed NYIC’s Project Cedar x Ubin+ achieved cross‑border atomic settlement under 30 seconds on average, interlinking distinct central bank currency ledgers without a shared network—an important design input if your jurisdiction is sceptical of a shared mCBDC platform. (newyorkfed.org)

Multi‑CBDC platforms

Project mBridge reached MVP in 2024; HKMA, BoT, CBUAE, and PBoC (with SAMA joining) conducted real‑value transactions and opened the platform to more central/commercial banks under an MVP legal framework. BIS later stepped back operationally as the project matured, but the platform continues to expand. (bis.org)

Cross‑border retail model

Project Icebreaker’s hub‑and‑spoke approach keeps each retail CBDC domestic, uses competitive FX quotes, and completes transactions in seconds; your cross‑border strategy can adopt this without changing domestic ledger designs. (bis.org)

Adoption reality check: recent data points you should use in business cases

India’s retail e‑rupee hit 1 million daily transactions in December 2023 via incentives but fell to ~100k/day by mid‑2024; nonetheless, RBI’s 2024–25 annual report shows e‑rupee in circulation rose to ₹1,016 crore by March 2025 and the pilot expanded to 17 banks and ~6 million users, with offline features scaling. RBI is also exploring cross‑border pilots. (reuters.com)
Jamaica’s JAM‑DEX remains a small share of currency in circulation despite incentives; limited wallet providers and POS integration slowed merchant uptake—BOJ is pursuing dynamic QR on ~10,000 POS devices but readiness across providers is uneven. Use this as a cautionary tale for acceptance infrastructure. (jamaicaobserver.com)
The Bahamas plans to require commercial banks to offer Sand Dollar within two years to lift adoption—evidence that policy levers (not just incentives) may be necessary. (reuters.com)
China’s e‑CNY scale illustrates what “at‑scale” looks like: cumulative transactions reached 7 trillion yuan by June 2024, and 14.2 trillion yuan by September 2025, with dual‑offline features in production. Treat these as upper‑bound design inputs for throughput and reconciliation. (centralbanking.com)

A 90‑day CBDC security, privacy, and resilience plan (used by 7Block Labs)

Weeks 1–2: Baseline and risk mapping

Map requirements to PFMI, DORA, and national privacy laws; agree on 2h RTO and data‑minimisation targets by use case (retail/wholesale/offline). (bis.org)
Crypto inventory and “PQC day‑0” decisions: approve hybrid KEM/TLS profile and HSM roadmap toward FIPS 140‑3. (nist.gov)

Weeks 3–6: Architecture sprints

Select ledger style (centralised DB vs permissioned DLT) and API layer (Rosalind‑style), with ISO 20022 events for synchronisation/interop. (bis.org)
Offline design decision: pick secure‑element form factors and define offline limits, device attestation, and double‑spend evidence routines (Polaris guidance + device talks). (bis.org)
Privacy blueprint: alias service with DIDs/VCs; PETs hooks for collaborative AML (Aurora). (bankofengland.co.uk)

Weeks 7–10: Controls and tests

Build TIBER‑EU‑aligned red‑team scenarios; define cross‑border failover drills and sector exercises. (ecb.europa.eu)
Require SSDF compliance and SBOM+VEX for all components; integrate SBOM scanning into CI. (csrc.nist.gov)

Weeks 11–13: Pilot preparedness

Interop testbed: run PvP with a simulated RTGS or join a synchronisation PoC (Meridian FX patterns) and, where relevant, connect to an mCBDC sandbox or Icebreaker‑style hub. (bis.org)
Board‑level playbook: adoption KPI pack using India/Jamaica/Bahamas data; policy options (mandates, merchant incentives, government disbursements) with risk caps. (reuters.com)

Reference architecture (retail CBDC with offline and cross‑border paths)

Core
- Ledger: centrally governed database or permissioned DLT, with audit journals anchored by hash‑based signatures (FIPS 205). (nist.gov)
- API layer: 30+ standardised endpoints (Rosalind‑style), OAuth2.1 + selective‑disclosure credentials, PETs toggles for analytics. (bis.org)
- Messaging: ISO 20022 events for synchronised settlement and interop with RTGS (Meridian). (bis.org)
Identity and privacy
- Alias service using DIDs/VCs; intermediaries hold KYC and consent, not the core. (bankofengland.co.uk)
- Online: pseudonymised identifiers with encrypted attributes; offline: payer‑only disclosure and device‑resident limits. (ecb.europa.eu)
Crypto and keys
- HSM/KMS: FIPS 140‑3 validated modules; hybrid KEM; crypto inventory mapped to SP 800‑131A. (csrc.nist.gov)
Offline
- Secure element applets (eSE/iSE/eSIM) + card‑form factor for inclusion; counters, spending caps, and attestation; delayed reconciliation and fraud scoring on reconnect (Polaris, ECB analysis). (bis.org)
Resilience
- Active‑active multi‑region deployment; 2h RTO playbooks; quarterly TIBER‑EU engagements; vendor exit drills for DORA. (bis.org)
Cross‑border
- Retail: Icebreaker hub for FX quote competition and domestic‑only CBDC flows. (bis.org)
- Wholesale: synchronisation operator for PvP FX; optional mBridge corridor where available. (bis.org)

Emerging best practices you can adopt immediately

Set explicit privacy SLAs in your rulebook (e.g., maximum data fields per payment type, retention windows, audit‑only access patterns) aligned to ECB/BoE models. (ecb.europa.eu)
Treat PQC as a programme, not a toggle: hybrid rollout in 2025, PQC‑only for new secrets by 2027, deprecation of non‑agile components by 2028 (align to NIST transition guidance). (csrc.nist.gov)
Use PETs for AML effectiveness, not surveillance: collaborative analytics with privacy budgets and federated models instead of central log pools. (bis.org)
Exercise cross‑border outages: synchronised recovery with RTGS operators and corridor partners based on Meridian FX patterns. (bis.org)
Build merchant acceptance early: Jamaica and Bahamas show that POS enablement and wallet diversity make or break adoption—budget for QR retrofits and acquirer onboarding. (jamaicaobserver.com)

Decision checkpoints for executives

Do we have a signed 2h RTO architecture with offline fallbacks and manual reconciliation? If not, pilot is not ready. (bis.org)
Are crypto and keys agile and PQC‑ready, with an HSM migration path before the 2026 FIPS 140‑2 sunset? (csrc.nist.gov)
Can we prove user privacy claims (no central access to personal data) with technical controls and logs, not just policy? (bankofengland.co.uk)
Have we aligned red‑team/TLPT with TIBER‑EU/DORA so our regulators can mutually recognise tests? (ecb.europa.eu)
Is our cross‑border story grounded in synchronisation or hub‑and‑spoke models (Meridian/Icebreaker), not vague “interoperability”? (bis.org)

How 7Block Labs can help

90‑day readiness sprint: PFMI/DORA mapping, PQC and HSM roadmap, API threat modelling, offline prototyping, and TIBER‑EU exercise design. (bis.org)
Interop lab: Meridian‑style synchronisation harness and Icebreaker‑style FX hub to test RTGS/DLT links and corridor viability before regulatory sandboxes. (bis.org)
Privacy and PETs: implement alias services (DIDs/VCs), PETs pipelines for AML (Aurora), and provable “no access” controls for core operators (BoE model). (bis.org)

If you’re weighing a CBDC pilot—or you just need a resilient, privacy‑preserving payment platform—start with the controls and experiments above. They are based on what supervisors are already asking for, what pilots have actually achieved, and what it takes to withstand real‑world outages and adversaries.