CBDC consultancy: Integrating Retail CBDC Wallets with Existing Core Banking

Decision-Makers’ Summary

Retail Central Bank Digital Currencies (CBDCs) are shifting gears from just being discussed in whitepapers to actually launching production pilots. This guide dives into the nitty-gritty details of integrating a retail CBDC wallet stack with your bank’s core systems. We’ll cover the latest central bank API patterns, tips for offline payments, best practices for ISO 20022 data, and insights from live pilots in places like India, the Bahamas, Jamaica, and China. You can find more info here.

Why this matters now

• The Eurosystem is working on a unified "digital euro scheme rulebook," and they’re aiming to kick off early testing around mid-2027. They've set their sights on having everything ready for launch in 2029. This means banks and payment service providers need to start making some big changes well ahead of the official green light. (ecb.europa.eu)
• Real-world retail CBDC pilots are on the rise: India’s e₹ has made waves, reaching 17 banks, gaining over 6 million users, and hitting ₹1,016 crore in circulation by March 2025. Plus, they’ve opened up the pilot to non-bank wallet providers like CRED and MobiKwik. (economictimes.indiatimes.com)
• We’re seeing some valuable lessons in adoption: The Bahamas has linked the Sand Dollar to its national ACH and is gearing up to mandate that commercial banks distribute it. Jamaica is set to roll out CBDC on standard POS systems using dynamic QR codes. Meanwhile, China has reported that the total transactions for e-CNY have reached trillions of yuan. (centralbankbahamas.com)

This post breaks down the latest integration patterns that 7Block Labs is using for CBDC programs. Our goal is to help banks enhance their current core systems rather than replace them entirely.

---

The target state in one picture

A two-tier retail CBDC model keeps the central bank’s ledger pretty lean while allowing supervised intermediaries like banks and payment service providers to handle things like wallet user experience, onboarding, screening, and other value-added services. There’s an API layer that connects both tiers in a formal way.

The BIS/BoE "Project Rosalind" demonstrated this concept with 33 standardized endpoints across six functional categories and over 30 different use cases, including offline and device-based payments. Now, the challenge for your bank is to figure out how to integrate those functions into your payment hub, general ledger, risk management stack, and data governance strategy. (bis.org)

---

Core concepts (fast)

• Two-tier issuance: The central bank issues the CBDC, while intermediaries handle distribution and services. Keep the central bank's ledger straightforward; let the banks take care of programmability and user experience. (bis.org)
• Wallets ≠ deposit accounts: Remember, CBDC balances are liabilities of the central bank, while deposits are liabilities of commercial banks. Make sure your integration supports smooth and reversible conversion paths.
• ISO 20022 everywhere: The harmonized usage of ISO 20022 is on track to mature by 2027--so, design your CBDC adapters to handle clean ISO 20022 data across payment channels and CBDC APIs. (bis.org)
• Offline is real: Resilience requirements mean that you’ll need value-limited offline payments through secure elements, smart cards, or SIM-based wallets--so plan for limits, reconciliation, and fraud controls right from the get-go. (bis.org)

---

Integration blueprint: bank systems that must change

1) Identity, Onboarding, and Limits

• Reuse KYC: Once customers finish their KYC process, issue a verifiable credential so they can quickly set up interoperable CBDC wallets with tiered limits across different channels. W3C Verifiable Credentials 2.0 became a W3C Standard in 2025--so make sure to use it for sharing KYC assertions between wallet providers. (w3.org)
• Tiering Policy: Align tiered wallets (like basic versus fully verified) with transaction and balance caps, and establish stricter offline limits. Check out the ECB drafts and BIS Polaris for more details. (ecb.europa.eu)

2) Wallet Lifecycle and Device Security

• Make sure to link wallets to secure hardware like secure elements, TEE, smartcards, or SIMs. It’s super important to enforce device attestation and keep an eye on risk scores when users log in and make transactions.
• When it comes to keys and HSMs, you’ve got to manage your master keys, tokenization keys, and offline one-time counters in FIPS 140‑3 validated HSMs. And don’t forget to plan ahead for migrations from 140‑2 since that’ll be hitting its end-of-life before we know it in 2026. Check out more details here.

3) Account ↔ Wallet Conversion

• Domestic on/off-ramps: It’s all about making it easy for users to move their money. We need to set up ACH and instant payment adapters for both “Deposit → CBDC wallet” and “Wallet → Deposit.” Take The Bahamas, for example--they’ve got ACH integration all sorted out. Now, bank customers can top up their Sand Dollar right from their online banking. Then there’s Nigeria’s eNaira, which smartly connects each wallet to a NUBAN ID and processes transactions through NIBSS Instant Payments. It’s a good move for your bank to create aliasing tables that link wallet IDs to bank accounts, making the conversion process smooth and straightforward. (centralbankbahamas.com)

4) Payments and Messaging

• Dive into ISO 20022 fields like payer/beneficiary, purpose, structured address, and LEI to enhance your screening, reconciliation, and analytics. Make sure you’re in step with CPMI’s 12 harmonized data requirements. Don’t forget to map your CBDC payment requests to the pacs.008/pacs.002 equivalents in your hub. Check it out here: (bis.org).
• When it comes to real-time ledger posting, aim for those CBDC payments to hit the wallet ledger in less than a second. Your core systems should be able to reflect this through event-sourced booking and almost real-time GL posting.

5) Risk, AML/CFT, and Data

• Make sure to apply your usual AML/BSA/OFAC procedures to any CBDC inflows and outflows. Keep a close eye on transaction monitoring for CBDC wallet transfers, too. When it comes to cross-border transactions or interactions with Virtual Asset Service Providers (VASPs), make sure you’re on the same page as FATF’s latest virtual asset standards and the Travel Rule expectations at the boundaries (where it makes sense). You can check out more about it here: (fatf-gafi.org).
• For data minimization and privacy, it’s important to design your APIs in a way that upholds the CBDC privacy model. Think about using an intermediated model where the central bank doesn’t have access to personal data--this was a key point highlighted in the UK’s response to the digital pound consultation. For more details, take a look here: (bankofengland.co.uk).

---

What your CBDC API gateway should expose (Rosalind-aligned)

Project Rosalind confirmed the effectiveness of a neutral API layer that connects the central bank ledger with private-sector applications. Take those insights and turn them into a bank-facing API gateway that supports your wallet services while keeping your core system safe. Here are a few examples:

• Identity and onboarding
  • POST /wallets: This endpoint lets you create a wallet for a KYC’d customer by using a verifiable credential reference. You can also set the tier, limits, and device bindings here.
  • POST /consents: Use this endpoint to grab explicit consent from customers for sharing their data, as well as for analytics and signing them up for offline capabilities.
• Liquidity and Conversion
  • POST /wallets/{id}/topup: This endpoint lets you pull funds from a connected deposit using ACH or RTP. Just make sure to include those ISO 20022 details like the amount, purpose, and remittance info.
  • POST /wallets/{id}/redeem: Use this one to push funds back to your deposit. It incorporates pacs.008 mapping, so you can expect same-day availability.
• Payments
  • POST /payments/authorize: This one’s all about reserving the balance and it’s got your back with merchant presentment using QR/NFC, plus some offline options if you need them.
  • POST /payments/capture and DELETE /payments/{id}: Here, you can either finalize the payment or void it altogether.
  • POST /payments/offline/reconcile: Use this to send in signed offline bundles along with counters and risk labels.
• Compliance and Telemetry
  • POST /reports/aml: This is where you send those enriched ISO 20022-structured events straight to your AML engine.
  • GET /wallets/{id}/limits: Check out the dynamic limits here, taking into account whether online/offline, the risk tier, and those ECB-style holding caps. (bis.org)

Implementation Notes

• We're going to use an event bus (like Kafka or Pulsar) to send out CBDC wallet events to GL, CRM, AML, and analytics.
• Don’t forget to incorporate idempotency keys, replay protection, and high-watermark cursors for those offline bundle ingestions.
• Make sure API privacy enforcement aligns with the CBDC scheme’s rulebook. Think about user experience minimums, latency, and dispute workflows, all of which the ECB’s RDG is working to codify. You can check out more details on their progress here.

---

Throughput, latency, and resilience targets you can defend internally

Fed/MIT’s Project Hamilton introduced us to two cool architectures: the first one is an ordered, block-based design that wraps up over 99% of transactions in under 2 seconds and hits around 170,000 transactions per second (TPS). The second? A parallel, unordered setup that boasts a whopping ~1.7 million TPS with 99% of transactions completing in under 1 second. Now, you probably won’t be able to replicate that kind of performance from end to end in a bank, but it does give you a solid benchmark for your wallet and core adapters.

So, here’s the game plan: aim for a p99 latency of less than 500 ms on your API gateway, keep your end-to-end p99 under 1.5 seconds for domestic retail payments, and ensure there’s zero-data-loss failover split across two datacenters. Check out more details here.

Resilience checklist (condensed)

• Multi-region active-active gateway; stateless API layer with distributed session tokens.
• Write-ahead logs for wallet debits/credits; GL replication with exactly-once semantics.
• HSM clustering across sites; automated key rotation; JD-RTO goals integrated into runbooks.

---

Offline: what “good” looks like in production

BIS's “Project Polaris” is all about crafting handbooks and design guides specifically for offline CBDC. If we break it down, it focuses on three main areas: constrained value, secure hardware, and verifiable reconciliation. You can check it out more on their official page here: (bis.org).

• Device classes:
  • We've got SE‑backed smartphones (think NFC) equipped with offline counters;
  • hardware cards sporting e‑ink displays that show balance and dynamic QR codes;
  • and SIM‑based hard wallets specifically for those moments when devices are powered down. China’s e‑CNY ecosystem has already given all three a test run. So, when you’re designing your wallet server, make sure it can spot the device class during risky times. (digitalpoundfoundation.com)
• Limits and policy:
  • Keep in mind that the daily offline cap is noticeably lower than the online cap; it’s even stricter for those anonymous or low‑KYC tiers. Don’t forget to enforce the expiry of offline value blobs!
  • If you find yourself in a situation where both parties are offline, treat that as provisional until you can reconcile. Also, make sure to version your conflict rules to keep those false positives to a minimum. (bis.org)
• Recovery and forensics:
  • It’s crucial to store cryptographic receipts for every spend. Consider running some background graph analytics to sniff out any double‑spend patterns.
  • And if you start suspecting fraud, you can remotely lower the device limit class the next time it connects.

---

Data and standards: make ISO 20022 work for you

CBDC is built to introduce fresh message types and an API surface, steering clear of creating yet another data island. To enhance straight-through processing (STP) and analytics for both cross-border and domestic payments, aim to align with CPMI's standardized ISO 20022 data needs by the end of 2027. Make sure to incorporate consistent canonical data in your CBDC gateway and payments hub, rather than juggling two separate schemas. (bis.org)

Quick Wins

• Let’s standardize how we identify payers and beneficiaries (using LEI when it makes sense), along with setting some consistent purpose codes and structured addresses for CBDC, ACH, RTP, and cards.
• We can boost our AML efforts by feeding enriched ISO data into the system to minimize false positives and make investigations quicker.

---

Case snapshots: what live pilots teach integrators

• India (e₹ retail)
  • Scale: We're seeing 17 banks on board, over 6 million users, and a whopping ₹1,016 crore in circulation expected by March 2025. They’re also ramping up offline capabilities and programmability features, and now non-bank fintechs are getting in on the action as wallet distributors.
  • Integration lesson: It’s all about tapping into UPI QR acceptance and the existing merchant infrastructure to keep things smooth at the point of sale. Plus, it’s smart to highlight programmability use cases like targeted Direct Benefit Transfers (DBT) and employee allowances to really drive interest. (economictimes.indiatimes.com)
• The Bahamas (Sand Dollar)
  • Integration: They’ve linked up with ACH, and banks have spruced up their online banking to allow easy top-ups into local wallets. Plus, there's a cool CBDC-card bridge through Mastercard prepaid, which means users can spend their converted CBDC anywhere it’s accepted globally. Regulators are also indicating that banks will have to distribute the CBDC.
  • Integration lesson: Connecting ACH and card bridges really boosts utility; when banks are required to distribute, it changes how quickly people adopt the currency--so it’s smart to plan those core changes early. (centralbankbahamas.com)
• Jamaica (JAM‑DEX)
  • Integration: There are three licensed bank wallet providers now in the mix, and the central bank has even tested a dynamic QR system that lets merchants accept JAM‑DEX through regular POS systems. This is a solid move to ease any hesitations merchants might have about juggling multiple devices.
  • Integration lesson: Making sure your existing POS systems can handle CBDC transactions is a must--it's all about expanding your POS software stack to include different payment types, rather than relying on separate terminals. (jamaicaobserver.com)
• China (e‑CNY)
  • Scale: Cumulative transactions have hit a whopping 14.2 trillion yuan, with hundreds of millions of wallets in play. To make things even cooler, they've got hardware “visual” cards and SIM-based wallets that let you use the service offline, though they do enforce strict limits for each device.
  • Integration lesson: Getting ready for a variety of offline device types is key--it helps bridge inclusion gaps and boosts resilience in transit and disaster situations. (china.org.cn)

---

Security stack: what regulators will look for

• Cryptography and custody
  • We use FIPS 140‑3 validated HSMs to keep your key material secure. This involves split-knowledge operations, automated key rotation, and making sure customer keys are kept separate from system keys.
  • For attestation, we implement hardware-backed device binding and restrict spending on devices that don't pass the attestation check. Check out more details here: (csrc.nist.gov)
• Fraud and AML
  • Use behavioral analytics on your CBDC wallet flows and make sure your anomaly models are fine-tuned for those offline re‑sync spikes.
  • Stay in line with FATF standards when you’re dealing with VASPs or cross‑border flows; don’t forget to implement secure Travel Rule messaging wherever it’s needed. (fatf-gafi.org)
• Privacy
  • Stick to the intermediated privacy model: the central bank gets to see token/ledger events, but not the identities behind them; supervised intermediaries are the ones who hold personally identifiable information (PII) and ensure they’re following data protection laws. UK authorities reinforced this stance in their feedback on the digital pound design. (bankofengland.co.uk)

---

Deliverable architecture: reference components

• CBDC gateway: We're all about that REST/gRPC life, using OAuth 2.1 along with mTLS, and we're totally FAPI-aligned. Plus, we stick to consented data minimization policies to keep things neat and tidy.
• Wallet ledger: Think of this as an event-sourced micro-ledger that has an append-only log. It’s built to handle compensating transactions and keeps a clear and immutable audit trail.
• Payment hub adapter: This little gem maps CBDC payment intentions to ISO 20022 pacs messages and is great at sending out confirmations and handling exceptions.
• AML/sanctions adapter: We use Kafka topics to enrich transaction events, plus we’ve got hooks for creating SAR cases when needed.
• Offline service: This part issues, rotates, and validates offline value bundles. It keeps track of counters and epoch keys based on device class, and we even have forensic replay tools to back us up.
• Reconciliation engine: It seamlessly merges online and offline data, applying conflict resolution rules and generating auditor-visible reports to keep everything transparent.

---

Example: mapping ISO 20022 to your CBDC payment API

// POST /payments/authorize (excerpt)
{
  "paymentId": "CBDC-2025-12-08-000452",
  "debtor": {
    "walletId": "WLT-8842",
    "name": "Acme Retail Checking",
    "lei": "5493001KJTIIGC8Y1R12"
  },
  "creditor": {
    "walletId": "WLT-9921",
    "name": "BlueBird Cafe",
    "merchantId": "MCH-33601"
  },
  "instructedAmount": {"currency": "CBDC", "value": "23.40"},
  "remittanceInformation": {
    "structured": {
      "ustrd": "INV-33812",
      "purpose": "GDDS"
    }
  },
  "context": {
    "channel": "POS",
    "presentment": "QR_DYNAMIC",
    "deviceClass": "HARD_CARD"
  }
}

Make sure your adapter fills in purpose codes, structured remittance details, and IDs. This will help you get the most out of your STP and AML models, just like CPMI’s ISO 20022 data guidance suggests. Check it out here: (bis.org).

---

A pragmatic 90‑day plan to de‑risk your first integration

• Weeks 1-2
  • Set up a CBDC sandbox featuring a Rosalind-style API façade; incorporate IdP and KYC VC issuance; establish tiered limits for online and offline use. (bis.org)
• Weeks 3-6
  • Create flows for topping up and redeeming ACH/RTP; chart out the ISO 20022 fields; kick off AML streaming; connect HSMs for key custody. Check out the patterns from the Bahamas and Nigeria for account aliasing. (centralbankbahamas.com)
• Weeks 7-9
  • Start testing out merchant acceptance with dynamic QR codes on the current POS systems; check in daily to make sure everything’s running smoothly; adjust limits and risk rules as needed. Jamaica has a solid model for acceptance that we can look to for guidance. (jamaicaobserver.com)
• Weeks 10-12
  • Kick off the offline device pilot, starting with just one device class. Dive into that reconciliation and dispute process as laid out in the Polaris handbook. Also, make sure to run a failover test between two sites. (bis.org)

KPIs to Keep an Eye On

• Time to first transaction after onboarding
• Success rate for top-ups
• 99th percentile end-to-end latency
• Offline reconciliation success rate
• Rate of AML false positives
• Merchant acceptance growth (POS penetration)

---

Cross‑border foresight (don’t bolt this on later)

If you're thinking about cross-border retail flows in your market, it's time to start designing for some interlinking. Take a look at BIS's “Project Icebreaker,” which introduces a hub-and-spoke model. In this setup, each domestic CBDC stays within its own borders while FX quotes compete at a central hub, automatically selecting the best route.

This architecture is built with 24/7 availability in mind, aims for HTLC-like atomicity, and clarifies AML roles. So, make sure your CBDC gateway is already equipped to handle multi-currency quoting, onboard FX providers, and manage traceable message choreography. Check out more about it on bis.org.

---

What the emerging rulebooks imply for banks

• Minimum UX and latency: The ECB’s RDG drafts come with non-functional requirements like availability, latency, and maintenance windows, along with some basic UX standards. Make sure to integrate these into your SLOs right away.
• Holding caps and offline caps: Get ready for some limits (the offline ones will be stricter) to help keep deposit flight and fraud in check. Don’t forget to factor in wallet “sweep-back” rules when you're building your liquidity engine. Check it out here: (ecb.europa.eu)

---

Build vs. buy: decision criteria we use with clients

• It's probably not a good idea to rebuild a central bank ledger. Instead, you might want to concentrate on:
  • A solid CBDC gateway, wallet ledger, and payment-hub adapters;
  • Orchestrating devices and offline operations;
  • Tools for data management, AML, and overall operations.
• Tech to check out:
  • The OpenCBDC codebase from Project Hamilton can serve as a performance testbed and help you understand resilience patterns, even if you're not planning to actually run the central bank ledger. You can find more about it here.
• Vendor ecosystem:
  • Make sure our main vendors, like Temenos, can handle deposit updates seamlessly alongside wallet transfers. They should also offer up-to-date, event-driven APIs. A few of them have already shown off their CBDC integrations using DLT stacks. Check it out here: (temenos.com)

---

The 7Block Labs view

Integrating CBDCs isn’t just about “blockchain” -- it’s really all about having a solid payment architecture in place. We’re talking clean APIs, staying on top of ISO 20022 standards, strict AML practices, and making sure we have offline resilience.

So, where to begin? Start with something manageable and testable. Focus on things like KYC VC issuance, converting deposits to wallets, accepting dynamic QR codes at POS, and having one type of offline device. Once you prove that it’s reliable, you can then think about scaling it up.

If you're interested, we can customize this blueprint to fit your specific core system (whether it's Temenos, Finacle, FIS, Fiserv, Mambu, or something homegrown) and kick off a 90-day CBDC readiness sprint with your risk, payments, and infrastructure teams.

---

Sources (selected)

• The BIS/BoE's Project Rosalind is all about creating an API layer for retail CBDC, featuring 33 different endpoints and some insights on offline/UX experiences. Check it out here.
• Moving on to BIS Project Polaris, they’re putting together handbooks and design guides for offline CBDCs. You can learn more about it here.
• The ECB is making strides with its digital euro preparations and they’ve made some progress on the scheme rulebook, along with a pilot timeline that’s worth a look. Dive into the details here.
• Over in India, the e₹ pilots are gaining traction with a focus on scale, programmability, and offline use, plus they’re including non-bank wallets too. More info can be found here.
• The Bahamas is integrating the Sand Dollar with ACH, which includes a mandate for bank distribution and a bridging solution for card transactions. Get the scoop here.
• Jamaica’s working hard on the JAM‑DEX with their dynamic QR rollout efforts for POS systems. You can read more about their progress here.
• In China, e‑CNY is expanding with some cool innovations like visual cards and SIM-based wallets for offline transactions. Get the details here.
• There's also some movement on ISO 20022 harmonization with CPMI and BoE aligning their efforts. More info is available here.
• Finally, Project Hamilton/OpenCBDC has released its performance and resilience results, which you can check out here.

---

Description

This guide is your go-to resource for banks and fintechs looking to integrate retail CBDC wallets with existing core systems. We're diving into practical API designs, essential ISO 20022 data recipes, offline risk controls, and sharing insights from real-life pilots like e₹, Sand Dollar, JAM‑DEX, and e‑CNY.