> ## 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. # Tokenized Deposits > Representing commercial bank deposits on ledger while the deposit stays a deposit on the bank's own core. A tokenized deposit is a representation of a client's deposit balance, held on a digital ledger the Cosmos Tokenization Suite (CTS) runs alongside the bank's existing core. It is not a new liability, not a claim on a third party, and not a stablecoin. It is the same deposit, made transferable. This is the use case the Issuance solution is built for today, and the one most of this documentation describes. ## The deposit stays a deposit CTS creates a deposit product on the bank's core reserved solely for tokenized deposits. Balances held in accounts under that product are mirrored to the digital ledger. The product is blocked on the core side so those balances cannot move through the core's normal channels, and CTS holds the unlock key. ```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}} flowchart LR subgraph Core["Core Banking Platform"] Product["Tokenized Deposit Product
blocked, CTS holds the unlock key"] Other["Other Deposit Products
unaffected"] end Digital[("Digital Ledger")] Product -->|"Mirror"| Digital Digital -->|"Writeback"| Product ``` Two consequences follow. Every token has a real balance behind it on the bank's own books, because the token is created from that balance rather than issued against it. And the two ledgers cannot drift, because a balance in the reserved product cannot change without CTS being the path it changed through. See [The deposit product model](/banking-core-integrations/custom-cores) for the default configuration, and [Reconciliation](/banking-core-integrations/reconciliation) for how agreement between the two ledgers is maintained. ## Why that matters Keeping the core authoritative is a constraint the design accepts on purpose, because it is what lets the existing operating model continue unchanged: * Accounting, regulatory reporting, and audit run against the same system they do today * The deposit remains a deposit on the balance sheet, rather than becoming a different instrument that has to be classified and reported separately * Existing controls over the core are untouched, and existing deposit products are unaffected * The bank can stop issuing tokenized deposits without unwinding its books, because the balances never left them ## Regulatory treatment The design above keeps the deposit on the bank's own books. Whether that deposit is insured, and to whom, is a question of law rather than of architecture. What follows is the United States federal position, stated as the sources state it. ### The FDIC's position is a proposal, not a final rule On April 7, 2026 the FDIC Board approved a [notice of proposed rulemaking implementing the GENIUS Act](https://www.fdic.gov/news/press-releases/2026/fdic-approves-proposal-implement-genius-act-requirements-and-standards), published in the [Federal Register on April 10, 2026 under RIN 3064-AG19](https://www.govinfo.gov/content/pkg/FR-2026-04-10/html/2026-06974.htm), with a comment period that closed on June 9, 2026. Its stated purposes include to "clarify the treatment of tokenized deposits". As of the date of the sources cited on this page, it has not been finalized. The proposal would add a new 12 CFR 330.3(k), headed "Technology used to record deposits", reading: "The technology or type of recordkeeping utilized by an insured depository institution to record deposit liabilities does not affect whether those liabilities constitute 'deposits.'" It would also insert the words "regardless of the technology or type of recordkeeping utilized" into the definition of deposit account records at 12 CFR 330.1(e). In the preamble the FDIC states that "\[a] tokenized product that meets the statutory definition of 'deposit' is a deposit, and as such, is treated no differently under the FDI Act than other forms of deposits", and that "a depositor using tokenized deposits is afforded the same Federal deposit insurance coverage under the FDI Act as a depositor using non-tokenized deposits." Two points on the weight of that. The FDIC presents the amendment as codifying a principle it already reads out of the statutory definition of deposit at section 3(l) of the Federal Deposit Insurance Act, describing that definition as "technology neutral", so the agency's reading does not depend on the rule being finalized. The regulation itself, however, does not yet exist, and the FDIC is soliciting comment on whether the amendment is even the right one, asking in Question 131 whether it "should consider a more narrow amendment specifically focused on tokenized deposits". Before the proposal, the position existed only in speeches. On April 8, 2025, then Acting Chairman Travis Hill said in [View from the FDIC: Update on Key Policy Issues](https://www.fdic.gov/news/speeches/2025/view-fdic-update-key-policy-issues) that "we should provide certainty that 'deposits are deposits, regardless of the technology or recordkeeping deployed.'" That was a statement of what the agency should do, in a speech, which binds no one. ### The term is industry vocabulary the FDIC adopted "Tokenized deposit" is not defined in the Federal Deposit Insurance Act. The FDIC uses it descriptively in the proposal, in a footnote, as generally referring to "a tokenized form of an IDI's deposit liability recorded in an on-chain or off-chain account enabled with distributed ledger technology", and folds "deposit token" into the same term. It then asks, in Question 133, whether it would be helpful to define relevant terms at all. The legal test is the statutory definition of deposit, not the label. ### What the FDIC says cuts the other way The same proposal carries limits that matter more to a bank than the headline does: * Tokenizing a liability does not make it a deposit. "Although a tokenized deposit is a deposit, there may be tokenized bank liabilities that are not deposits, irrespective of an intention or representation that such constitute a deposit." * The characterization can change over the life of the product. Institutions "should also be mindful of the evolving characteristics and capabilities of tokenized deposits that may lead to any material changes to the underlying nature throughout a product or transaction lifecycle to ensure ongoing alignment of the underlying tokenized deposit with the FDI Act's statutory definition." * A token representing a claim on a deposit is an open question, not a settled one. Question 138 asks "\[h]ow should the FDIC view a digital asset that only represents an interest in or claim on a deposit at an IDI rather than being the tokenized deposit itself", and under what circumstances such a product would instead be a payment stablecoin backed by tokenized deposits. * Coverage is determined from the failed bank's records. Question 137 notes the FDIC "determines deposit insurance coverage at the time of the failure of an IDI, based on the IDI's deposit account records", and asks what challenges distributed ledger recordkeeping presents "as it relates to identifying owners of the deposits and aggregating tokenized deposits with other traditional deposits". * The GENIUS Act itself "does not address tokenized deposits, other than to provide that the definition of 'payment stablecoin' does not include, among other things, a deposit, including a deposit recorded using distributed ledger technology." ### Pass-through insurance is conditional and is being reconsidered Pass-through coverage is the mechanism that treats deposits placed at a bank by a third party on behalf of others as if the underlying owners had deposited directly. It does not follow from a deposit being a deposit. The FDIC states in the same proposal that "\[c]ertain regulatory requirements must be satisfied for pass-through deposit insurance to apply", citing 12 CFR 330.5(b) and 330.3(h): 1. "the deposit account records of the IDI must expressly disclose a basis for pass-through coverage, such as a custodial or agency relationship" 2. "the identities and interests of the owners must be ascertainable either from the records of the IDI or records maintained in good faith and in the regular course of business by the depositor or another party that maintains such records for the depositor" 3. "the relationship that provides the basis for pass-through deposit insurance coverage must be genuine, with the deposited funds actually owned by the named owners" The FDIC's [guidance for financial institution employees](https://www.fdic.gov/financial-institution-employees-guide-deposit-insurance/pass-through-deposit-insurance-coverage) adds that the account titling must indicate the agency nature of the account, and that where the requirements are not met the deposits are insured to the named account owner and aggregated with that party's other deposits in the same category at the same bank, which can leave balances uninsured. The FDIC has not resolved how those rules apply to tokenized arrangements. It "seeks comment on whether any amendments to the deposit insurance rules, including the pass-through rules, are needed to address tokenized deposits", and Question 139 asks what clarifications are needed and "\[t]o what extent should the FDIC consider modifications with respect to expectations around account titling and recordkeeping". In the April 2025 speech, a footnote is blunter: many of the existing operational rules for pass-through insurance, "such as the records needed to identify the ultimate owners of the deposits, were designed around legacy systems and may present challenges with blockchain-based payment arrangements." There is also a worked example of pass-through being denied. The same proposal would add 12 CFR 330.11(a)(3) providing that deposits held as reserves for a payment stablecoin are deposits of the issuer, insured as corporate deposits and "not insured to payment stablecoin holders on a pass-through basis". That is a different product from a tokenized deposit, but it shows the FDIC treating pass-through as a question to be decided on the facts of an arrangement. In the model this documentation describes, the accountholder on the bank's core is the bank's own client, so pass-through is not the mechanism in play. Where a deployment introduces a third party holding balances for underlying beneficiaries, it is, and the conditions above have to be met on their own terms. ### Other jurisdictions A United States position is not a global one. * European Union. MiCA, [Regulation (EU) 2023/1114](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1114), states at Article 2(4) that it "does not apply to crypto-assets that qualify as one or more of the following: ... (b) deposits, including structured deposits". A deposit therefore sits outside MiCA and inside the existing banking and deposit guarantee framework. * United Kingdom. In a Dear CEO letter dated 18 May 2026, [Reaffirming the PRA's position and clarifying expectations on innovations in the use of deposits, e-money and stablecoins](https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/letter/2026/innovations-in-the-use-of-deposits-emoney-and-regulated-stablecoins.pdf), the Prudential Regulation Authority says it "expects deposit-takers' innovations in deposits taken from retail customers, e.g. through tokenised deposits, including claims structured as transferable liabilities, to be done in a way that meets the PRA's rules for depositor protection under the FSCS and associated operational requirements." The same letter records that "\[s]tandard-setters and market participants have not yet settled on any definitions for 'tokenised' deposits." Nothing on this page is legal advice, and none of it is a representation that a given deployment is insured. Deposit insurance turns on conditions being met, including the statutory definition of deposit and, where a third party holds balances for others, the pass-through recordkeeping and ownership conditions above. It does not turn on the technology, and it is not conferred by using the Suite. The central United States authority cited here is a proposed rule that has not been finalized and could change. Confirm the treatment of your own product with your compliance and legal functions and with your primary regulator. ## What it unlocks A deposit on a digital ledger can do things a deposit on a core ledger cannot, because it is no longer bounded by the core's operating windows or its settlement cadence. Client payments clear continuously between banks over IBC. The interbank obligations they create settle separately, on demand or on a schedule, so a payment does not wait for a settlement window to complete. Balances move between accounts and networks within the day rather than at end of day, which changes how much liquidity has to be held idle to cover the gap. Transfers execute in response to conditions rather than manual instruction, under policy enforced by the bank's own compliance and policy engines. Programmability is governed rather than open. CTS connects to the bank's existing identity management, compliance and risk, and policy systems over the policy and logs interface, so those controls apply to a programmed transfer the same way they apply to a manual one. ## Where the deposit can go The networks selected during setup determine where a client can move the bank's tokenized deposit, and which assets the bank can host alongside it. Movement to a counterparty bank is a message between two digital ledgers over IBC, with no intermediary holding the asset. See [Connecting Networks](/ibc/connecting-networks) for the networks reachable, and [Settlement Options](/settlement/settlement-options) for the rails available to settle the resulting obligations. ## Next * [Issuance](/cts-issuance/overview) for the solution overview * [Core Requirements](/banking-core-integrations/core-requirements) to check whether your core can support the integration * [Getting Started](/what-is-cts/getting-started) for the setup and first tokenization run