What a bank needs to see before a pilot goes live
Rado Patus, Protofire
Moment at 14:25Episode 5 · TradFi Goes Onchain, Part 2: From Pilots to Market Infrastructure
Tokenized Deposits Platform for Banks
In short
Protofire builds tokenized deposits platforms for banks. The bank issues a deposit token to its own clients. Each token is minted against a debit on the core ledger and burned against a credit, and supply is reconciled every day. We build the platform end to end and can run it after launch. The bank stays the issuer and holds the keys.
Reviewed by Luis Medeiros, Field CTO at ProtofireLast reviewed: October 2026
250+
projects shipped since 2016
$2B+
secured on the Safe deployments we built across 120+ EVM networks
1M+
developers use Solhint, which we maintain
Core
contributor to Chainlink
Trusted by teams building on-chain
Tokenized deposits put a bank's own deposit liability on a ledger. A client's balance becomes a token that moves between accounts at any hour and settles against tokenized assets, while it stays a deposit under existing banking law. The engineering sits mostly outside the token contract, in the link to the core banking ledger: a mint only against a debit, a burn only against a credit, a reconciliation every day, and a defined answer for what the token does at night and on weekends when the core is closed.
Protofire builds a tokenized deposits platform around that link, from the token contract to the monitoring, and can run it after launch under runbooks the bank approves. Issuance, the client relationship and the keys stay with the bank.
The tokenized deposits stack, from core ledger to chain
The stack runs from the core banking system, which stays the system of record, to the monitoring that watches the token around the clock.
01
Core banking and treasury
The system of record. Every mint debits a client or mirror account, every burn credits it, and positions reconcile against the ledger every day.
02
Mint and burn orchestration
The service between core and chain: idempotent mint and burn requests (a retried request can never mint twice), limits per client and per window, and defined behavior while the core is closed.
03
Deposit token contract
A permissioned token, either an allowlisted ERC-20 or an ERC-3643 token with identity checks, with pause, supply cap, role-separated mint and burn, and forced transfer for legal orders.
04
Custody and key governance
HSM or MPC custody for issuer keys, Safe multisig for admin roles, time locks on sensitive changes, and a signing policy the bank's risk owners approve.
05
Compliance hooks
KYC status driving the allowlist, sanctions screening on every address, Travel Rule data where the transfer requires it, and audit evidence in the regulator's format.
06
Interoperability
Chainlink CCIP for cross-chain messages, ISO 20022 and Swift connectivity, shared bank ledgers, and delivery-versus-payment against tokenized assets.
07
Monitoring and operations
24/7 monitoring of supply against the core ledger, reconciliation breaks, key use and contract events, with runbooks and on-call response.
01
How a deposit token moves
1
Client instruction
A client asks to convert part of its balance into tokens, through the bank's own channels or an ISO 20022 or Swift message. The orchestration service checks the client's KYC status, allowlisted address and limits before anything moves.
2
Debit on the core
The core banking system debits the client's account, or moves the balance to a mirror account, and the service records the request as in flight. A request that arrives while the core is closed follows the cut-off rule agreed in design.
3
Mint to the client
The service mints the same amount to the client's allowlisted address, signed by an issuer key in HSM or MPC custody. The request is idempotent, so a retry can never mint twice.
4
Transfer or settlement
The holder pays another allowlisted client, or settles against a tokenized asset, at any hour. The contract checks that both addresses are approved, and sanctions screening runs on the counterparty.
5
Burn and credit
When the holder redeems, the service burns the tokens and credits the account in the core banking system. Both sides are tracked until each one confirms.
6
Daily reconciliation
Every day, token supply and balances are compared with the core ledger. Each break goes to a named owner in operations and is resolved under the bank's runbook.
02
What we build into a tokenized deposits platform
We write the deposit token in one of two permissioning models, chosen for your counsel's classification and for who will hold it. An allowlisted ERC-20 checks that both sender and recipient are approved addresses; it is the pattern J.P. Morgan's JPMD uses on Base, as the verified source of its implementation contract shows, and it keeps the interface simple and under the bank's control. ERC-3643 ties eligibility to an onchain identity with verifiable claims (KYC status, jurisdiction, client type) and modular compliance rules, which suits a token that may reach other banks' clients or carry jurisdiction limits.
Either way the contract carries the controls a bank needs: pause, a supply cap, role-separated mint and burn, forced transfer for legal orders, time-locked allowlist additions and an upgrade path an auditor can follow. Keeping every holder a known client also supports the deposit classification in the EU, where a bearer-like token that moves beyond the bank's clients risks classification as an e-money token.
We build the orchestration service that sits between the core and the chain, with idempotent requests, per-client and per-window limits, and a recorded state for every request in flight. Every token in circulation should match a debit on the core ledger, every burn a credit, and the two should reconcile every day, including failed transactions and those a chain reorganization reverses.
Where the core closes and the chain does not, we design the cut-off behavior explicitly; J.P. Morgan, for example, publishes a three-hour Saturday downtime (3 to 6 p.m. EST) for moving funds between legacy accounts and its blockchain deposit accounts.
The issuer keys are the most sensitive part of the system. We put mint, burn and admin roles behind HSM or MPC custody, including Fireblocks where the bank already uses it, Safe multisig for administrative roles that need several approvers, and time locks on changes that alter who can hold or move the token. The signing policy is written with the bank's risk owners: who can move what, when, in what amounts, and what happens when a signer leaves.
We wire the token into the bank's existing compliance stack instead of adding a parallel one. KYC status drives the allowlist, so an offboarded client can no longer receive tokens; sanctions screening runs on every counterparty address; and where a transfer requires it, originator and beneficiary data travel with the payment.
In the EU, the European Banking Authority reads a payment from an onchain deposit account as a transfer of funds under the recast Transfer of Funds Regulation, while noting that the Travel Rule treatment may need clarification. Evidence comes out in the format your regulator already receives from you. Compliance integration covers the KYC, screening and Travel Rule providers we connect.
On its own, a deposit token moves money only among the issuing bank's clients. To reach further we connect it: Chainlink CCIP for cross-chain messages and token movements between networks, ISO 20022 and Swift connectivity so instructions can start in existing payment systems, and integration with shared bank ledgers (Swift's blockchain ledger, the UK's GBTD and Hong Kong's EnsembleTX all ran live pilots in 2026).
For tokenized securities and funds we build the delivery-versus-payment cash leg: atomic when cash and asset sit on the same ledger, and coordinated with escrow and timeouts when they do not. The same rails carry programmable payments: conditional releases, scheduled sweeps and intraday liquidity moves between group entities on any day of the week.
A deposit token never closes, so the monitoring runs around the clock. We track token supply against the core ledger, reconciliation breaks, key use, allowlist changes and contract events, alert on drift, and respond under runbooks agreed with the bank, as part of managed onchain operations.
Supply-against-ledger checks draw on our Proof of Reserve work. For a bank that wants defined threats answered automatically, the onchain threat response blueprint sets out the DORA-aligned pattern of pre-authorized responses.
03
Choosing the rail
The ledger decides who the token can reach and what the bank controls. We build on all three options below and set out the trade-offs in writing before you commit.
01
Public chain, permissioned in the token
The token lives on a public network such as Ethereum or an Ethereum layer 2, and the contract decides who may hold and move it. The bank gains reach and composability with tokenized assets and with other institutions on the same network. It gives up control of transaction ordering, inclusion and fees, and has to handle transfers it did not ask for: tokens sent to its addresses from unknown or sanctioned senders, each of which has to be screened. We design the contract and the monitoring for those cases. The Basel cryptoasset standard also requires the entities that execute transfers and settlement to be regulated and supervised or subject to appropriate risk management standards, a condition that is hard to meet with public validators; the Basel Committee is running a targeted review of the standard and expects an update by the end of 2026.
02
Permissioned ledger, one bank or a consortium
The bank, or a group of banks, runs the validators, so it controls access, upgrades, privacy and finality. Citi, HSBC and DBS run their deposit token programs this way. The cost is reach: money moves only among participants, so paying another bank's client needs an interbank leg or a shared network.
03
Canton Network
Canton is a public network built for regulated institutions with configurable privacy between parties. HSBC ran a simulated tokenized deposit pilot on it in April 2026, and Digital Asset and Kinexys announced plans in January 2026 to issue JPMD natively on Canton. It fits a bank whose counterparties and tokenized assets are already on Canton and that needs privacy between transacting parties. Contracts there are written in Daml rather than Solidity, so EVM tooling and audits do not carry over directly, and connecting to EVM networks needs its own interoperability design. We build on Canton as well as on EVM chains; the Daml, node and EVM-link work is set out on Canton Network development.
04
Deposit token, stablecoin, or both?
A deposit token fits when the holders are your own clients. When they must pay people who bank elsewhere, a stablecoin may fit better, and in the EU a credit institution can issue an e-money token on its banking license. Our guide to tokenized deposits vs stablecoins compares the options.
For e-money token builds, see the issuance, mint controls and licensed-issuer distribution blueprints.
05
How an engagement works
1
Design
We map your counsel's classification onto the token design, trace mint, burn and reconciliation through your core banking system, and agree custody and compliance with your risk owners. Deliverables: a classification-to-design map (permissioning model, rail, who may hold the token); a mint and burn state machine that includes your core's cut-off windows; a reconciliation spec with break categories and an owner for each; a signing policy; the list of compliance evidence your regulator will receive; and a build plan your risk committee can review.
2
Build
We write the contracts, the mint and burn orchestration service, the custody and Safe roles, the compliance hooks and the interoperability layer, and harden every contract with Solhint and internal review before an independent audit. Deliverable: the platform running in a test environment connected to your core.
3
Pilot
A limited run with real value and a small set of the bank's own clients, through at least one month-end close, built to produce what risk owners ask for before production: a reconciled month, compliance evidence in the regulator's format, and at least one counterparty outside the project team. Deliverable: the evidence pack for the production decision.
4
Operate
Production rollout, then optional 24/7 monitoring, incident response and change management, or a clean handover to your team. Deliverable: a live deposit token platform, run by us or by you. We size the work after a first call about your core banking system, the holders you have in mind and the rail. Open questions on classification, core integration or custody are raised in the design phase, while the architecture can still change.
06
What the bank provides
Five roles inside the bank carry the decisions this platform depends on. Rado Patus, Lead Product Manager at Protofire, gave the rule on The Protocol Roundtable: "whoever owns the risks decides, and decides on the evidence they can defend."
- A core banking owner, who approves how mint, burn and reconciliation touch the ledger
- Treasury operations, which set limits and cut-off windows and work reconciliation breaks
- Risk owners, who approve the signing policy and the pilot evidence
- Security, which runs the HSM or MPC custody and reviews key access
- Legal, which signs off the classification the token design rests on
07
What you can launch on it
24/7 treasury moves between group entities, each one an onboarded client
Intraday liquidity transfers, reconciled against the core ledger every day
Client-to-client payments, between holders on your allowlist
DvP cash leg for tokenized bonds and funds, atomic only on the same ledger
Collateral and margin posted onchain, to counterparties that hold your token
Programmable and conditional payments, within limits your risk owners set
Cross-border transfers across your branches, where each market's rules allow
Onchain FX between currency tokens, atomic when both sit on one ledger
Connection to shared bank ledgers, most of them still in pilot
08
An engineering partner for regulated onchain money
A deposit token platform is assembled from layers we build in production: permissioned tokens, including the ERC-3643 identity and compliance layers in our tokenization infrastructure work; Safe multisig key governance; reserve attestation, which we delivered across 15+ deployments for a large auditing firm; and Chainlink interoperability. More on digital asset infrastructure for banks.
“Every token in circulation should match a debit on the core ledger, every burn a credit, and the two should reconcile every day, including failed transactions and those a chain reorganization reverses.”
Production work this platform builds on
15+proof-of-reserve and real-time attestation deployments
We built and operated the reserve-data pipeline behind a large auditing firm's real-time attestation of asset-backed tokens, across 15+ deployments. A deposit token platform runs the same kind of check every day, matching token supply against the core ledger.
Large auditing firm
$2B+secured across 120+ EVM networks
We deployed and maintain Safe multisig across 120+ EVM networks. In the platform we build, Safe holds the deposit token's admin roles.
SafeView project →
Corecontributor, node tooling and External Adapters
We built Chainlink node deployment tooling and dozens of External Adapters across EVM networks. In the platform we build, Chainlink CCIP moves the deposit token between networks.
ChainlinkView project →
A deposit token proof of concept vs a production platform
| Proof of concept | Production platform we build | |
|---|---|---|
| Mint and burn | Scripted, a handful of transactions | Wired to the core ledger, with limits and idempotent requests |
| Reconciliation | Checked by hand after the fact | Automated daily, with breaks raised to operations |
| Keys | One operator key | HSM or MPC custody, Safe multisig admin roles, an approved signing policy |
| Who can hold | A fixed test list | An allowlist driven by KYC status, with sanctions screening |
| Hours | Business hours | 24/7, with defined behavior while the core is closed |
| Evidence | A demo and a report | Compliance evidence in your regulator's format |
| After launch | The project team | 24/7 monitoring and incident response, or a handover |
FAQ
What is a tokenized deposits platform?
A tokenized deposits platform is the system a bank needs to issue its own deposit token and run it in production: the token contract, plus the services that tie it to the core banking ledger, guard the issuer keys, check every holder and watch it around the clock. Live tokenized deposits (tokenised deposits in British spelling) include J.P. Morgan's Kinexys blockchain deposit accounts on a private permissioned ledger and its JPMD deposit token on Base, which only vetted institutional clients can hold; Citi Token Services, live since October 2024 on Citi's private permissioned blockchain; and HSBC's Tokenised Deposit Service, live since May 2025 on HSBC's own ledger. Protofire builds the platform and can operate it; the bank remains the issuer.
Do we need a new license to issue a deposit token?
Generally no: a deposit token is still a deposit, so the bank issues it under its existing banking license in the US, the EU and the UK. The GENIUS Act and MiCA both leave deposits outside their stablecoin and crypto-asset rules, and the UK PRA expects tokenized deposits to stay inside the deposit taker. Classification is still decided case by case, so your counsel's analysis sets the design and your supervisor should hear about the program early; we build to that classification. Our guide to tokenized deposits vs stablecoins sets out the rules market by market.
Should the token be an allowlisted ERC-20 or ERC-3643?
Use an allowlisted ERC-20 when the holders are your own clients and the rules are simple; it is the pattern J.P. Morgan's JPMD uses on Base. Use ERC-3643 when other banks' clients may hold the token or eligibility rules have to travel with it; it can also share one identity layer with the bank's tokenized securities. ERC-7943 offers a minimal standard interface (can send, can receive, freeze, forced transfer) that leaves identity to the issuer. We recommend one in design and build either.
How does the deposit token connect to our core banking system?
Through an orchestration service between the core and the chain. It debits the client's account, or moves the balance to a mirror account, before it mints, and on redemption it burns before it credits; every request is idempotent, limited per client and per window, and tracked until both sides confirm. A daily reconciliation compares token supply with the core ledger and raises breaks for operations. The six-step flow on this page shows the full cycle, and the cut-off rule for hours when the core is closed is agreed in design.
Public chain, permissioned ledger or Canton: which should we use?
Choose the ledger your counterparties and tokenized assets already use. A public chain with permissioning in the token gives reach, but the bank does not control transaction ordering or fees. A permissioned ledger gives the bank full control, and is how Citi, HSBC and DBS run their programs, but money moves only among participants. Canton offers privacy between parties on a public network built for regulated institutions. The rail section above sets out the trade-offs, and we build on all three.
Can a deposit token settle tokenized securities (DvP)?
Yes. When the deposit token and the tokenized security sit on the same ledger, delivery and payment settle in one atomic transaction. When they sit on different ledgers, we build a coordinated settlement: the asset is escrowed on its chain, the cash moves on the deposit token's ledger, and a coordinator releases both legs or neither within a timeout. Where a counterparty or asset lives on a chain your token does not reach, the cash leg may have to be a regulated stablecoin instead.
Who holds the keys and the client funds?
The bank holds both. The deposit stays on its balance sheet, and the issuer keys sit in the bank's own HSM or MPC custody and Safe multisig, under a signing policy its risk owners approve. Protofire builds the platform and, if asked, runs it under runbooks and access rights the bank defines; we never hold client funds and take no role as issuer or custodian.
Should we build a deposit token platform in-house or with a partner?
Use a partner when the priority is a production platform first; build in-house when the bank plans to run onchain money as its own engineering line for years and can staff smart contract, custody and 24/7 chain operations engineering. Either way, most of the effort is integration with systems the bank already runs: the core ledger, custody, compliance screening and payment messaging. Protofire builds the platform on layers we build in production, from permissioned tokens to Safe multisig key governance, and after launch the bank runs it with us or takes it over.
Discussed on The Protocol Roundtable
All episodesGet a proposal
Tell us what you are building. An engineer reads it, we have a short call, and the written proposal follows within one business day.
Budget
I accept the
Privacy PolicyI agree to receive new research announcements as well as information about Protofire services and special offers
An NDA is available from the first message and can cover anything you share. How it works