> ## 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. # Core Requirements > The read and write API surface the Cosmos Tokenization Suite requires from a core banking system, and what to check before scoping an integration. 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 | Data | Why it is needed | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account balances | Establishing what a tokenized deposit is backed by. The balance must be a real, live figure, both available and total, not a cached or memo-only number that washes out overnight | | Transaction history | Replaying core activity onto the digital ledger, both at initial tokenization and on an ongoing basis. Each posting needs an amount, a credit or debit direction, a posting date, and a reference or description that survives into the history | | Customer and account identifiers | Tying a tokenized balance to the account it represents and the customer who owns it. Where the core cannot enumerate accounts, a curated list agreed at setup works instead | ## 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. | Operation | Why it is needed | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Post debits and credits | Reflecting digital ledger activity on the bank's books, including the writeback that follows an external settlement | | Transfer between two accounts | Moving funds between a customer's transaction account and the deposit account reserved for tokenization | | Clearing debits and credits | Recording the core-side legs of an interbank transfer. These post as ordinary debits and credits, routed through a clearing or suspense account where one is available | 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](/banking-core-integrations/custom-cores) for the deposit product model these operations run against. See [Reconciliation](/banking-core-integrations/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](/banking-core-integrations/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. | Capability | Used for | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account discovery | Enumerating in-scope accounts automatically instead of a curated setup list | | Batch balance reads | Fetching a whole roster of balances in one call instead of one read per account | | General ledger reads and journal postings | Reconciling against a GL control account and posting interbank settlement journals. Without them, CTS reconciles against its own balance snapshots and tracks interbank liability off the core | | Opening an account under the tokenized deposit product | Binding a new account for an existing customer on demand instead of at setup only | | Restricting debits on the tokenized deposit account | Preventing balances reserved for tokenization from being spent outside CTS, with CTS lifting the restriction for its own postings | | Per-transaction timestamps | Ordering digital ledger entries by wall-clock time instead of posting date alone | ## 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](/banking-core-integrations/architecture). ## Reference implementations | Core | Status | | ------------------------------------------------------- | ------------------------------------------ | | [Fiserv](/banking-core-integrations/fiserv) | Live on the Fiserv AppMarket | | [Jack Henry](/banking-core-integrations/jack-henry) | Supported on SilverLake via jXchange | | [Custom cores](/banking-core-integrations/custom-cores) | Batch and API based, scoped per deployment |