CBDC consultancy: Integrating Retail CBDC Wallets with Existing Core Banking

Decision-makers’ summary: Retail CBDCs are moving from whitepapers to production pilots. This guide explains, in concrete technical detail, how to integrate a retail CBDC wallet stack with your bank’s core systems, drawing on the latest central bank API patterns, offline payment guidance, ISO 20022 data practices, and live pilots from India, the Bahamas, Jamaica, and China. (bis.org)

Why this matters now

The Eurosystem is drafting a unified “digital euro scheme rulebook” and expects early piloting from mid‑2027, with issuance readiness targeted for 2029—meaning banks and PSPs must begin core changes well before legal go‑ahead. (ecb.europa.eu)
Real‑world retail CBDC pilots are scaling: India’s e₹ reached 17 banks, 6+ million users and ₹1,016 crore in circulation by March 2025, while non‑bank wallet providers (e.g., CRED, MobiKwik) were admitted to the pilot. (economictimes.indiatimes.com)
Adoption lessons are emerging: the Bahamas has integrated Sand Dollar with the national ACH and is preparing to require commercial banks to distribute it; Jamaica is enabling CBDC on standard POS via dynamic QR; China reports cumulative e‑CNY transactions in the trillions of yuan. (centralbankbahamas.com)

This post distills the latest integration patterns 7Block Labs uses on CBDC programs to help banks extend their existing cores—not replace them.

The target state in one picture

A two‑tier retail CBDC model keeps the central bank ledger minimal while letting supervised intermediaries (banks/PSPs) run wallet UX, onboarding, screening, and value‑added services. An API layer formally bridges both tiers. BIS/BoE “Project Rosalind” proved this with 33 standardized endpoints across six functional families and >30 use cases, including offline and device‑based payments. Your bank’s challenge is to map those functions into your payment hub, GL, risk stack, and data governance. (bis.org)

Core concepts (fast)

Two‑tier issuance: central bank issues CBDC; intermediaries distribute and service it. Keep the CB ledger simple; push programmability and UX to banks. (bis.org)
Wallets ≠ deposit accounts: CBDC balances are central‑bank liabilities; deposits are commercial‑bank liabilities. Your integration needs clean, reversible conversion paths.
ISO 20022 everywhere: harmonized usage is maturing by 2027—design your CBDC adapters to ingest/emit clean ISO 20022 data across payment rails and CBDC APIs. (bis.org)
Offline is real: resilience requirements mean value‑limited offline payments via secure elements, smartcards, or SIM‑based wallets—plan for limits, reconciliation, and fraud controls from day one. (bis.org)

Integration blueprint: bank systems that must change

Identity, onboarding, and limits

Reuse KYC: issue a verifiable credential at KYC completion so customers can open interoperable CBDC wallets instantly (with tiered limits) across channels. W3C Verifiable Credentials 2.0 became a W3C Standard in 2025—use it to share KYC assertions across wallet providers. (w3.org)
Tiering policy: mirror tiered wallets (e.g., basic vs. fully verified) with per‑txn and balance caps; set stricter offline limits (see ECB drafts and BIS Polaris). (ecb.europa.eu)

Wallet lifecycle and device security

Bind wallets to secure hardware (secure element, TEE, smartcard, or SIM). Enforce device attestation and risk scores on login and spend.
Keys and HSMs: manage master keys, tokenization keys, and offline one‑time counters in FIPS 140‑3 validated HSMs; plan for 140‑2 end‑of‑life migrations before 2026 historical listing. (csrc.nist.gov)

Account ↔ wallet conversion

Domestic on/off‑ramps: implement ACH/instant payment adapters for “Deposit → CBDC wallet” and “Wallet → Deposit.” The Bahamas completed ACH integration so bank customers can top up Sand Dollar from their online banking; Nigeria’s eNaira maps each wallet to a NUBAN ID and routes via NIBSS Instant Payments. Your bank should implement aliasing tables that link wallet IDs to bank accounts for straight‑through conversion. (centralbankbahamas.com)

Payments and messaging

Embrace ISO 20022 fields (payer/beneficiary, purpose, structured address, LEI) for screening, reconciliation, and analytics; align with CPMI’s 12 harmonized data requirements. Map CBDC payment requests to pacs.008/pacs.002 equivalents in your hub. (bis.org)
Real‑time ledger posting: CBDC payments should hit the wallet ledger in sub‑second times; your core can mirror this via event‑sourced booking and near real‑time GL posting.

Risk, AML/CFT, and data

Apply your normal AML/BSA/OFAC stack to CBDC inflows/outflows, plus transaction monitoring on CBDC wallet transfers. For cross‑border or VASP interfaces, align with FATF’s latest virtual asset standards and Travel Rule expectations at the perimeter (where applicable). (fatf-gafi.org)
Data minimization and privacy: design your APIs to enforce the CBDC privacy model (e.g., intermediated model where the central bank never sees personal data, as emphasized in the UK digital pound response). (bankofengland.co.uk)

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

Project Rosalind validated a neutral API layer that sits between the central bank ledger and private‑sector apps. Translate those lessons into a bank‑facing API gateway that fronts your wallet services and insulates the core. Examples:

Identity and onboarding
- POST /wallets: create wallet for a KYC’d customer using a verifiable credential reference; set tier, limits, and device bindings.
- POST /consents: capture explicit customer consent for data sharing, analytics, and offline capability enrollment.
Liquidity and conversion
- POST /wallets/{id}/topup: pull funds from a linked deposit via ACH/RTP; embed ISO 20022 elements (amount, purpose, remittance).
- POST /wallets/{id}/redeem: push funds back to deposit with pacs.008 mapping and same‑day availability.
Payments
- POST /payments/authorize: reserve balance; support merchant presentment via QR/NFC and offline fallbacks.
- POST /payments/capture and DELETE /payments/{id}: finalize or void.
- POST /payments/offline/reconcile: submit signed offline bundles with counters and risk labels.
Compliance and telemetry
- POST /reports/aml: send enriched ISO 20022‑structured events to your AML engine.
- GET /wallets/{id}/limits: dynamic limits factoring online/offline, risk tier, and ECB‑style holding caps. (bis.org)

Implementation notes

Use an event bus (Kafka/Pulsar) to broadcast CBDC wallet events to GL, CRM, AML, and analytics.
Apply idempotency keys, replay protection, and high‑watermark cursors for offline bundle ingestion.
Tie API privacy enforcement to the CBDC scheme’s rulebook (user experience minimums, latency, dispute workflows), which the ECB’s RDG is codifying. (ecb.europa.eu)

Throughput, latency, and resilience targets you can defend internally

Fed/MIT’s Project Hamilton showed two architectures: an ordered, block‑based design completing >99% of transactions under 2 seconds at ~170k TPS, and a parallel, unordered design demonstrating ~1.7M TPS with 99% under 1 second. You won’t replicate that end‑to‑end inside a bank, but it sets a ceiling for your wallet/core adapters—plan for p99 <500 ms on your API gateway, end‑to‑end p99 <1.5 s for domestic retail payments, and zero‑data‑loss failover across two datacenters. (bostonfed.org)

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 objectives baked into runbooks.

Offline: what “good” looks like in production

BIS “Project Polaris” provides handbooks and design guides for offline CBDC. Boil it down to three mandates: constrained value, secure hardware, and verifiable reconciliation. (bis.org)

Device classes:
- SE‑backed smartphones (NFC) with offline counters;
- hardware cards with e‑ink displays (balance, dynamic QR);
- SIM‑based hard wallets for powered‑down scenarios. China’s e‑CNY ecosystem has piloted all three. Design your wallet server to recognize device class at risk time. (digitalpoundfoundation.com)
Limits and policy:
- Daily offline cap significantly below online cap; stricter for anonymous/low‑KYC tiers; enforce expiry of offline value blobs.
- Treat dual‑offline (both parties offline) as provisional until reconciliation; version your conflict rules to minimize false positives. (bis.org)
Recovery and forensics:
- Store cryptographic receipts per spend; run background graph analytics for double‑spend patterns.
- On fraud suspicion, degrade device limit class remotely on next connect.

Data and standards: make ISO 20022 work for you

By design, CBDC adds new message types and an API surface—not another proprietary data island. Align with CPMI’s harmonized ISO 20022 data requirements by end‑2027 to boost STP and analytics across cross‑border and domestic rails. Embed the same canonical data in your CBDC gateway and payments hub, not two different schemas. (bis.org)

Quick wins

Normalize payer/beneficiary identification (LEI where applicable), purpose codes, and structured addresses across CBDC, ACH, RTP, and cards.
Pipe enriched ISO data into AML to reduce false positives and speed investigations.

Case snapshots: what live pilots teach integrators

India (e₹ retail)
- Scale: 17 banks, 6+ million users, ₹1,016 crore in circulation by March 2025; expanding offline and programmability features; non‑bank fintechs joining as wallet distributors.
- Integration lesson: leverage UPI QR acceptance and existing merchant rails to minimize POS friction; focus on programmability use cases (targeted DBT, employee allowances) to create pull factors. (economictimes.indiatimes.com)
The Bahamas (Sand Dollar)
- Integration: ACH linkage completed; banks upgraded online banking for top‑ups into native wallets; CBDC–card bridge via Mastercard prepaid lets users spend converted CBDC on global acceptance rails; regulators signaling banks will be required to distribute the CBDC.
- Integration lesson: ACH and card bridges materially increase utility; bank distribution mandates change adoption curves—plan core changes early. (centralbankbahamas.com)
Jamaica (JAM‑DEX)
- Integration: three bank wallet providers licensed; central bank piloted dynamic QR to accept JAM‑DEX on standard POS, tackling merchant reluctance to run parallel devices.
- Integration lesson: acceptance at existing POS is non‑negotiable—extend your POS software stack for CBDC tender types, not separate terminals. (jamaicaobserver.com)
China (e‑CNY)
- Scale: cumulative transactions reached 14.2 trillion yuan with hundreds of millions of wallets; hardware “visual” cards and SIM‑based wallets extend offline reach, with strict per‑device limits.
- Integration lesson: preparing for multiple offline device classes reduces inclusion gaps and adds resilience for transit and disaster scenarios. (china.org.cn)

Security stack: what regulators will look for

Cryptography and custody
- FIPS 140‑3 validated HSMs for key material; split‑knowledge operations; automated rotation; customer keys isolated from system keys.
- Attestation: hardware‑backed device binding; block spending on devices failing attestation. (csrc.nist.gov)
Fraud and AML
- Behavioral analytics on CBDC wallet flows; anomaly models tuned for offline re‑sync spikes.
- Align with FATF standards at your perimeter when interacting with VASPs or cross‑border flows; implement secure Travel Rule messaging where applicable. (fatf-gafi.org)
Privacy
- Follow the intermediated privacy model: the central bank sees token/ledger events, not identities; supervised intermediaries hold PII and comply with data protection law. UK authorities reaffirm this approach in their digital pound design feedback. (bankofengland.co.uk)

Deliverable architecture: reference components

CBDC gateway: REST/gRPC, OAuth 2.1 + mTLS, FAPI‑aligned; supports consented data minimization policies.
Wallet ledger: event‑sourced micro‑ledger with append‑only log; supports compensating transactions and immutable audit trail.
Payment hub adapter: maps CBDC payment intents to ISO 20022 pacs messages; emits confirmations and exceptions.
AML/sanctions adapter: Kafka topics for enriched transaction events; SAR case creation hooks.
Offline service: issues, rotates, and validates offline value bundles; counters and epoch keys stored per device class; forensic replay tools.
Reconciliation engine: merges online/offline; conflict resolution rules with auditor‑visible reports.

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"
  }
}

Your adapter should populate purpose codes, structured remittance, and IDs to maximize STP and AML model effectiveness (per CPMI’s harmonized ISO 20022 data guidance). (bis.org)

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

Weeks 1–2
- Stand up a CBDC sandbox with a Rosalind‑style API façade; integrate IdP and KYC VC issuance; define tiered limits (online/offline). (bis.org)
Weeks 3–6
- Build ACH/RTP top‑up/redeem flows; map ISO 20022 fields; enable AML streaming; wire HSMs for key custody. Use Bahamas/Nigeria patterns as reference for account aliasing. (centralbankbahamas.com)
Weeks 7–9
- Pilot merchant acceptance with dynamic QR on existing POS; reconcile daily; tune limits and risk rules. Jamaica’s approach is a good acceptance template. (jamaicaobserver.com)
Weeks 10–12
- Run offline device pilot (one device class first); exercise reconciliation and dispute flows per Polaris handbook; conduct failover test across two sites. (bis.org)

KPIs to track

Time‑to‑first‑transaction post‑onboarding; top‑up success rate; p99 end‑to‑end latency; offline reconciliation success; AML false positive rate; merchant acceptance growth (POS penetration).

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

If your market contemplates cross‑border retail flows, design for interlinking now. BIS “Project Icebreaker” shows a hub‑and‑spoke model where each domestic CBDC stays onshore, with FX quotes competing in a hub and the best path auto‑selected. That architecture expects 24/7 availability, HTLC‑like atomicity, and clear AML roles—your CBDC gateway should already support multi‑currency quoting, FX provider onboarding, and traceable message choreography. (bis.org)

What the emerging rulebooks imply for banks

Minimum UX and latency: the ECB’s RDG drafts include non‑functional requirements (availability, latency, maintenance windows) and minimum UX standards—bake these into SLOs now.
Holding caps and offline caps: expect limits (stricter offline) to reduce deposit flight and fraud. Model wallet “sweep‑back” rules into your liquidity engine. (ecb.europa.eu)

Build vs. buy: decision criteria we use with clients

You likely shouldn’t rebuild a central bank ledger. Focus on:
- A robust CBDC gateway, wallet ledger, and payment‑hub adapters;
- Device/offline orchestration;
- Data, AML, and operational tooling.
Open tech to consider:
- OpenCBDC codebase from Project Hamilton as a performance testbed and to inform resilience patterns—even if you won’t run the CB ledger itself. (bostonfed.org)
Vendor ecosystem:
- Ensure core vendors (e.g., Temenos) can orchestrate deposit updates atomically with wallet transfers and expose modern, event‑driven APIs; several have demonstrated CBDC integrations with DLT stacks. (temenos.com)

The 7Block Labs view

CBDC integration is less about “blockchain” and more about disciplined payment architecture: clean APIs, ISO 20022 hygiene, tight AML, and offline resilience. Start with a thin, testable slice: KYC VC issuance, deposit↔wallet conversion, dynamic‑QR POS acceptance, and one offline device class. Prove reliability, then scale.

If you’d like, we’ll map this blueprint to your exact core (Temenos, Finacle, FIS, Fiserv, Mambu, homegrown) and run a 90‑day CBDC readiness sprint with your risk, payments, and infrastructure teams.

Sources (selected)

BIS/BoE Project Rosalind API layer for retail CBDC; 33 endpoints; offline/UX learnings. (bis.org)
BIS Project Polaris: offline CBDC handbooks and design guides. (bis.org)
ECB digital euro preparation and scheme rulebook progress; pilot timeline context. (ecb.europa.eu)
India e₹ pilots (scale, programmability, offline; inclusion of non‑bank wallets). (economictimes.indiatimes.com)
Bahamas Sand Dollar ACH integration; bank distribution mandate trajectory; card bridge. (centralbankbahamas.com)
Jamaica JAM‑DEX POS dynamic QR rollout efforts. (jamaicaobserver.com)
e‑CNY scale and offline device innovation (visual cards, SIM‑based wallets). (china.org.cn)
ISO 20022 harmonization (CPMI; BoE alignment). (bis.org)
Project Hamilton/OpenCBDC performance and resilience results. (bostonfed.org)

Description: An expert, hands‑on guide for banks and fintechs: how to integrate retail CBDC wallets with today’s cores, with concrete API designs, ISO 20022 data recipes, offline risk controls, and lessons from live pilots (e₹, Sand Dollar, JAM‑DEX, e‑CNY).