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

# Custom Cores

> How the Cosmos Tokenization Suite integrates with batch and API-based cores without prebuilt connectors.

A custom core is a core without a prebuilt connector. The Cosmos Tokenization
Suite supports custom cores through the same integration model for batch and
API-based cores. Their cadence differs, but their structure does not. See
[Integration Architecture](/banking-core-integrations/architecture).

## The deposit product model

By default, CTS creates a new deposit product on the custom core. The
deposit product is reserved solely for tokenized deposits.

The assets in accounts under this product are mirrored directly to the digital
ledger. This ensures every token remains backed by a real balance on the bank's
own books.

The core blocks the deposit product, so its balances cannot move through normal
core channels. CTS holds the unlock key and is the only path for changing
these balances. This prevents either ledger from changing without CTS
knowing and keeps the ledgers aligned.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
flowchart LR
  subgraph Core["Core Banking Platform"]
    Product["Tokenized Deposit Product<br/>blocked, CTS holds the unlock key"]
    Other["Other Deposit Products<br/>unaffected"]
  end
  Digital[("Digital Ledger")]

  Product -->|"Mirror"| Digital
  Digital -->|"Writeback"| Product
```

Existing deposit products are untouched. Only balances the bank chooses to
tokenize move into the reserved product.

<Note>
  This is the default configuration. Alternative configurations are supported,
  and Cosmos Labs can discuss what fits a given core and operating model. Contact
  [sales@cosmoslabs.io](mailto:sales@cosmoslabs.io).
</Note>

## Batch cores

A batch core is a core that exchanges files on a schedule. Mirroring and
writeback run at the file cadence, creating a window before the other ledger
reflects activity. This means the bank needs a defined position on activity
during that window.

Where the core exchanges ISO 20022, see
[ISO 20022 Messaging](/banking-core-integrations/iso-20022).

## API-based cores

An API-based core is a core that allows near-real-time reads and writes. The
window between a ledger event and its reflection on the other ledger is therefore
much smaller. The deposit product model is unchanged.

## What to prepare

* Which core platform and version is in use
* Whether the core is batch based or exposes an API
* Whether the core supports creating and blocking a deposit product, and who
  administers that
* The file transport or API credentials CTS will use

<Note>
  This page is a placeholder for the integration procedure. The steps to create
  and block the deposit product on a given core, the credential and transport
  setup, and the certification process all still need to be documented.
</Note>

## Related

* [Overview](/banking-core-integrations/overview)
* [Reconciliation](/banking-core-integrations/reconciliation)