CBDC Consultancy: Security, Privacy, and Operational Resilience

The Go-To Guide for Decision-Makers on Designing CBDCs

Here’s a hands-on playbook aimed at decision-makers looking to create Central Bank Digital Currencies (CBDCs) that are strong against quantum threats, prioritize user privacy, and are built to last. This guide is lined up with what’s happening in regulations, ongoing pilot programs, and real-world insights from 2024 to 2025.

What You Can Expect

Concrete Architecture Choices: We’ll break down the tech framework options you have.
Testable Controls: Get the skinny on controls you can actually put to the test.
Adoption Data: Find useful stats and figures that you can drop into your board presentations right now.

So, let’s dive in and get you equipped to handle the future of digital currencies!

TL;DR (description)

Central banks and businesses are shifting gears from experimenting with CBDCs to rolling out regulated pilot programs. This post breaks down the latest standards, privacy models, cross-border insights, and resilience requirements into an actionable blueprint that you can use, whether or not your project comes with a CBDC mandate. (bis.org)

Why security, privacy, and resilience must be designed together

Regulations are now pushing for resilience throughout the entire supply chain. In the EU, DORA kicks in on January 17, 2025, and it's extending its watchful eye to “critical” ICT providers. Regulators are actively choosing cloud and market infrastructure vendors for direct oversight. (eiopa.europa.eu)
CBDCs are going to be treated like Financial Market Infrastructures (FMIs): The CPMI‑IOSCO cyber guidelines are aiming for a two-hour recovery time objective (2h RTO) for critical operations--even in tough scenarios. This goal will shape everything from architecture to testing and fallback strategies from the get-go. (bis.org)
We're seeing privacy expectations getting some official backing. The ECB’s work on the digital euro lays out plans for cash-like privacy when offline, and for online use, it introduces pseudonymized and encrypted identifiers. Plus, the Bank of England has promised that neither the Bank nor the Government would access personal data within the core infrastructure of a digital pound. (ecb.europa.eu)
The world of cryptography is evolving: NIST gave the green light to Post-Quantum Cryptography (PQC) standards in August 2024 (FIPS 203/204/205). If you’re involved with long-lived CBDC ledgers and wallets, it’s high time to kick off migration planning. (nist.gov)

Security: what “good” looks like in 2025

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

Time to get serious about crypto-agility and hybrid key exchange! Start using TLS profiles that mix classical methods (like X25519) with PQC (specifically, FIPS 203 Kyber KEM). Don’t forget to take stock of your cryptography and set rotation SLAs. NIST’s SP 800‑131A guidance and the draft Rev.3 are pushing for a shift to at least ≥128-bit security and PQC. Check it out here: (csrc.nist.gov)
When it comes to HSM baselines, make sure you're on top of the FIPS 140‑3 validation for any new modules. Get your upgrade plans in place before the FIPS 140‑2 sunset; all 140‑2 certs will be moved to the historical list by September 21, 2026. This is especially important if you’re dealing with CBDC custody nodes, issuing services, or offline hardware. Find more here: (csrc.nist.gov)
Think about your signature and attestation strategy. It’s time to phase in ML‑DSA (FIPS 204) for managing ledger changes and wallet attestations. Also, consider using hash-based signatures (FIPS 205) for those long-term audit anchors and root-of-trust. More details can be found here: (nist.gov)

Practical Control Set to Include in Your RFPs

Make sure to look for a PQC‑ready KMS that comes with hybrid KEM/TLS and handy crypto inventory dashboards (check out the SP 800‑131A mapping) for a solid foundation. (csrc.nist.gov)
Don't forget to include dual‑admin ceremonies, M of N approvals, and deterministic builds for all release artifacts--these are super important (see the SSDF for details). (csrc.nist.gov)

2) Wallet security--including offline

China's e‑CNY app lets users do NFC "tap-to-pay" transactions even without power. It’s pretty cool since users can set their own limits and use code-free quotas--this is a solid example of a dual-offline user experience and risk management. When designing your policy engine, think about setting limits on amounts and attempts, quick revocation processes, and delayed reconciliation. (nfcw.com)
The ECB is looking into rolling out an offline digital euro using secure elements like eSE, iSE, and eSIM. They've been chatting with device makers about this in late 2024, so it’s a good idea to incorporate these options into your procurement plans to steer clear of vendor lock-in. (ecb.europa.eu)
As for research direction, consider protocols that keep computation light within the secure element (think delete-only tokens plus signatures). This approach shrinks the attack surface while still allowing for double-spend detection once you reconnect. (eprint.iacr.org)

Checklist:

Make sure to require secure element attestation, tamper-resistant counters, and offline balance ceilings for each persona.
Set up a reconciliation SLA and create a double-spend evidence pipeline (signed transcripts) for any offline events.

3) Ledger, API, and software supply chain hardening

Go for an API layer that has standardized functions across different wallets and services. This approach was showcased by the BIS/BoE Project Rosalind, which created 33 retail CBDC APIs. Make sure to put rate limits, consent, and PETs hooks on each endpoint. (bis.org)
Implement ISO 20022 messaging on synchronization rails to ensure smooth interoperability with RTGS and asset ledgers (like Meridian), not just sticking to DLT-to-DLT. (bis.org)
Make SSDF practices and SBOMs a must. Ask suppliers to hand over SBOMs in SPDX/CycloneDX format along with VEX attestations; CISA’s 2025 Minimum Elements draft is a solid reference for the fields and coverage you should expect. (csrc.nist.gov)

Privacy by design: implementable patterns from live programs

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

Offline payments: The transaction details are kept private between the payer and payee. Meanwhile, for online transactions, everything is pseudonymized and encrypted, making it impossible for the Eurosystem to connect payments directly to individuals. Access to AML data is limited to intermediaries. When you design your data model and audit trails, make sure to incorporate these constraints. (ecb.europa.eu)

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

The Bank of England and HM Treasury have laid out some key principles: they won’t be snooping on users' personal data. Instead, there’s going to be a platform model where intermediaries (like PIPs/ESIPs) take care of KYC and consent. They’re also looking into using DIDs/VCs for an alias service, which could help cut down on personal data sharing throughout the ecosystem. (bankofengland.co.uk)

Apply now:

Set up an alias service that uses rotating, unlinkable identifiers (like DID/VC) instead of fixed IDs, and provide detailed consent options to PIPs. (bankofengland.co.uk)

PETs and selective disclosure

The BIS Project Tourbillon has come up with a cool design that ensures payer anonymity--it’s cash-like for the payer, but not so much for the payee. This approach helps to minimize data exposure while still giving merchants clear compliance pathways. If you’re looking for high-privacy options in retail, this is definitely a model to consider. Check it out here.
On the other hand, the BIS Project Aurora is all about collaborative analytics. It uses Privacy-Enhancing Technologies (PETs) and network analysis to boost the effectiveness of Anti-Money Laundering (AML) efforts without the hassle of centralizing raw personal data. This model really shines when it comes to spotting suspicious patterns across different intermediaries. You can dive into the details here.

Operational resilience that auditors will sign off

Map to PFMI, DORA, and threat‑led testing

Make sure to get your systems up and running within a two-hour time frame for crucial operations, as outlined by CPMI‑IOSCO, and aim to wrap up settlement by the end of the day. Don’t forget to document your backup plans and any manual processes you can rely on during recovery. Check out more details in this BIS document.
Get your red-team program on the same page as TIBER‑EU; they rolled out some updates in 2024-2025 that align with DORA’s threat-led penetration testing standards. This is a great way to ensure mutual recognition right across the EU. For more info, head over to the ECB website.
Think of third-party concentration risk as something that needs your full attention. The ESAs and national authorities are now tagging critical ICT providers for direct oversight under DORA. So, it’s wise to put some exit strategies in place and make sure your architecture supports portability across different regions and cloud services. Dive deeper into this topic with the details found on ESMA's page.

Offline as a resilience strategy

The BIS Project Polaris has got you covered with a solid security and resilience framework along with an offline handbook. This resource is great for outlining threat models, different device classes (think SE, cards, wearables), and strategies to tackle fraud or abuse during extended outages. Check it out here: (bis.org)

Concrete controls to implement in year one:

Set up a multi-region active-active core that includes deterministic replay, cryptographic state anchoring, and pre-approved kill-switches for those wallet classes that might get compromised.
Conduct quarterly sector-style exercises. This means running a cross-border incident playbook with the central bank, intermediaries, and key ICT providers, similar to the TIBER-EU approach. You can check out more details here.

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

Synchronising with RTGS and across jurisdictions (wholesale)

Project Meridian FX (2025) demonstrated that RTGS systems can actually work together through a synchronization operator for PvP FX. This connects various Eurosystem prototypes and allows for atomic settlement across different infrastructures without the need to completely overhaul the RTGS. You can check it out more here.
In a similar vein, the Fed NYIC’s Project Cedar x Ubin+ managed to pull off cross-border atomic settlements in under 30 seconds on average! It links up different central bank currency ledgers without relying on a shared network--definitely a crucial factor if you're in a jurisdiction that's a bit wary of a shared mCBDC platform. More details can be found here.

Multi‑CBDC platforms

In 2024, Project mBridge hit its MVP milestone! The HKMA, BoT, CBUAE, and PBoC (along with SAMA) started conducting real-value transactions and welcomed more central and commercial banks to the platform under an MVP legal framework. As the project moved forward, BIS stepped back from day-to-day operations, but the platform is still growing strong. (bis.org)

Cross‑border retail model

Project Icebreaker’s hub-and-spoke model ensures that every retail CBDC stays local. It leverages competitive FX quotes and wraps up transactions in just a few seconds. You can totally integrate this into your cross-border strategy without needing to tweak your domestic ledger designs. (bis.org)

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

India’s retail e‑rupee took off with a bang, hitting 1 million daily transactions in December 2023 thanks to some solid incentives. However, by mid‑2024, that number dropped to around 100,000 per day. On the bright side, the RBI’s annual report for 2024-25 showed that e‑rupee circulation climbed to ₹1,016 crore by March 2025. The pilot program expanded to 17 banks and approximately 6 million users, with offline features gaining traction. Plus, the RBI is checking out cross-border pilots. (reuters.com)
Jamaica’s JAM‑DEX is still a pretty small player in the currency game, even with some incentives on the table. The few wallet providers and the slow rollout of POS integration have kept merchants from jumping on board. The Bank of Jamaica is working on rolling out dynamic QR codes on about 10,000 POS devices, but the readiness varies across providers. This highlights the importance of having proper acceptance infrastructure. (jamaicaobserver.com)
The Bahamas is gearing up to make it mandatory for commercial banks to offer the Sand Dollar within the next two years to boost adoption. This shows that sometimes, policy measures (not just incentives) can play a key role in getting things moving. (reuters.com)
China’s e‑CNY really demonstrates what “at‑scale” looks like. By June 2024, cumulative transactions hit a staggering 7 trillion yuan and soared to 14.2 trillion yuan by September 2025, with dual‑offline features already in action. These figures can serve as a benchmark for throughput and reconciliation efforts. (centralbanking.com)

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

Weeks 1-2: Baseline and Risk Mapping

Let’s get our requirements sorted with PFMI, DORA, and the national privacy laws. We need to nail down a 2-hour RTO and data-minimization targets for each use case (retail, wholesale, and offline). Check out the details here.
Time to tackle the crypto inventory and make some key “PQC day-0” decisions. We’ll need to approve the hybrid KEM/TLS profile and set up our HSM roadmap to reach FIPS 140-3 compliance. More info can be found here.

Weeks 3-6: Architecture Sprints

Choose your ledger style: Decide between a centralized database or a permissioned distributed ledger technology (DLT). Also, select the API layer, going for that Rosalind-style, and make sure to incorporate ISO 20022 events for smooth synchronization and interoperability. Check out more about it here.
Offline design choices: It's time to pick the right secure-element form factors and set up the offline limits. Don't forget to cover device attestation and routines for spotting double spends--Polaris has some great guidance, plus there’ll be talks about devices. More info can be found here.
Privacy blueprint: Let’s get creative with an alias service that uses DIDs/VCs and hooks for privacy-enhancing technologies (PETs) to help with collaborative anti-money laundering (AML)--check out the insights from Aurora here.

Weeks 7-10: Controls and Tests

Set up some TIBER‑EU‑aligned red‑team scenarios and lay out cross-border failover drills along with sector exercises. Check it out here: (ecb.europa.eu).
Make sure we’re all on the same page with SSDF compliance and get SBOM+VEX for every component. Plus, let’s weave in SBOM scanning into our CI process. You can find the details here: (csrc.nist.gov).

Weeks 11-13: Getting the Pilot Ready

Interop Testbed: Get into the groove by running a Player vs Player (PvP) test with a simulated Real-Time Gross Settlement (RTGS) system, or hop onto a synchronization Proof of Concept (PoC) using Meridian FX patterns. If it makes sense, connect with an mCBDC sandbox or check out an Icebreaker-style hub. Learn more here.
Board-Level Playbook: Put together an adoption KPI pack using insights from India, Jamaica, and the Bahamas. This should include various policy options like mandates, merchant incentives, and government disbursements--all with some thoughtful risk caps in place. Check this out for more details.

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

Core
- Ledger: Think of it as a centralized database or a permissioned distributed ledger technology (DLT), where everything is backed by audit journals anchored with hash-based signatures (FIPS 205). Check it out here.
- API layer: Features over 30 standardized endpoints (kind of like Rosalind), plus OAuth2.1 and selective-disclosure credentials, with PETs toggles for analytics. More info can be found here.
- Messaging: We're using ISO 20022 events for smooth settlement and interoperability with RTGS (that’s Meridian for you). Check out the details here.
Identity and privacy
- Alias service: This uses DIDs/VCs, meaning intermediaries are the ones holding onto KYC data and consent instead of the core system. Find out more here.
- Online and Offline: Online, we’re talking pseudonymized identifiers alongside encrypted attributes. For offline, we’ve got payer-only disclosures and device-resident limits. More details available here.
Crypto and keys
- HSM/KMS: We’re working with FIPS 140-3 validated modules and a hybrid KEM, with a crypto inventory that lines up with SP 800-131A. You can read more here.
Offline
- Secure element applets: These include eSE/iSE/eSIM, plus a card form factor for added convenience. Features like counters, spending caps, and attestation help keep things secure; plus, we’ve got delayed reconciliation and fraud scoring when you reconnect (thanks to Polaris and ECB analysis). More on this here.
Resilience
- Deployment: We’re looking at an active-active multi-region setup, with 2-hour RTO playbooks in place, quarterly TIBER-EU engagements, and vendor exit drills for DORA compliance. Learn about it here.
Cross-border
- Retail: The Icebreaker hub is in play for FX quote competition and domestic-only CBDC flows. Details can be found here.
- Wholesale: We’ve got a synchronization operator for PvP FX and optional mBridge corridors wherever possible. Check out more here.

Emerging best practices you can adopt immediately

Make sure to set clear privacy SLAs in your rulebook. Think about things like the maximum data fields per payment type, how long you keep data, and access patterns that are strictly for audits. This should all line up with the ECB/BoE models. You can find more details here.
Approach PQC as a full-fledged program instead of just a quick switch. Plan for a hybrid rollout in 2025, go PQC-only for new secrets by 2027, and start phasing out those non-agile components by 2028, making sure to follow NIST's transition guidance. Want to dive deeper? Check it out here.
When it comes to AML effectiveness, think of using PETs in a way that focuses on collaboration instead of surveillance. Go for collaborative analytics that feature privacy budgets and federated models, rather than relying on central log pools. More info can be found here.
Don’t forget to run through some cross-border outage scenarios! Make sure you have a synchronized recovery plan in place with RTGS operators and corridor partners, based on what you learn from Meridian FX patterns. Find further insights here.
It’s crucial to build merchant acceptance from the get-go. Look at Jamaica and the Bahamas--they’ve shown that enabling POS and offering a range of wallet options can really make or break adoption. So, be sure to allocate budget for QR retrofits and onboarding acquirers. Check out the latest on this here.

Decision checkpoints for executives

Do we have a signed 2-hour RTO architecture in place that includes offline fallbacks and manual reconciliation? If not, we’re not ready for the pilot yet. (bis.org)
Are our crypto and keys flexible and ready for PQC, along with a plan for HSM migration before the 2026 FIPS 140-2 deadline? (csrc.nist.gov)
Can we back up our user privacy claims (like having no central access to personal data) with actual technical controls and logs, rather than just relying on policy statements? (bankofengland.co.uk)
Have we made sure that our red-team/TLPT efforts align with TIBER-EU/DORA so that our regulators can recognize each other’s tests? (ecb.europa.eu)
Is our cross-border strategy based on solid frameworks like synchronisation or hub-and-spoke models (Meridian/Icebreaker), rather than just some vague notion of “interoperability”? (bis.org)

How 7Block Labs can help

90-day readiness sprint: We're diving into PFMI/DORA mapping, creating a roadmap for PQC and HSM, doing some API threat modeling, prototyping offline, and designing the TIBER-EU exercise. Check it out here: (bis.org).
Interop lab: We're setting up a Meridian-style synchronization harness and an Icebreaker-style FX hub to test RTGS/DLT links and figure out if the corridors are viable before we jump into regulatory sandboxes. More details here: (bis.org).
Privacy and PETs: We're on it with implementing alias services (like DIDs and VCs), creating PETs pipelines for AML (Aurora), and developing provable “no access” controls for core operators, following the BoE model. Learn more at: (bis.org).

If you’re thinking about launching a CBDC pilot or just looking for a solid payment platform that keeps privacy in mind, check out the controls and experiments mentioned above. They’re grounded in what supervisors are currently looking for, what past pilots have accomplished, and what’s needed to handle real-life outages and challenges from adversaries.