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

# Reconciliation

> The transaction mapping that keeps the core ledger and the digital ledger in agreement, and the token sync and writeback runs that maintain it.

A tokenized deposit is only trustworthy while it agrees with the core ledger
balance it represents. Reconciliation is the process that maintains that
agreement, and it is built on one record: a persistent mapping between each
bank-side transaction reference ID and the corresponding digital ledger
transaction hash.

The Cosmos Tokenization Suite (CTS) adapter maintains that mapping and is its
single source of truth. Both ledgers are reconciled against the mapping, not
against each other.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  CL["Core ledger:<br/>bank transactions"] <-->|"check against mapping"| MAP["CTS mapping:<br/>bank transaction reference ID<br/>to digital ledger transaction hash"]
  MAP <-->|"check against mapping"| DT["Digital ledger:<br/>on-chain transactions"]
```

Tokenization is per transaction. Two runs maintain the mapping, in opposite
directions, and a bank operator triggers each.

## Core to ledger: tokenization

Token sync carries core activity onto the digital ledger. Every core transaction
up to the cutoff is checked against the mapping. Anything unmapped has not been
tokenized yet, so a matching digital ledger transaction is created and the new
pair is recorded.

Transactions reach token sync as `camt.054` messages. See
[ISO 20022 Messaging](/banking-core-integrations/iso-20022).

## Ledger to core: writeback

Writeback carries digital ledger activity back to the core. Digital ledger
transactions are compared against the mapping, and any new ones are written back
to the core ledger and recorded.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart TB
  RUN["Operator triggers a run"]
  RUN --> A{"Token sync: is each core transaction<br/>already in the mapping?"}
  RUN --> B{"Writeback: is each digital ledger<br/>transaction already in the mapping?"}
  A -->|"no, not yet tokenized"| AM["Create the matching<br/>digital ledger transaction"]
  A -->|yes| REP
  B -->|"no, new on chain"| BW["Write it back<br/>to the core ledger"]
  B -->|yes| REP
  AM --> ADD["Record the new pair<br/>in the mapping"]
  BW --> ADD
  ADD --> REP["Report whether the two ledgers agree"]
```

Transactions roll up to balances on each side: accumulated digital ledger
transactions produce digital ledger balances, and core transactions produce core
balances. This means agreement between the ledgers is checked transaction by
transaction against the mapping, not inferred from balance totals.

## Preventing double spends

[Tokenized deposit accounts](/cts-issuance/transaction-flows#tokenized-deposit-accounts),
as a custom deposit product, are locked on the core, and the digital ledger
always holds the authoritative spendable balance. Debits from tokenized accounts
must clear the digital ledger first. This ensures a balance cannot be spent
twice at the moment of a transaction, because there is exactly one place a spend
can clear.

The core ledger remains the system of record for the bank's books. Every
on-chain movement is written back to it, and it is the system the bank reports
and audits from.

A core-ledger debit that bypassed the digital ledger violates this split. It
surfaces as an error at the next token sync, for the bank to resolve rather than
for the mapping to absorb. The
[blocked deposit product](/banking-core-integrations/custom-cores) exists to
make this case rare: balances under it cannot move through the core's normal
channels.

## Recovery after an outage

Either side can be unavailable without corrupting the model. The mapping
persists through an outage on either side. When the failed side recovers, the
adapter compares both ledgers against the mapping and reconciles whatever is
missing, in the same way as an ordinary run.

<Note>
  The operator surface for triggering runs and resolving errors, the reporting
  available to a controller, and the handling of a settled external movement that
  cannot be reversed still need to be documented.
</Note>

## Related

* [Integration Architecture](/banking-core-integrations/architecture) for the adapter this model lives in
* [ISO 20022 Messaging](/banking-core-integrations/iso-20022) for the inbound message format
* [Custom Cores](/banking-core-integrations/custom-cores) for the deposit product model