> ## 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.

# Integration Architecture

> Connection patterns between the Cosmos Tokenization Suite and a core banking platform, and how the integration behaves when something fails.

The connector between the Cosmos Tokenization Suite (CTS) and the core banking platform
is the component that makes a tokenized deposit meaningful. It has one job: keep
the digital ledger and the core ledger in agreement, in both directions, without
manual intervention.

## The adapter model

The integration layer splits into two parts: a bank-agnostic engine and a
per-core adapter.

The engine is the same for every bank. It carries the tokenization engine,
reconciliation, cross-bank transfer and settlement, the on-chain client,
persistence, and the contract bindings, and it talks to the digital ledger over
EVM JSON-RPC.

Each adapter integrates one specific core banking system. It holds that core's
vendor client and implements a common core-banking interface. Adapters depend on
the engine, never the reverse, and never on each other. This means adding a new
core means adding an adapter, not changing the engine, and no core integration
can break another.

## Process groups

A running deployment has three groups of processes, communicating over gRPC, EVM
JSON-RPC, and HTTP. They can run on one machine or be split across hosts and
clusters.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart TB
  subgraph BS["Banking systems"]
    CORE["Core ledger and the bank's existing applications"]
  end
  subgraph AD["CTS adapter"]
    APP["API server: bank-agnostic engine plus one per-core adapter"]
  end
  subgraph DL["Digital ledger stack"]
    TWIN["Private EVM chain"]
    SC["CTS and IBC contracts"]
    REL["IBC relaying: attestor, proof API, relayer"]
  end
  BS <-->|"Ledger sync"| AD
  AD -->|"EVM JSON-RPC"| DL
```

Only the IBC relaying components are externally reachable. The digital ledger
itself exposes no public interface, and the adapter reaches it from inside the
deployment. See [Digital Ledger Support](/digital-ledger-support/overview).

## Connection patterns

The core's available interfaces determine how CTS reaches it.

| Pattern         | Used when                                          | Characteristics                                       |
| --------------- | -------------------------------------------------- | ----------------------------------------------------- |
| API integration | The core exposes a real-time or near real-time API | Lowest latency between a ledger event and core update |
| File exchange   | The core operates on scheduled file drops          | Batch cadence, so writeback lags ledger activity      |
| Message based   | The bank exchanges ISO 20022 messages              | Standardized format, cadence depends on transport     |

Writeback is the core update that follows a ledger event. The connection pattern
determines how quickly writeback completes, which determines how the bank handles
the interval before the core reflects the event.

## Failure handling

The integration must assume that either side can become unavailable
independently.

If the core is unreachable, ledger activity continues, but writeback queues. The
bank needs a defined position on whether tokenization continues issuing against
a core it cannot currently confirm. It also needs a limit for the writeback
backlog before issuance pauses.

If CTS is unreachable, the core continues to operate as it does today.
Tokenized balances remain stale until the connector resumes. Reconciliation on
resume must account for core-side activity that occurred during the interval.

If the core rejects a writeback, the ledger and core disagree until the
disagreement is resolved. This case matters most: it is a reconciliation
exception, not a retry. See
[Reconciliation](/banking-core-integrations/reconciliation).

<Note>
  This page is a placeholder for the failure handling detail. The actual retry
  policy, backlog thresholds, the behavior CTS takes when issuance outruns
  writeback, and the operator surface for exceptions still need documentation
  against a named core.
</Note>

## Related

* [Overview](/banking-core-integrations/overview)
* [Reconciliation](/banking-core-integrations/reconciliation)