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

# Key Security and Governance

> What the custody provider controls, what the bank retains, and how signing policy is enforced.

This page covers the key custody and signing function: protecting the private
keys that control digital assets and enforcing policy over their use. It is
distinct from digital asset custody, the holding of the assets themselves,
which is covered in the [Overview](/digital-asset-custody/overview#two-custody-functions).

The Cosmos Tokenization Suite (CTS) never holds private keys for assets on a shared or
public network. Keys are generated, stored, and used inside the custody
provider's environment, and CTS reaches them only through the custodian
API.

## What each party controls

| Control                               | Held by                                      |
| ------------------------------------- | -------------------------------------------- |
| Key generation and storage            | Custody provider                             |
| Key rotation and recovery             | Custody provider, under the bank's agreement |
| Signing policy definition             | Bank                                         |
| Signing policy enforcement            | Custody provider                             |
| Transaction initiation                | CTS, on the bank's behalf                    |
| Approval of an individual transaction | Bank, where policy requires it               |

The signing policy is the policy that the bank defines and the custody provider
enforces outside the CTS environment. A compromise of the CTS layer can
propose a transfer, but it cannot approve one outside policy or sign one at all.

## Signing policy

Signing policy is configured at the custody provider, not in CTS. A bank typically controls these dimensions:

* Transfer limits per transaction, per day, and per counterparty
* Allowlisted destination addresses, so settlement can only reach known wallets
* Approval thresholds requiring one or more human approvers above a given amount
* Separation of duties between the staff who define policy and those who approve
  transfers
* Time windows during which automated settlement may run

CTS does not express or override any of these dimensions. It requires only
that a submitted transfer resolves to approved, rejected, or pending, and it
tracks a pending request until the provider reports an outcome. The exact
policy vocabulary is the provider's own, and it is mapped during the
per-deployment integration described in
[Connecting a Custody Provider](/digital-asset-custody/integrations).

## Self-custody

Self-custody is an arrangement in which a bank holds its own keys and runs its
own key management. It is supported, with signing performed through the bank's
own hardware security modules.

Self-custody changes ownership, not the mechanism. The bank takes on every row
in the table above currently assigned to the custody provider, including
hardware security module operation, key ceremony, rotation, and recovery.

The integration surface is identical in either arrangement. CTS issues a
signing request and does not depend on which system answers it.

The choice is therefore operational and regulatory, not technical. See
[Overview](/digital-asset-custody/overview) for why most banks integrate a
provider instead, and
[Connecting a Custody Provider](/digital-asset-custody/integrations) for how
either arrangement is wired in.

## Related

* [Overview](/digital-asset-custody/overview) for the division of responsibility
* [Connecting a Custody Provider](/digital-asset-custody/integrations) for the
  integration surface
* [Settlement Asset Custody for 24/7 Payments](/digital-asset-custody/settlement-for-payments)
  for where signing happens in a payment flow
* [Digital Ledger Support](/digital-ledger-support/overview) for the chain the
  Suite runs alongside the core