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

# Transaction Flows

> The value-movement flows in Issuance: internal deposit and withdrawal, cross-bank transfer, refund, and settlement.

Four flows move value in Issuance. Two are internal to one bank, and two cross
banks. Each is described here at the level of what moves, in what order, and
what happens on failure.

## Tokenized deposit accounts

A tokenized deposit account is a new deposit product created on the bank's core,
reserved solely for tokenized deposits. Balances held under it are mirrored to
the digital ledger, and the product is blocked on the core side with CTS holding
the unlock key. See [Custom Cores](/banking-core-integrations/custom-cores).

The flows below move value into, out of, and between these accounts.

## Internal deposits: from demand deposits to tokenized deposits

A customer moves funds between their conventional demand deposit account and
their tokenized deposit account at the same bank. Both sides are the bank's own
money on its own core ledger: the movement is a change of form, with no external
asset and no escrow.

Depositing debits the demand deposit account and credits the tokenized deposit
account on the core, then mints the matching tokenized deposit to the customer's
on-chain account, tracked against the bank's tokenized deposit control account.

Withdrawing reverses it: the tokenized deposit is burned, and the funds are
credited back to the demand deposit account.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sequenceDiagram
  participant C as Customer
  participant BS as Banking systems
  participant AD as CTS adapter
  participant DL as Digital ledger
  Note over C,DL: Deposit: lands on the core ledger first
  C->>BS: Move funds from demand deposit to tokenized deposit
  BS->>BS: Debit the demand deposit, credit the tokenized deposit account
  BS->>AD: Credit transaction synced toward the digital ledger
  AD->>DL: Mint the tokenized deposit to the customer's account
  Note over C,DL: Withdrawal: clears the digital ledger first
  C->>AD: Move funds from tokenized deposit to demand deposit
  AD->>DL: Debit the customer's on-chain account
  DL->>AD: Debit synced toward the core ledger
  AD->>BS: Debit the tokenized deposit account, credit the demand deposit
```

A deposit lands on the core ledger first, because
the core is the record of record for the incoming funds. A withdrawal clears the
digital ledger first, because the digital ledger holds the authoritative
spendable balance for a tokenized account. This ensures a tokenized balance
cannot be spent twice. See
[Reconciliation](/banking-core-integrations/reconciliation).

## Cross-bank transfers

The sending bank burns its deposit token on send, and the receiving bank mints
its own deposit token and credits the recipient. No escrow is involved, and each
bank's token stays within its issuer's perimeter. The full flow, including the
IBC message and acknowledgment, is documented in
[Token Transfers](/ibc/token-transfers).

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sequenceDiagram
  participant SA as Bank A digital ledger
  participant SB as Bank B digital ledger
  SA->>SA: Burn the sender's deposit tokens
  SA->>SB: IBC message
  SB->>SB: Verify, compliance check, mint Bank B's token
  SB->>SB: Credit the recipient
  SB->>SA: IBC acknowledgment
```

## Refunds

Every cross-bank failure path re-mints the original deposit tokens to the
original sender: destination rejection, for example an unknown recipient
account, and timeout both resolve the same way. Refunds are automatic rather
than operational.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sequenceDiagram
  participant SA as Bank A digital ledger
  participant SB as Bank B digital ledger
  SA->>SA: Burn the sender's deposit tokens
  SA->>SB: IBC message
  alt Destination rejects
    SB->>SA: Reject acknowledgment, for example unknown recipient
  else Timeout
    SA->>SA: Prove the timeout
  end
  SA->>SA: Re-mint the tokens to the sender
```

## Settlement

A cross-bank transfer moves value and records the interbank obligation at the
same time. The obligations settle separately, in batch, over the rail the bank
chose at onboarding, netted or gross as the counterparties agreed. See
[Settlement](/cts-settlement/overview) and
[Settlement Options](/settlement/settlement-options).

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  T["Cross-bank transfers<br/>clear continuously"] --> O["Obligations recorded<br/>in CTS"]
  O --> N["Netted or gross,<br/>as agreed"]
  N --> R["Settlement run<br/>periodic or on demand"]
  R --> Rail["Chosen rail:<br/>tokenized deposit network,<br/>stablecoin, or traditional"]
```

## Related

* [Reconciliation](/banking-core-integrations/reconciliation) for the mapping these flows are checked against
* [Integration Architecture](/banking-core-integrations/architecture) for the components involved