Mint & burn engine
Runs issuance, transfer and redemption as a state machine tied to core postings. Any undo is a compensating transaction, never a reversal.
Tokenised deposit infrastructure for licensed banks
Issue tokenised deposits from the ledger you already trust.
Naimint is the orchestration layer between your core banking system and tokenised deposit networks, with bank-controlled signing, compliance checks before every transaction and continuous reconciliation.
Your core leadsThe deposit liability stays on your core ledger.
Your HSM signsKeys stay in your HSM. We never hold one.
You're the memberYour bank joins the network in its own name.
Your core banking systemAuthoritative deposit ledger
NaimintTokenised deposit orchestration layer
Mint & burn
Core connectors
Compliance
Signing gateway
Reconciliation
Network adapters
Your HSMSigns under your policy
Token networkCanton today, more via adapters
Built for licensed banks
Enable new possibilities without replacing what works.
Launch tokenised deposits on your existing core banking system, with a clear line between what Naimint provides and what your bank keeps: the deposit liability, the keys, network membership and the customer relationship.
The Naimint platform
Six integrated modules. One cohesive platform.
Software to issue, transfer, redeem and reconcile tokenised deposits, deployed in your own cloud, with clear trust boundaries and bank controls.
Core banking connectors
Built on your core provider's own APIs, with a dedicated tokenised deposit account per customer, so your core needs no customisation.
Compliance controls
Eligibility, limits and screening run before any transaction is built, enforced ahead of signing and recorded for audit.
Signing gateway
Connects to your HSM over PKCS#11. It decodes and checks every transaction before your HSM signs, and manages per-customer keys.
Reconciliation & attestation
Independently checks that eligible deposit liability always covers outstanding tokens. If it doesn't, minting halts automatically.
Network adapters
One network-agnostic token model, expressed natively on each network. Canton comes first; new networks are additions, not rewrites.
How it works
From deposit to token, step by step.
The core moves first on the way in and last on the way out, so the same deposit is never spendable twice. Pick a step to see the controls around it.
Key checks at this step
Outcome
Designed around how banks work
Built for real-world banking requirements.
Practical outcomes: your core stays authoritative, your bank stays in control, and a scoped pilot proves it in your environment.
A shorter path to a pilot
Start with a defined scope on your existing core instead of replacing the ledger.
Clear control boundaries
Deposit accounting, key custody and network membership stay explicitly with your bank.
Open and extensible
Start intra-bank on Canton and add interbank networks through adapters as you're ready.
Security and control
Trust boundaries you can draw on a whiteboard.
A bank-focused architecture with defined responsibilities, controlled signing and continuous visibility of what's backed by what.
- Your HSM, your policy
- One key per customer in your HSM over PKCS#11. Naimint builds each transaction; your HSM applies your signing policy and can refuse. We never hold a key or produce a signature.
- Defined trust boundaries
- Ledger, orchestration, signing and network roles are separate, and signing and reconciliation run as isolated services.
- Continuous attestation
- Coverage is checked continuously, not at month-end. A shortfall stops minting before it can grow, and every state change is auditable.
- Deployed in your cloud
- Naimint runs in your own environment and fits your existing operations and change control. There's no third party on your settlement path.
Phase 1 pilot
Start with a focused pilot.
A Phase 1 pilot connects to a sandbox of your core, a private Canton domain and a development HSM. Your teams see the full mint, transfer and redeem cycle before anything touches production.
- 1DiscoveryUnderstand your environment, use cases and control requirements.
- 2IntegrationConnect your core sandbox and development HSM in an agreed test environment.
- 3TestingValidate flows, controls, failure handling and reconciliation end to end.
- 4Pilot reviewAssess results against agreed acceptance criteria and decide next steps.
Start inside. Connect out.
Two phases. The second adds to the first — it doesn't replace it.
The first tokenised deposit systems in production at major banks were single-issuer: tokens moving between one bank's own clients. Phase 1 follows that proven pattern, with no dependency on an external network.
Phase 1Available for pilots
Intra-bank, on your private Canton domain
Tokenised deposits move between your own customers. This proves the core integration, mint and burn, reconciliation, compliance and HSM signing end to end.
- Network-agnostic canonical token model
- No special-case path for intra-bank transfers
- Routing behind an interface from day one
- Counterparty as a first-class concept, even when internal
Phase 2Additive
Interbank, via network adapters
Issue once and reach many networks. Tokens are burned on one network and reissued on another, never bridged, so the canonical position stays with you.
Canton Global SynchronizerAtomic DvP across banks
Cari NetworkEVM / Prividium adapter
The Clearing HouseWhen bank integration is published
Ask Naimint
Your architecture and design questions, answered.
Ask Naimint is a self-serve assistant for approved teams at banks. Ask detailed questions about architecture, design, mint and redeem flows, custody and keys, reconciliation, APIs, security and deployment, and get answers straight away from Naimint's technical documentation. Our team is one click away for anything it can't cover.
Access is for named people at banks. We review every request.
Questions you can ask
- What does the custody service check before it signs?
- How do you avoid double-booking when the core times out?
- When does reconciliation halt minting, and who can lift it?
- How does the channel API handle idempotency?
- What runs where in an AWS deployment?
Insights
Tokenised deposits, explained.
Plain explanations for bank technology, risk and product teams. All insights →
JPMorgan and HSBC on Canton: what the banks announced
What JPMorgan and HSBC have announced about tokenised deposits on the Canton Network, what is live, what is planned and what it means for other banks.
Read →What is a tokenised deposit?
A tokenised deposit is bank money as a token on a ledger. It stays the bank's liability, backed one-for-one by its core ledger. How it differs from stablecoins.
Read →
Questions banks ask
Straight answers for your technology and risk teams.
What is Naimint?
Naimint is software for licensed banks that issues and manages tokenised deposits from the bank's existing core banking system. It is the orchestration layer between your core ledger, your HSM and tokenised deposit networks such as Canton. Naimint is a software vendor, not a bank, custodian or network participant.
What is a tokenised deposit?
A tokenised deposit is a commercial bank deposit represented as a token on a distributed ledger. It remains a deposit liability of the issuing bank. With Naimint, every token is backed by an earmarked balance on the bank's core ledger and is never a bearer instrument.
Does the core banking system stay the system of record?
Yes. The deposit liability stays on your core ledger. When tokens are minted, the core moves first: funds are earmarked in a dedicated tokenised deposit account before any token exists. When tokens are redeemed, the core moves last: tokens are burned on the network before the earmark is released.
Does Naimint hold keys or customer funds?
No. Keys live in your own HSM (Azure Managed HSM or AWS CloudHSM over PKCS#11), one per customer. Naimint builds each transaction; your HSM applies your signing policy and can refuse. Naimint never holds keys, produces signatures or holds customer funds.
Which networks does Naimint work with?
Canton first. Phase 1 runs on a private Canton domain for transfers between your own customers. Phase 2 adds interbank networks through adapters: the Canton Global Synchronizer, Cari Network, and The Clearing House once its bank integration is published. Network names describe compatibility only.
How do tokens move between networks?
By burn and reissue, never by bridging. Tokens are burned on one network and reissued on another, so the canonical position always stays with your bank.
What happens if a transaction fails part-way?
Nothing is deleted or reversed. Naimint posts a compensating transaction on each affected ledger, so your core, the network and the audit trail always agree. Reconciliation checks continuously that eligible deposit liability covers outstanding tokens, and halts minting automatically if it doesn't.
Where does Naimint run?
In your own cloud. Naimint is a Java modular monolith, with the signing gateway and reconciliation as separate services, so it fits your existing operations and change control. Your bank joins each network in its own name; Naimint connects through you.
What does a Phase 1 pilot involve?
A pilot connects to a sandbox of your core, a private Canton domain and a development HSM. Your teams see the full mint, transfer and redeem cycle before anything touches production.