Skip to main content
The Cosmos Tokenization Suite (CTS) works with the custody provider a bank has already selected. The connection is an API integration: keys stay where they are, while the bank’s existing controls and reporting continue to apply. A bank that prefers to hold its own keys receives the same support. See Custom and self-custody integrations below.

​
What CTS requires from a provider

CTS drives the custody integration through five operations and one callback channel. A provider supporting the 24/7 payments settlement flow needs to offer:
  • Deposit address creation, so CTS can orchestrate funding of the bank’s settlement wallets
  • Balance reads for the wallets CTS settles from
  • Programmatic transfer initiation, accepted asynchronously: the provider returns a request identifier immediately, and the transaction hash once the transfer is approved, signed, and broadcast
  • Transfer status reads, so CTS can poll as a fallback when a callback is missed
  • Authenticated status callbacks, such as webhooks, for deposit confirmations and transfer status changes, so CTS can mark obligations settled
  • Address allowlisting, so settlement can be constrained to known counterparty wallets
The provider must also support the settlement chain and settlement asset the two banks agreed on, and enforce the bank’s signing policy before any transfer is signed.

​
How approvals fit

A transfer request may pause inside the provider while the bank’s approval policy runs, for example a four-eyes quorum above a threshold. CTS treats that pending state as normal. It tracks the request, resumes when the provider reports approval and broadcasts, and surfaces a rejection to the bank’s operators. Approval policy itself lives entirely at the provider; CTS never needs the authority to bypass it. See Key Security and Governance.

​
How an integration is delivered

Each provider is connected through an adapter that Cosmos Labs builds and maintains against the contract above, working from the provider’s API documentation, authentication model, and sandbox environment. Custody integrations are scoped and delivered per deployment as part of the bank’s rollout, so a provider is not required to build anything CTS specific: an API that covers the operations above is sufficient.

​
What the bank configures

  1. The custodial wallet CTS settles from and the counterparty wallets it may settle to
  2. The signing policy the custodian enforces, including approval thresholds
  3. The settlement trigger: on demand, scheduled, or threshold based
  4. Credentials for the custodian API, scoped to the operations CTS needs

​
Custom and self-custody integrations

Not every bank wants a third-party custodian. CTS supports two alternatives. A bank can custody its own digital assets and manage its own keys, consistent with OCC guidance that national banks may provide crypto asset custody. Its hardware security modules perform signing instead of a provider. The integration surface remains unchanged: CTS issues the same signing request, while the system enforcing policy and holding the key differs. The bank assumes every responsibility that a custodian would otherwise carry: key ceremony, storage, rotation, and recovery. See Key Security and Governance. A bank can also integrate a provider that is not already supported. These integrations are scoped per deployment. Contact sales@cosmoslabs.io with the provider, the networks it covers, and the policy controls it enforces.

​
Independence between counterparties

Each bank connects its own provider. Bank B’s wallet may use the same custody and issuance providers as Bank A, or an entirely different set. The counterparties agree on the settlement asset and chain, not on a shared vendor.