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. 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.Connection patterns
The core’s available interfaces determine how CTS reaches it.
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.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.