A sovereign CBDC that cannot touch the existing financial plumbing is an island. The engine integrates with RTGS, instant-payment systems, and card networks as a peer, so value moves between the new ledger and the rails a nation already runs.
Reserve money and CBDC are two representations of the same central-bank liability, and the integration keeps them reconciled.
Issuance and redemption of CBDC are tied to corresponding movements in the RTGS account structure, so the outstanding CBDC stock always maps to a defined central-bank position. The two ledgers are reconciled, not run on faith.
Participants can move value between their RTGS reserves and CBDC holdings through controlled issuance and redemption. This lets a bank fund CBDC activity from existing reserves without holding trapped liquidity in a parallel system.
A movement across the boundary is conditioned so that the RTGS leg and the CBDC leg either both complete or both fail. There is no window where value has left one ledger but not arrived on the other.
The hash-chained CBDC ledger produces a settlement position that reconciles against RTGS balances at cut-off, giving operations a tamper-evident record to close the day against.
The engine speaks to national fast-payment schemes so users move between bank money and CBDC without a separate rail.
The CBDC engine connects to instant-payment schemes at the participant layer, presenting as an addressable endpoint that can send and receive within the scheme's clearing and settlement model.
Where a jurisdiction runs proxy addressing — phone numbers, national IDs, or account aliases — the CBDC integration can resolve against the same directory, so users are not forced to learn a second addressing scheme.
The CBDC ledger operates continuously, matching the always-on expectation of instant-payment rails rather than reintroducing batch windows at the boundary between the two.
The integration supports both settling each instant payment individually against CBDC and netting scheme obligations for periodic settlement, letting the operator match the existing scheme's economics.
Existing merchant acceptance and cardholder devices become points of presence for CBDC without re-terminaling the country.
CBDC transactions can be routed through existing card acceptance infrastructure at the acquiring edge, so merchants who already take cards can receive CBDC without new hardware in the common case.
The engine maps CBDC authorization and settlement onto the network's authorize-then-clear model, translating between the card message flow and the atomic ledger commit underneath.
Because CBDC settlement is final on-ledger, integration makes the reversibility model explicit: disputes are handled at the scheme layer with defined off-ledger remedies rather than by silently reversing a committed transfer.
The architecture is designed to support constrained and intermittently connected acceptance, so card-style tap interactions can be reconciled to the ledger when connectivity is available.
Connecting to legacy systems must not dilute the CBDC's security or residency guarantees.
Each crossing between the CBDC ledger and an external rail generates a signed, hash-chained event. The exact value that entered or left through each rail is reconstructable and tamper-evident.
Integration adapters run inside the national data residency perimeter. Traffic to external rails leaves through defined, monitored interfaces rather than exposing the core ledger.
An outage or corruption in an external rail cannot corrupt CBDC state; boundary transfers are atomic, so a failed integration leg leaves the ledger in a consistent, well-defined position.
Value crossing any boundary is authorized under the same ML-DSA-65 signing discipline as native CBDC operations, so the security floor does not drop at the edge where legacy systems attach.