Skip to main content
Configure a deployment of the Cosmos Tokenization Suite (CTS) to issue tokenized deposits on your existing banking core.

​
Configure the deployment

1

Choose your core

Select your core banking platform, such as Fiserv or Jack Henry.
2

Choose the integration path

Connect the core over API, webhooks, or batch file exchange. CTS creates a deposit product on the core, reserved for tokenized deposits. See Custom Cores for the deposit product model.
3

Choose the assets to interoperate with

Select the assets CTS will host for the bank, such as USDC, EURC, or other external digital assets.This choice has two effects: (1) the bank can offer the selected assets to clients who want to hold or purchase them, and (2) clients can move the bank’s tokenized deposit onto those networks where the bank enables it.
4

Choose a custody provider

Select who will custody the bank’s digital assets, such as settlement stablecoins, and who will hold the keys that control them. Both functions can sit with an established custodian, such as Fireblocks or Anchorage, or with the bank itself, signing through its own hardware security modules.See Digital Asset Custody.
5

Choose a wallet model

A wallet model is either an individual wallet per client or an omnibus account comparable to the for benefit of model used by fintechs.
6

Choose a deployment model

A deployment model is either on-premises or cloud. An on-premises deployment runs inside the bank’s production environment under its controls. A cloud deployment is managed by Cosmos Labs, with the bank interacting over an API.Deployment models are scoped per bank. Contact sales@cosmoslabs.io to discuss which model fits your environment. See Architecture for what runs in each.

​
Issue tokenized deposits

The first run issues tokenized deposits from the bank’s existing balances: it replays the bank’s existing transactions onto the digital ledger, so its state matches the core.
1

Identify untokenized transactions

Query the core for transactions without a corresponding entry on the digital ledger.
2

Retrieve the transactions

Transactions are retrieved as camt.054 messages in the ISO 20022 standard. See ISO 20022 Messaging.
3

Tokenize each transaction

Transactions are tokenized one at a time. Each transaction moves from pending to confirmed as it is written to the digital ledger.
4

Confirm reconciliation

After every transaction has been replayed, balances on the core ledger and digital ledger agree. Reconciliation status between the two remains continuously visible from that point.

​
What you have afterwards

Every tokenized deposit has a corresponding deposit on the bank’s books, held on the bank’s own core. The two deposits stay reconciled. The bank has not left its ledger, and custody services and networks selected during setup can now reach the tokenized balances.
Deposit insurance and regulatory treatment of tokenized deposits depend on the jurisdiction and the bank’s regulatory position. Confirm treatment with your compliance and legal functions instead of relying on this documentation.

​
Next