Skip to main content
The Cosmos Tokenization Suite (CTS) requires specific capabilities from any core banking system, independent of platform. Use these requirements to determine whether a given core supports an integration before scoping one. The requirement follows from the architecture: CTS runs a digital ledger alongside the core and keeps both reconciled. It must read enough data to build the digital ledger’s state and write enough data to keep the core current.

​
What CTS reads from the core

​
What CTS writes to the core

Every write is an ordinary core posting. No blockchain awareness and no special transaction types are required of the core. Amounts are decimal currency at cent precision. Each write carries a memo or description; the core should retain it, because CTS uses it to recognize its own postings when it reads the history back. See Custom Cores for the deposit product model these operations run against. See Reconciliation for what happens when a write fails.

​
Duplicate prevention

CTS may submit the same write more than once. Retries after a network interruption, a restart, or a reconciliation pass are normal, so every write carries a stable reference, and the same reference must never post twice. Two models satisfy this:
  • The core honors a caller-supplied reference or external key and absorbs the duplicate itself. This is the preferred model.
  • The core has no such key, and CTS tracks what it has posted and does not re-send. This model works, but it depends on the memo surviving into transaction history so CTS can verify a posting whose outcome was ambiguous.
The distinction the core must make cleanly is between a definitive rejection, such as insufficient funds or an unknown account, and a transient failure. A definitive rejection tells CTS the posting did not land and can be retried or surfaced. An ambiguous answer forces CTS to confirm against recent history before it acts, which is why readable history is a hard requirement.

​
Posting semantics

Posting semantics are the core’s treatment of a posting. Read and write capability is necessary but not sufficient because that treatment determines settlement timing. A core that hardens a posting immediately allows CTS to treat a successful write as final. A core that memo-posts during the day and hard-posts in an end-of-day batch does not, and same-day confirmation then reads memo-posts rather than hardened entries. The interval between submission and hardening is a window the bank must account for operationally. Posting hardening is not a limitation of CTS: it is a property of the core. It is the single most important issue to establish early. See Fiserv for a worked example.

​
Optional capabilities

CTS uses these when the core offers them and works around their absence. None of them blocks an integration.

​
Checklist before scoping an integration

  • Can the core expose live balances, transaction history, and account and customer identifiers?
  • Can it accept posted debits, credits, and transfers programmatically?
  • Can a deposit account or product be designated for tokenized balances, and can debits on it be restricted?
  • Does the core honor a caller-supplied reference so a duplicate submission never posts twice, and does a posting’s memo survive into transaction history?
  • When does a posting harden, and what runs between submission and hardening?
  • What authentication does the core’s API require, and is enrolment in a vendor program needed to obtain credentials?
  • Is the core batch based or API based? See Integration Architecture.

​
Reference implementations