Your core leads. Tokens follow.
The deposit liability stays on your core ledger. Every token is backed by an earmarked balance there, and it is never a bearer instrument. Core moves first on the way in and last on the way out.
Tokenised deposit orchestration for licensed banks
Issue tokenised deposits from the ledger you already trust.
Naimint is the software layer between your core banking system and tokenised deposit networks. Your core stays authoritative, your HSM holds every key, and your bank is the network member. We orchestrate everything in between.
Your core banking systemAuthoritative ledger for the deposit liability
You own
Naimint orchestration layerWe build
Mint / burnCore connectorsCompliance
Signing gatewayReconciliationNetwork adapters
Your HSMHolds every key. Signs under your policy.
Settlement networkCanton today. More via adapters.
Three rules we never break
Tokenisation without handing over your balance sheet, your keys or your seat at the table.
Your keys. Your signatures.
Keys live in your HSM, one per customer. Naimint builds each transaction; your HSM applies your own signing policy and can refuse. We never hold a key or produce a signature.
You're the member. We're the software.
Your bank joins the network in its own name. We connect through you, never beside you. There's no intermediary on your settlement path and no new counterparty for your regulator to assess.
The platform
Everything between your core and the chain.
Six modules, deployed in your own cloud. The signing gateway and reconciliation run as isolated services because they are your trust boundaries.
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, so every ledger stays append-only.
Core banking connectors
A common layer plus an adapter for each core, built on your core provider's own REST APIs. We open a dedicated tokenised deposit account for each customer, so your core needs no customisation.
Compliance controls
Eligibility, limits and screening run before any transaction is built. Your policies are enforced ahead of signing and recorded for audit.
Signing gateway
Connects to your Azure Managed HSM or AWS CloudHSM over PKCS#11. It manages per-customer key lifecycle and signing requests without a third-party custody platform.
Reconciliation & attestation
Independently checks that eligible deposit liability always covers outstanding redeemable tokens. If it doesn't, minting halts automatically.
Network adapters
A network-agnostic token model that each adapter expresses natively on its network. Canton/Daml comes first, and new networks are additions rather than rewrites.
How it works
One mint, one redemption, every layer.
The same deposit can never be spent twice. Real money and token money are never both spendable at the same time.
Mint
Core moves first- 01Channel
A customer asks to tokenise part of a deposit balance.
- 02Core
Funds move into the customer's tokenised deposit account and are earmarked.
- 03Naimint
Compliance and limit checks run, and the customer is mapped to their own network party.
- 04Naimint
The mint transaction is built, with your bank as signatory.
- 05Your HSM
Your HSM applies your signing policy, then signs or refuses.
- 06Network
The transaction is submitted to the network and final settlement is confirmed.
- 07Reconciliation
Coverage is re-attested: eligible deposit liability ≥ outstanding tokens.
Redeem
Core moves last- 01Naimint
The redemption is checked and a burn transaction is built.
- 02Your HSM
The burn is signed under your policy.
- 03Network
The tokens are burned on the network first.
- 04Core
Only then is the earmark released and the balance returned to the deposit account.
- 05Reconciliation
The position is re-attested and recorded for audit.
If something fails mid-flow
Nothing is deleted or reversed. Naimint posts a compensating transaction on each affected ledger, so your core, the network and the audit trail always tell the same story.
A clean line of responsibility
We're a software vendor, not a bank, custodian or network participant.
Naimint delivers
- Mint, burn and transfer orchestration
- Core banking connectors and tokenised deposit account set-up
- Compliance controls ahead of signing
- Signing orchestration to your HSM
- Reconciliation, attestation and automatic mint halt
- Network adapters and the canonical token model
Your bank keeps
- The deposit liability, on your own core ledger
- Custody: HSMs, keys and signing policy
- Network membership, in your own name
- Settlement liability and the customer relationship
- Your infrastructure: we deploy into your cloud
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
Built for bank technology teams
Familiar technology, and trust boundaries you can draw on a whiteboard.
- Java, deployed in your cloud
- A modular monolith with the signing gateway and reconciliation as separate services. It fits your existing operations and change control.
- Your HSM over PKCS#11
- Azure Managed HSM or AWS CloudHSM. There's no separate custody platform to license, and no third party on your signing path.
- Per-customer keys
- Each customer has a distinct network party with its own key in your HSM. There are no omnibus wallets.
- Core-agnostic by design
- Adapters declare what each core can do, and the token mapping lives with us, not in your core.
- Append-only everywhere
- Compensating transactions instead of reversals, matching how ledgers and smart contracts already behave.
- Continuous attestation
- Coverage is checked continuously, not at month-end. A shortfall stops minting before it can grow.
Run your first tokenised deposit on your own infrastructure.
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.