Banks have three integration paths to issue tokenized deposits: bank-issued on the bank's own ledger, token-issued with a custody bank holding the reserves, and bank API deposit locking against existing accounts. The choice is not a vendor preference. It is a function of the bank's core-ledger architecture, regulatory license, and balance-sheet scale, and picking the wrong one is the most common reason pilots stall in procurement.
What a tokenized deposit actually is, and what it is not
A tokenized deposit is a commercial bank deposit liability represented on a distributed ledger. It remains a deposit in every legal and regulatory sense. The European Banking Authority is direct on this point: "tokenisation does not per se alter the fundamental nature of the claim and thus its regulatory qualification as a deposit," which is why activities involving tokenised deposits are excluded from the scope of MiCAR and sit instead under the Capital Requirements Directive.
That definitional anchor matters because three things get conflated in the market. Stablecoins are claims on a private issuer. E-money is a separately regulated instrument. A tokenized deposit is a bank liability with deposit insurance, capital treatment, and resolution rights attached. The FDIC restated this plainly in 2025: "deposits are deposits, regardless of the technology or recordkeeping deployed." The Federal Reserve confirms the same posture, noting in a December 2025 FEDS Note that banks are building tokenized deposit products "that aim to combine the convenience and programmability of digital tokens with the regulatory protections of traditional banking services."
What a tokenized deposit is not is a bearer instrument. The EBA report on tokenised deposits is explicit: the claim is account-based, bound to the identity of the account holder, and not directly transferable to a non-client of the bank. That single design constraint is what preserves the singleness of money and is the reason the BIS, in Bulletin 73, considers tokenized deposits more conducive to monetary integrity than bearer-style stablecoins.
Why the integration model is a balance-sheet decision, not a tech decision
The choice of integration model is dictated by where the deposit liability sits, who holds the license, and what the bank's core ledger can do. Three variables decide it: whether the bank can run a primary record on DLT, whether the token issuer is itself the bank or a non-bank entity using a bank for custody, and how much balance-sheet weight the institution can place against the program. Vendor RFPs rarely distinguish between these three paths, which is why most pilots discover the mismatch only after procurement begins.
The EBA's report on tokenised deposits frames the technical version of this split as one-layer versus two-layer architectures. In the one-layer (native) model, the DLT is the primary record of the deposit. In the two-layer (non-native) model, the DLT mirrors a traditional deposit account on the bank's core, and reconciliation processes between the two ledgers are required. UK Finance's Regulated Liability Network work calls these the direct and indirect models. The architectural choice cascades into license requirements, capital treatment, and operational risk.
This is also a balance-sheet question. A bank-issued model puts the liability directly on the issuing bank's balance sheet. With a token issuer and custody bank, reserves park at the custodian and the on-chain claim is structurally different. Under API deposit locking, the deposit stays where it is and programmable controls encumber it. Each has a different capital, liquidity, and resolution profile, and none of those profiles are interchangeable. FractiFi's base layer enforces the same invariant across all three: total token supply must equal total locked bank deposits, continuously and verifiably.
Model 1: Bank-issued tokenized deposits
In the bank-issued model the bank itself issues the token, the token represents a direct claim on the issuing bank, and the DLT either is the primary ledger or sits as a tightly integrated subledger of the bank's core. This is the deepest integration of the three and the strongest regulatory alignment, because the issuer is the regulated deposit-taker and the instrument is unambiguously a deposit on its books.
JPMorgan's Kinexys is the reference implementation. Blockchain Deposit Accounts let clients mint JPM Coin directly from a BDA, which JPMorgan describes as "a more direct tokenization," and the program now runs across a permissioned blockchain that has processed over $3 trillion in cumulative volume with more than $7 billion in average daily flows. South Africa's FirstRand moved onto Kinexys in 2026 to automate 24/7 USD transfers between its group entities. Citi Token Services followed the same template, going live commercially in October 2024 with Mars as an early client and expanding to five locations and euro denomination by late 2025.
This model demands the most from the issuing bank. It requires a core-ledger architecture that can either run on DLT directly or maintain near-zero reconciliation latency to a DLT subledger, a license posture that accommodates the program in every jurisdiction where the token circulates, and enough balance-sheet capacity to absorb the corresponding deposit liability. That set of conditions exists at global systemically important banks. It does not exist at most regional or mid-tier institutions, which is why so few independent bank-issued programs follow the JPMorgan and Citi pattern.
Model 2: Token issuer with custody bank
In the token issuer with custody bank model, a separately licensed token issuer issues the on-chain instrument and a regulated bank holds the underlying reserve assets in segregated, bankruptcy-remote custody. The bank does not issue the token. Reserves sit at the custody bank, but the on-chain claim is the issuer's. This is the fastest model to market because it routes around the bank's core-ledger constraints, but it is also the model that requires the most rigor on the legal structure between issuer and custodian.
Hong Kong's licensing framework illustrates the operational requirements precisely. The HKMA explanatory notes on stablecoin issuer licensing require written contractual agreements with qualified custodians, and "an effective trust arrangement should be put in place to ensure that the reserve assets are segregated from the assets of the applicant, held for and on behalf of specified stablecoin holders." The FCA observed the same pattern in DP23/4: most issuers of fiat-backed stablecoins hold at least part of their backing as deposits with banks or assets with custodians.
For the bank, this model is attractive because reserves sit on its balance sheet without the bank having to build, license, or operate the token program. For the token issuer, it is attractive because the bank's regulatory status anchors the reserve story. The trade-off is that the on-chain instrument is structurally a claim on the issuer, not a claim on the bank. That distinction matters for capital treatment, deposit insurance coverage at the holder level, and how the instrument behaves in a resolution scenario. It is the right model for non-bank fintechs and for banks that want to support a tokenized money program without absorbing the engineering and license expansion that the bank-issued model demands.
Model 3: Bank API deposit locking
In the API deposit locking model the deposit never leaves the customer's existing bank account. A token is minted against that account and the bank, via API, places a programmable encumbrance on the underlying balance so it cannot be moved while the token is outstanding. Total token supply matches total locked deposits at every point in time. This is the most capital-efficient integration of the three. No funds move into a reserve account, no liquidity buffers are required, and once the API is in place, mint and redemption execute in seconds. The trade-off is that it makes the most demanding ask of the bank's infrastructure: it requires a stable, programmatic deposit-lock API, which is why it fits Open Banking jurisdictions where that capability is already a regulated surface.
No public source uses this term, because the framework is FractiFi's. The mechanic, however, sits on top of well-understood primitives. The bank exposes account control APIs. The token issuer holds a permission to lock and release. The on-chain supply is reconciled in real time against locked balances on the bank side. The deposit liability stays with the customer's bank, the customer remains the depositor of record, and the token represents an encumbered claim against a specific locked balance rather than a new deposit liability against the token issuer.
The model fits a specific institution profile. It works for banks whose core ledgers cannot, in the short term, support a one-layer DLT issuance and whose balance sheets are too thin to absorb a bank-issued program at meaningful scale, but who operate in jurisdictions with mature API mandates. In practice, banks rarely start here. The typical progression is to begin with the custody-bank model for speed to market, migrate to API deposit locking as Open Banking infrastructure matures, and ultimately move to bank-issued as the deep core integration completes. Each step preserves the customer relationships, compliance workflows, and reconciliation discipline built in the prior phase.
How to pick: a decision frame for CTOs and digital-asset leads
Three questions decide the model. Can the core ledger serve as, or tightly mirror, a primary DLT record? Does the bank hold the license posture, in every jurisdiction of intended circulation, to issue the token itself? Does the program have enough balance-sheet weight behind it to justify the engineering and capital cost of full issuance? If the answer to all three is yes, the bank-issued model is the right one. A "no" on any one pushes the decision to one of the remaining two.
When the bank wants the deposit liability on its balance sheet but is not the right entity to operate the token program, the token issuer with custody bank model is the fit. Banks that cannot or do not want a new deposit liability structure, but operate in an Open Banking jurisdiction, should pick API deposit locking. The mismatch failure mode is consistent: regional banks attempting bank-issued programs without the core-ledger or license footing to support them, non-bank issuers pursuing models that effectively require a banking license, and Open Banking-jurisdiction institutions ignoring the lightest path because no vendor RFP described it.
The decision is not reversible cheaply. Each model implies a different operating model, a different regulatory engagement, and a different set of integrations into customer treasury workflows. Choosing late, after a vendor has scoped to one model and the institution discovers it needed another, is what produces the long procurement freezes that have characterized the first wave of tokenized deposit pilots.
What still has to be true regardless of model: the settlement leg
Model choice is downstream of one prior question: how the cash leg settles. Without central bank money or its equivalent on the same rails as the token, every model degrades into a faster version of correspondent banking. The BIS makes the point in its 2025 Annual Economic Report: tokenisation of deposits and central bank money lets the primary means of payment and the settlement function of central bank money sit on the same programmable platform.
Live infrastructure is converging on this. The HKMA's EnsembleTX program settles interbank tokenized deposit transactions through HKD RTGS today and is evolving toward 24/7 tokenized central bank money. Fnality's sterling payment system received UK settlement finality designation and processed the world's first regulated DLT-based wholesale payment with BNP Paribas in 2025 using "a digital representation of funds held at the central bank." Partior provides 24/7 multi-currency clearing for DBS, JPMorgan, Standard Chartered, Deutsche Bank, and Emirates NBD with atomic payment-versus-payment. The EBA report records one live EEA case in which interbank settlement of tokenized deposit transactions ran through the existing RTGS system.
The institutional implication is direct. A bank choosing an integration model should resolve the settlement leg in parallel, not after. A bank-issued program with no path to central bank money settlement reproduces the on-us-only limitation that constrained JPM Coin's earliest iterations. A custody-bank or API-locking program with no settlement layer becomes a closed loop. The model decision and the settlement decision are one decision, and they should be made together.
FractiFi builds the tokenized deposit infrastructure for banks that supports all three models on a single base, with the reserve invariant enforced at the protocol level and a settlement layer designed to plug into RTGS, DLT-based wholesale payment systems, and future tokenized central bank money rails as they come online. For banks, asset managers, and fintechs working out which model fits their architecture, license, and balance sheet, this is the conversation we want to have early, before vendor scope has locked the answer. If you are scoping a tokenized deposit program and want a working session on the model decision, we would like to talk.
