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

# Tokenized Securities

> Tokenizing securities held on the general ledger, plus the wider securities case that is not yet a product.

<Note>
  Tokenized securities are not a shipped product. The one confirmed capability
  today is tokenizing securities held on the general ledger through the Jack Henry
  integration described below. Everything beyond that is directional. Contact our
  team at [sales@cosmoslabs.io](mailto:sales@cosmoslabs.io) to discuss a specific instrument or workflow.
</Note>

The securities use case is the asset class closest to tokenized deposits in the
Cosmos Tokenization Suite (CTS). The bank already carries the tokenized position on a
system it operates. The complications come from the instrument's restrictions
and the events it generates over its life.

## Securities on the general ledger

The Jack Henry integration is not limited to deposits. Securities held on the
general ledger can use the same ledger sync mechanism as deposits: the position
stays on the core and is mirrored to the digital ledger.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  subgraph Core["Jack Henry Core"]
    GL["General Ledger<br/>securities positions"]
    Dep["Tokenized Deposit Product"]
  end
  Digital[("Digital Ledger")]

  GL -->|"Mirror"| Digital
  Dep -->|"Mirror"| Digital
  Digital -->|"Writeback"| Core
```

This mechanism places securities and tokenized deposits on the same digital
ledger. A securities leg and cash leg can settle against each other without
either asset leaving the bank's books. This is the purpose of delivery versus
payment.

See [Jack Henry](/banking-core-integrations/jack-henry) for the integration and
[Delivery vs Payment](/settlement/delivery-vs-payment) for settling the two legs.

## Why the architecture suits the wider case

The properties supporting general ledger securities are not specific to Jack
Henry:

* The core stays the register of record: the position is mirrored instead of
  migrated, and reporting continues against its current system. See
  [Banking Core Integrations](/banking-core-integrations/overview).
* The cash leg is already on the ledger as a tokenized deposit. This makes atomic
  exchange possible without requiring reconciliation between two settlements.
  See [Atomic Settlement](/settlement/atomic-settlement).
* The bank's existing compliance, risk, and policy systems govern activity
  through the policy and logs interface. Instrument-level eligibility and
  restriction checks belong there. See
  [Components](/what-is-cts/components).
* Reaching a counterparty is a message between two ledgers over IBC. No
  intermediary takes custody of the security in transit. See
  [Inter-Blockchain Communication](/ibc/overview).

## What a securities product would still need

Three instrument-specific requirements separate the general ledger case from a
securities product:

* Transfer restrictions enforced at transfer time, covering investor eligibility,
  lock-ups, jurisdiction, and holding limits
* Lifecycle events, including coupon and dividend payments, corporate actions,
  maturity, and redemption
* Connectors to whichever register is authoritative for the instrument, which for
  most securities is a custodian or a central securities depository rather than
  the bank's own core

<Note>
  The security types in scope for the Jack Henry integration still need to be
  documented. The setup required to tokenize a general ledger position also needs
  to be documented.
</Note>

## Next

* [Jack Henry](/banking-core-integrations/jack-henry) for the supported integration
* [Real World Assets](/use-cases/real-world-assets) for the broader asset case
* [Delivery vs Payment](/settlement/delivery-vs-payment) for asset against cash settlement