Gateway capabilities
- Core-synchronised token
- Balance policy
- Reconciliation evidence
Funds & Assets · Design record
Tokenized deposits
Extend a regulated deposit liability into programmable workflows while preserving the bank core as final authority.
01Issuing bank→
02Depositor→
03Core ledger→
04Wallet or custody layer
Target business outcome
Programmable bank money that interoperates with digital-asset workflows without creating an uncontrolled parallel ledger.
Gateway implementation layer
Translate the workflow into a deployable operating boundary.
The record defines the financial problem. Gateway then maps the relevant Platform capabilities, privacy fit, deployment, specialist dependencies, and validation path.
Open Privacy Suite applicability
Shields customer balances while the bank retains full visibility of its book.
Deployment
Token ledger synchronised with core banking; core stays the system of record.
Partner dependencies
- Core banking
- Identity
- Payment scheme
Implementation path01 · Map the flow02 · Validate the hardest assumption03 · Define the production boundary
Actors
- Issuing bank
- Depositor
- Core ledger
- Wallet or custody layer
- Compliance function
- Counterparty bank
- Supervisor
Confidential data
- Account ownership
- Deposit balances
- Transaction purpose
- Core-ledger postings
- Risk and compliance decisions
Public or shared evidence
- Token or claim state
- Core-ledger reconciliation reference
- Policy receipt
- Settlement finality
Regulator and auditor access
Bank control functions and supervisors access reconciled evidence through governed roles; counterparties see only required settlement claims.
Institutional constraints
- Core-ledger authority and reconciliation must be unambiguous
- Deposit protection and balance-sheet treatment are jurisdiction-specific
- Wallet recovery and account controls must match bank policy
- Interbank use changes the operating model
Viable approaches
Core-synchronised token
Treat the onchain representation as a controlled extension of the authoritative bank balance.
Closed institutional network
Operate deposit tokens within an approved participant domain.
Questions to resolve during discovery
- Is the token the legal record or a synchronized representation?
- How quickly must core and token state reconcile?
- Who can create, suspend, or recover a wallet?
- What happens during ledger or network unavailability?
Relevant standards and frameworks
- Bank accounting and deposit regulation
- ISO 20022
- Operational-resilience policy
- Identity and access management policy
Related cases
Continue through the adjacent operating questions.
Financial workflows rarely stand alone. These records cover the closest dependencies and alternatives.
PaymentsDesign record
Institutional stablecoin payments
Design digital cash issuance or integration under a defined brand, reserve, distribution, and transaction-policy model.
Open use-case record →TradingDesign record
Private DvP and secondary markets
Coordinate asset transfer and cash settlement while limiting exposure of intent, price, position, and counterparty data.
Open use-case record →Data & OraclesDesign record
Evidence and audit rails
Produce a durable chain of identity, policy, transaction, deployment, and operational evidence for assurance and supervision.
Open use-case record →Start with the architecture
Turn tokenized deposits into an institution-specific architecture.
A workshop maps the actors, authoritative records, disclosure requirements, operating boundary, and highest-risk assumptions into a proposed architecture.