Summary: When it comes to CBDC programs, their success or failure hinges on three key areas: architecture, privacy, and interoperability. We've put together a practical, decision-making playbook based on the latest trials from central banks and industry standards. This guide will help you pick the right ledger, design for privacy (both online and offline), and connect seamlessly with current systems and tokenized money.

CBDC consultancy: Architecture choices, privacy tradeoffs, and interop

Decision-makers aren't looking for more CBDC buzz--they want clear, verifiable options. This guide highlights what's actually working in central bank trials and industry initiatives in 2024-2025, plus how to incorporate these insights into your roadmap.

---

1) Architecture choices that actually scale

When you cut through the technical lingo, a retail or wholesale CBDC really comes down to three key decisions: the architecture of the ledger, the involvement of intermediaries, and how everything connects together.

1.1 Ledger architecture: ordered vs high‑throughput designs

• Ordered, single-sequencer designs
  • Pros: Easy to track global history and make audits a breeze.
  • Cons: Can hit a snag with ordering bottlenecks. During the MIT-Boston Fed Project Hamilton Phase 1, the “atomizer” (ordered) setup managed to peak at around 170k TPS with less than 2 seconds latency for 99% of the transactions. (eprint.iacr.org)
• Parallel, 2‑phase‑commit (2PC) designs
  • Pros: These designs offer almost linear scalability. Hamilton showed that they can reach around 1.7 million transactions per second (TPS), with about 99% finishing in under a second. The tradeoff? There's no single globally ordered list. They're perfect for retail micro-payments and environments with a lot of interconnected users. Check out more here.
• Implication: If you don't absolutely need a fully ordered global history for your policy and compliance needs, going with a 2PC-style core that has append-only evidence for audits can really help you save costs. But if you do need global ordering--like in some wholesale workflows--it's best to plan for sharded ordering or hybrid patterns.

1.2 DLT vs centrally operated cores

• Wholesale experiments have shown that Distributed Ledger Technology (DLT) can totally eliminate settlement risk with atomic payments versus payments (PvP). Plus, it can speed up settlement times from the typical T+2 days down to mere seconds, all while keeping ledger autonomy intact across different jurisdictions--there’s no need for a single shared operator. The work done by FRBNY and MAS on Cedar x Ubin+ achieved end-to-end times of under 30 seconds, maintaining atomicity across various ledgers. (newyorkfed.org)
• When it comes to retail, it turns out that distributed ledgers aren’t always necessary to hit those performance, privacy, or resilience targets. Hamilton’s team made it clear that under the trust assumptions of a single jurisdiction, a distributed ledger is “not needed” at all. (cryptoslate.com)

Practical take: Aim for the smallest trust surface you really need. If you’re dealing with domestic retail, a solid high-throughput non-DLT core, along with some evidence trails and robust APIs, usually does the trick. But when it comes to cross-border wholesale, using a multi-ledger DLT with PvP/atomicity can significantly boost both speed and reduce risks. (newyorkfed.org)

1.3 Intermediated distribution (two‑tier) by default

• So, it looks like mature designs are coming together on this two-tier retail model. Here, the central bank takes care of the core operations, while private Payment Interface Providers (PIPs) step in to manage things like KYC, user experience, and programmability. The BIS-BoE Project Rosalind has really put this into action with a universal API layer that has 33 endpoints split across six functional groups, making sure the core and edge stay nicely separated. (bis.org)
• On the flip side, the Bank of England has a pretty neat concept model. They’ve got the core ledger, API layer, alias service, and programmable “locking” features all within a bank-managed platform. Meanwhile, PIPs and ESIPs get to create the user-facing workflows. This setup also means that personal data access is kept under wraps. (beta.bankofengland.co.uk)

Engineering Note: Standardizing on an API Façade

Let’s get on the same page about using an API façade from the get-go. It’s way simpler to tweak the internal ledger stuff behind a solid API than it is to overhaul a bunch of wallets down the line. Rosalind demonstrates that this API can be ledger-agnostic while still fostering innovation. Check out the details here: (bis.org).

1.4 Consensus and runtime choices

• Wholesale multi-CBDC platforms are really gaining traction, especially those that use BFT with EVM-compatible runtimes. This combo helps developers reach a wider audience and boost composability. Check out BIS Project mBridge’s MVP--it’s EVM-compatible and has validating nodes set up at each central bank. (bis.org)
• If you're working within a national-scale retail setup, a 2PC core (like Hamilton) combined with a deterministic “evidence log” and periodic anchoring can actually outperform BFT when it comes to throughput, all while keeping things auditable. (eprint.iacr.org)

1.5 Offline from day one (if you’ll ever need it)

• BIS Polaris offers a comprehensive security and resilience framework along with an offline design guide. It views offline capabilities as a crucial element for resilience and inclusion, rather than just an extra perk. You can look forward to features like secure elements, replay protection, double-spend limits, and revocation processes. Check it out here: (bis.org)

---

2) Privacy tradeoffs you must pick explicitly

Users really value their privacy above everything else, while regulators are pushing for solid enforcement of AML/CFT rules. Here are some clear options we have:

2.1 Online privacy: pseudonymous by default, enforceable when needed

• The ECB is aiming for a digital euro that lets you make online transactions with more privacy than what we currently have. They’re working on using pseudonymisation, hashing, and encryption right at the Eurosystem boundary. Plus, all the anti-money laundering (AML) data will stay with payment service providers (PSPs). You can check out more details here.
• Meanwhile, the Bank of England’s approach guarantees that neither the Bank nor the Government will have access to your personal data. Instead, that information stays with payment interface providers (PIPs) and can only be shared when it’s required by law. You can read more about it here.

Implementation Tip: Think about using verifiable credentials for KYC proofs, along with role-separated data stores. This way, core operators won’t be able to connect someone’s identity to their transaction flows without going through the proper channels.

2.2 Offline privacy: “cash‑like” within risk budgets

• The ECB’s offline strategy is all about cash-like privacy. Basically, only the payer and payee know the details of the transaction--nothing gets shared with payment service providers or the Eurosystem. Just a heads up, we can expect some limits on holdings and transactions, plus measures to prevent replay attacks. (ecb.europa.eu)
• Research is increasingly focusing on e-cash-style protocols that combine hardware secure elements with some good old back-online reconciliation. The PayOff project (2024) illustrates how we can maintain privacy while also enforcing holding limits and protecting against any failures of the secure elements. (arxiv.org)
• The BIS's Project Tourbillon has made strides by prototyping payer anonymity and even testing out quantum-safe cryptography. While there’s still work to be done on practical throughput, the privacy features look pretty solid. (bis.org)

Policy Overlay

The EU's data-protection bodies are pushing for a “privacy threshold” for those low-value online transactions--meaning that below a certain amount, AML data won’t be tracked. This move is all about aligning online protections with what we already have offline. So, if you're building a product, consider integrating this tiered approach right from the start. You can check out more details here.

2.3 “Managed anonymity” in production pilots

• China’s e‑CNY is rolling out a cool feature called "controllable anonymity" in their wallet system. So, for smaller transactions, users can enjoy some level of pseudonymity. But if you want to move to higher wallet tiers, you'll need to provide stronger ID. This means you'll share more info with regulated parties, but merchants and most third parties won’t see your details. It's an interesting way to approach privacy and transaction limits. (ecns.cn)

2.4 Governance controls you’ll likely need

• They're looking at holding limits to keep bank funding stable. The ECB has mentioned some conservative user caps, and earlier chats suggested around ~€3,000 as a ballpark figure, but that’s not set in stone. (reuters.com)
• There’s also going to be a “single access point” where you can check your total holdings across different PSPs, all without having to reveal your identity to the central bank. How cool is that? (edpb.europa.eu)

Privacy Engineering Checklist

• PETs: Use zero-knowledge proofs for those compliance attestations and selective disclosure credentials.
• Separation of Duties: Make sure the core system can't decrypt identities, and the PIPs aren't able to view core-level graphs.
• Auditable Privacy: Implement tamper-evident logs, set up privacy budgets, and run a red team to assess re-identification risks.

---

3) Interoperability: domestic, cross‑border, and with tokenized money

The top way to future-proof your design is by ensuring it works smoothly across three different planes.

3.1 Domestic interop via an API layer

• Rosalind showcased a universal API that seamlessly functioned across various core designs and supported over 30 retail use cases. Think of APIs--not the ledger--as your main ecosystem contract. (bis.org)

3.2 Cross‑border retail: interlinking, not merging

• The BIS Project Icebreaker breaks down FX payments into two domestic legs linked by a “hub” that finds the best FX quotes and manages hash-time-locked PvP. The system runs 24/7 and supports HTLC, resulting in transactions that complete in just seconds while reducing counterparty risk. (bis.org)

Design choice: Keep each CBDC localized within its own system and interconnect them at the edges. This approach helps maintain policy independence while minimizing the risks associated with shared platforms. (bis.org)

3.3 Cross‑border wholesale: PvP and programmable FX

• Cedar x Ubin+ has achieved some pretty impressive atomic settlement across different autonomous central-bank ledgers in under 30 seconds on average, which totally wipes out principal risk. This approach can also scale for bridging currency routing, especially for those less-liquid pairs out there. (newyorkfed.org)
• Project Mariana took a dive into AMM-based wholesale CBDC FX using a public-permissioned setup that features bridges and a shared token standard. This is a handy option if you're looking for on-chain price discovery that wraps up neatly in central-bank money. (bis.org)
• mBridge hit its MVP milestone, with validating nodes set up at each central bank, EVM compatibility, a clear rulebook, and actual transactions happening through participating banks. It’s shaping up to be a solid testbed for add-on solutions. (bis.org)

3.4 Interop with existing rails (ISO 20022 and Swift)

• Just a heads-up: the MT/ISO 20022 transition period for cross-border financial institution payments wraps up on November 22, 2025. After that, you'll need to stick to ISO 20022 for your payment instructions. It’s a smart move to start mapping CBDC/payment messages to CBPR+ now so you don't end up with any shaky gateways down the line. You can read more about it here.
• Swift has been busy working on CBDCs, showing how different DLT networks can be connected with existing payment systems. They're planning to roll out a platform for connecting CBDCs within 12 to 24 months from their announcement in March 2024. Be sure to build your solutions using ISO 20022 semantics along with the certificate and PKI practices you’re already familiar with. Check out the details here.

3.5 Interop with tokenized deposits and securities

• The Regulated Liability Network (RLN) Proof of Concept (PoC) in the US revealed that using deposit tokens to settle transactions in a wholesale CBDC could really enhance international payments through a shared multi-entity ledger. Check out more details on this here.
• The Bank for International Settlements (BIS) has this exciting "unified ledger" vision, and their Project Agorá (running from 2024 to 2026) is set to test a multi-currency, programmable platform. This will merge tokenized commercial bank money with central bank reserves to enable atomic and composable transactions. Now might be a good time to align your CBDC semantics with deposit-token models. Dive deeper into this concept here.

---

4) What’s working in the wild: three concrete scenarios

1) National Retail Rollout with UPI/QR Interoperability and Programmability (India)

• The RBI has ramped up its retail e‑rupee pilot, teaming up with 17 banks and reaching around 6 million users by March 2025. The total value in circulation hit ₹1,016 crore, and they've started testing some cool features like offline transactions and programmability, which allows for targeted benefits and employee allowances. Plus, the UPI QR interoperability is making things a whole lot smoother for merchants. (Read more here)
• Actionable Tip: If your instant-payments network is already a big player, consider making CBDC a "first-class citizen" at those same acceptance points (think QR/NFC). It might be wise to focus on programmability for more specific, high-trust scenarios first, like benefits and allowances, rather than rolling it out for everyday retail just yet. (Check this out)

Cross-border treasury and FX (Cedar x Ubin+ style)

• Is your corporate treasury having a tough time with principal risk and cut-offs? Check out those wholesale CBDC testbeds. They can help you tackle atomic PvP across autonomous ledgers. Aim for confirmation times under 30 seconds and make sure your netting policies are written into smart contracts. For more details, take a look at this link.

3) Multi-CBDC Trade Corridors (mBridge/Icebreaker Mix)

• For regional corridors that have different policy appetites, it’s a good idea to use EVM-compatible shared platforms like the mBridge MVP for some experimentation. Additionally, you can set up an Icebreaker-style hub for retail remittances in areas where policy alignment is still a work in progress. (bis.org)

---

5) Best emerging practices we recommend to clients

Architecture and Performance

• Aim for at least 100k TPS and keep your p50 latency under a second for retail applications. If you need even more performance, you might want to look into 2PC-style cores that come with evidence logs. And don’t forget to test how everything holds up when you lose two datacenters, just like they did in the Hamilton tests. Check it out here: (globalgovernmentfintech.com).
• When it comes to programmability, keep it simple at the core. Offer basic building blocks like locks and escrows, and let PIPs handle the workflow composition. This aligns with what the Bank of England is suggesting and helps to lower systemic risk that comes from complicated core logic. More details can be found here: (beta.bankofengland.co.uk).

Privacy and Compliance

• Consider using a tiered approach for privacy and limits--think “keep it anonymous for smaller transactions, but traceable for larger ones.” It’s a good idea to use ZK-based compliance attestations when you can. Check it out here: (mdpi.com).
• When it comes to offline scenarios, it's smart to go with Polaris controls. This means integrating secure elements, setting up double-spend risk budgets, ensuring device attestation, and getting that hot-list updated quickly once devices reconnect. You can read more about it here: (bis.org).

Interop and Standards

• Make sure to map all your payment and account events to ISO 20022 CBPR+ now. You’ll want to test those post-coexistence behaviors before November 22, 2025, like NAK/contingency processing. Check out more details here.
• When it comes to cross-border transactions, consider using HTLC-based PvP (Icebreaker) or atomic settlement contracts (Cedar x Ubin+). The choice really depends on whether you need centralized or decentralized routing--so choose wisely! You can read more about it here.

Security and Resilience

• Use the BIS Polaris 7-step security/resilience framework to guide your approach, and don't forget to put PETs through some adversarial testing to check out their re-identification risk. You can find more details on this here.

Ecosystem Enablement

• Roll out a solid API similar to Rosalind, complete with versioned endpoints and handy reference SDKs. Plus, let’s organize regular “vendor test weeks” to ensure wallet compatibility and manage load profiles with our ecosystem partners. (bis.org)

Governance

• Separate roles: core operators can't connect identity to transactions; Payment Service Providers (PSPs) hold Personally Identifiable Information (PII); regulators can only access data through legal pathways. Make sure to reflect the governance commitments of the Bank of England and the European Central Bank in your policy documents and code. (bankofengland.co.uk)

---

6) RFP checklist and acceptance criteria (copy/paste)

• Ledger
  • It supports both ordered and parallel modes, which is pretty cool. You’ll want to document TPS and latency at the P50 and P95 levels across different failure scenarios. Oh, and don’t forget to design an evidence log for audits. Plus, make sure to benchmark against Hamilton targets. You can check out more here.
• API and SDKs
  • You’ll need to roll out Rosalind-equivalent features, including payments, onboarding, aliasing, consented data access, and dispute flows. Also, a versioning policy with clear deprecation timelines is a must. More details can be found here.
• Privacy
  • For online transactions, we’re going with pseudonymised end-to-end data. Offline, think cash-like transactions up to configurable limits. Make sure to include a PET design along with a red-team strategy. Also, keep in mind the EDPB “privacy threshold” for low-value online transactions. You can learn more here.
• Offline
  • We’ll focus on device attestation, keeping an eye on risk budgets, spotting double spends, and managing secure-element lifecycles. Don’t forget to conduct recovery drills according to Polaris guidelines. More info is available here.
• Interop
  • It needs to be ISO 20022 native with CBPR+ mappings. Support for HTLC and/or atomic PvP is also required, along with gateway patterns to accommodate Swift pilots and mBridge/EVM plugins. You can find out more here.
• Operations
  • We’re aiming for a 24/7/365 operational posture, complete with observability SLIs. Don’t forget to implement incident response protocols and lawful-access workflows, along with audit APIs.

---

7) A reference blueprint we deploy at 7Block Labs

• Core
  • We’ve got a parallel transaction processor (2PC) for retail, plus an optional ordered shard that’s perfect for those audit-heavy tasks.
• API Layer
  • Think of it like a Rosalind-style façade, decked out with OAuth2.1/MTLS, an alias service, programmable “locks/holds” primitives, and an event bus to handle receipts and disputes. Check it out here: bis.org
• Privacy
  • We’re using a VC-based KYC approach, along with ZK proofs for sanctions checks. Plus, we've designed a split-knowledge key architecture so that no single entity can link identity and transaction flows.
• Offline
  • Our secure-element wallets come with risk budgets, inspired by PayOff safeguards and the Polaris threat model. Dive deeper here: arxiv.org
• Interop
  • We're all about those ISO 20022 native messages, featuring an HTLC module, a PvP atomicity service, and an EVM plug-in for mBridge-style pilots. There’s also a Swift gateway in line with CBPR+, which you can read more about at bis.org.
• Governance
  • We’ve set up a holding-limit service through a privacy-preserving “single access point,” alongside a law-enforcement gateway that verifies warrants and keeps an immutable audit trail. More info can be found at edpb.europa.eu.

---

8) What to watch next (12-24 months)

• Just a heads up: the ISO 20022 “coexistence” phase wraps up on November 22, 2025. Make sure to run those cutover rehearsals and negative-acknowledgement tests this quarter. Check out more details on swift.com.
• The digital euro program is getting exciting as it moves into the build and pilot phases. We’ll see things like offline privacy, PSP roles, and caps finalized in the rulebook and pilots set for 2026 to 2029. Now's the time to start getting your wallet, offline, and PET options in sync with the ECB/EDPB signals. More info can be found on ecb.europa.eu.
• Got an interest in mBridge? The MVP is now open for private-sector add-ons! If your corridor involves CNY, AED, THB, HKD, or SAR, think about exploring cross-border use cases in the sandbox. Dive into the details on bis.org.
• BIS Project Agorá is in the works, creating a multi-currency unified ledger with over 40 institutions. You can look forward to design patterns for tokenized deposits and wholesale CBDC that you can adapt for domestic use. For more info, check bis.org.
• India’s e-rupee is making strides with programmability and ongoing cross-border pilots. The QR/UPI interoperability is the go-to model for merchant acceptance. You can read more about it on economictimes.indiatimes.com.

---

Final take

If you’re gearing up to launch a CBDC or a related tokenized-money program in 2025, it's a good idea to tackle some key decisions early on. Focus on these three things: (1) choose a ledger design that really fits your performance and audit requirements, (2) set up a privacy model that clearly defines online/offline tiers along with Privacy-Enhancing Technologies (PETs), and (3) ensure interoperability with ISO 20022, Swift, and tokenized deposits.

The great part? You don’t have to start from scratch--just look at what pilots have already validated, package it up with a clean API, and keep refining it through industry testbeds instead of diving straight into production.

Looking to really dig into an architecture review or kickstart a pilot build that fits these patterns? 7Block Labs is here to help you take that leap from PoC to a top-notch, policy-grade deployment.