> ## Documentation Index
> Fetch the complete documentation index at: https://cts-docs.cosmos.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How the Cosmos Tokenization Suite sits alongside a bank's existing core and connects it to custody services and external networks.

The Cosmos Tokenization Suite (CTS) does not replace the bank's existing core. Instead,
CTS contains a digital ledger that stores and tracks tokenized deposits
alongside the core. The core ledger stays authoritative.

CTS manages tokenization and reconciliation between the two ledgers.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  subgraph Orig["Originating Depository FI"]
    subgraph Stack["Existing Stack"]
      Apps["Enterprise Apps<br/>ID management, compliance and risk,<br/>policy engine, EMS and OMS"]
      Core[("Core Ledger")]
    end
    subgraph Issuance["Issuance"]
      App["Tokenized Deposits App"]
      Digital[("Digital Ledger")]
      CustConn["Custody Connectors"]
      NetConn["Networks Connectors"]
    end
  end

  Custody["Custody Services"]
  Networks["Networks<br/>Public · Consortia · Private"]

  subgraph Recv["Receiving Depository FI"]
    Wallet["Token Wallet"]
    RecvCore[("Core Ledger")]
  end

  Apps <-->|"Policy and logs"| App
  Core <-->|"Ledger sync"| Digital
  App --- Digital
  App --- CustConn
  App --- NetConn
  CustConn <--> Custody
  NetConn --> Networks
  Networks -.-> Wallet
  Core -.->|"Settlement bus"| RecvCore
```

## The two ledgers

Everything in CTS follows from there being two ledgers that must agree.

The core ledger is the bank's existing system of record, whether Fiserv,
Jack Henry, or another platform. It continues to hold the deposit and
remains the system from which the bank reports and audits.

The digital ledger is created by CTS alongside the core. It holds the
tokenized representation of those deposits and gives the bank reach into custody
services, other networks, and counterparty banks.

Ledger sync is the bidirectional process that keeps the two ledgers in agreement.
A tokenized deposit is only meaningful while every digital-ledger token has a
corresponding deposit on the core. See
[Reconciliation](/banking-core-integrations/reconciliation).

## Interfaces

| Interface           | Connects                                         | Carries                                                                                           |
| ------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Policy and logs     | Enterprise apps to the tokenized deposits app    | Compliance, risk, and policy decisions from systems the bank already runs, and audit records back |
| Ledger sync         | Core ledger to digital ledger                    | Tokenization of core transactions, and writeback of digital ledger activity                       |
| Custody connectors  | CTS to custody services                          | Signing requests for assets held on external networks                                             |
| Networks connectors | CTS to public, consortia, and private networks   | Asset movement and interoperability                                                               |
| Settlement bus      | Originating core ledger to receiving core ledger | Settlement of interbank obligations                                                               |

### Why the policy and logs interface exists

Without the policy and logs interface, compliance, risk, and policy would require
reimplementation inside the tokenization layer. Instead, they remain in the
systems the bank already operates, with audit records returned to those systems.

## Choosing the digital ledger

The bank chooses what the digital ledger runs on:

* The Cosmos EVM ledger, which is the recommended path and the fastest to deploy
* The bank's own ledger, which is fully supported where the bank has an existing
  chain or a requirement to operate its own

See [Digital Ledger Support](/digital-ledger-support/overview).

## Deployment

Two deployment models are supported, and the bank makes the choice during setup.

On-premises deployment runs CTS inside the bank's own production
environment and under the bank's own controls. Cloud deployment is managed by
Cosmos Labs. The bank interacts with a cloud deployment through an API instead
of operating it.

The components communicate over standard protocols and are independently
deployable. A production deployment can therefore split them across hosts or
clusters. The deployment model is an operational choice: both models run the same
components.

<Card title="Talk to us about deployment" icon="mail" href="mailto:sales@cosmoslabs.io">
  Deployment models are scoped per bank. Contact [sales@cosmoslabs.io](mailto:sales@cosmoslabs.io) to discuss
  which model fits your environment and controls.
</Card>

See [Getting Started](/what-is-cts/getting-started) for its place in setup.

## Related

* [Components](/what-is-cts/components) for what each part does
* [Banking Core Integrations](/banking-core-integrations/overview) for the core side
* [Digital Asset Custody](/digital-asset-custody/overview) for the custody side