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

# ISO 20022 Messaging

> The camt.054 message the Cosmos Tokenization Suite consumes, how entries map to mint and burn, and where ISO 20022 sits in the integration.

The Cosmos Tokenization Suite (CTS) uses one ISO 20022 message type:
`camt.054.001.08`, the bank-to-customer debit and credit notification. It is the
format in which core transactions reach CTS for tokenization.

Using a single standard message rather than a per-core format is what makes the
same tokenization path work across cores. A bank exchanging files and a bank
whose core exposes an API both hand CTS the same message type.

## How camt.054 reaches CTS

Two paths deliver the message, and both feed the same processing:

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  Drop["File drop<br/>camt.054 from the core"]
  API["Core API<br/>transactions read directly"]
  Norm["camt.054<br/>normalization"]
  Parse["Parse entries"]
  Engine["Mint or burn on the digital ledger"]

  Drop --> Parse
  API --> Norm --> Parse
  Parse --> Engine
```

A batch core delivers camt.054 files on its own cadence. An API core is read
directly, and the transactions are normalized into camt.054 before processing.
This means every transaction takes the same path regardless of how the core is
connected, and the normalized message is available for inspection either way.

## How entries are processed

Each notification carries entries, and two fields on an entry decide what
happens. The account is identified by IBAN, with a fallback to the account's
other identifier where no IBAN exists.

| Field                     | Value  | Effect                                                     |
| ------------------------- | ------ | ---------------------------------------------------------- |
| Credit or debit indicator | `CRDT` | Mint: a tokenized deposit is created on the digital ledger |
| Credit or debit indicator | `DBIT` | Burn: the tokenized deposit is reduced                     |
| Entry status              | `BOOK` | Processed                                                  |
| Entry status              | `PDNG` | Dropped: a pending entry is not tokenized                  |

Any other combination is rejected as unmapped: it becomes an error to resolve,
not a silent balance change.

## Writebacks

Writeback, the return direction that keeps the core current, posts through the
core connector rather than as ISO messages. A camt.054 rendering of pending
writeback entries is available for review and audit, in the same format as the
inbound flow.

Interbank coordination between deployments is also not ISO messaging: transfer
messages between banks travel over IBC. See
[Inter-Blockchain Communication](/ibc/overview).

## What this means for a batch integration

File exchange is a batch pattern, with three consequences:

* Writeback lags digital ledger activity by the file cadence rather than
  completing in near real time
* The window between a ledger event and the core reflecting it is larger, so the
  bank needs a defined position on what it does during that window
* Reconciliation exceptions surface at file processing time rather than at
  transaction time

Where a bank needs tighter coupling, a direct core connector is the better path.
See [Integration Architecture](/banking-core-integrations/architecture).

<Note>
  The camt.054 version consumed is `camt.054.001.08`. The field-level mapping
  reference, the file drop transport and cadence options, and the handling of
  malformed files beyond entry-level rejection still need to be documented.
</Note>

## Related

* [Overview](/banking-core-integrations/overview)
* [Core Requirements](/banking-core-integrations/core-requirements) for the read and write surface
* [Reconciliation](/banking-core-integrations/reconciliation) for how the two ledgers stay in agreement