---
path: /report/tokenized-money-for-banks/
title: "Tokenized Money for Banks: A Bank Treasury Guide to Institutional Settlement on Tokenized Rails"
description: A primer for banks evaluating tokenized deposits, first-party stablecoins, and third-party stablecoin settlement products.
image: /og/2026-q4/og_2026-q4_report_tokenized-money-for-banks_linework-f5_v02.png
category: Banking
order: 4
heroTitle: "Tokenized money for banks: a bank treasury guide to institutional settlement on tokenized rails"
seoTitle: Tokenized Money for Banks — Get the full report
seoDescription: A Tempo research report for banks evaluating tokenized deposits, first-party stablecoins, and third-party stablecoin settlement products.
printTitle: Tokenized Money for Banks
shortTitle: Tokenized Money for Banks
reportSummary:
  text: The report works through the tokenized money choices available to banks and shows how each product changes the deposit claim, liquidity ratios, venue reach, and operational burden.
  items:
    - How tokenized deposits preserve the bank claim
    - Where first-party stablecoins re-engineer the liability profile
    - When third-party stablecoins reach venues bank claims cannot
    - How LCR, NSFR, and RWA shape the product decision
audience: Bank treasury, ALCO, transaction banking, and digital asset teams
subtitle: A Bank Treasury Guide to Institutional Settlement on Tokenized Rails
eyebrow: Stablecoin Advisory
authors:
  - name: Simon Taylor
    url: https://www.linkedin.com/in/sytaylor/
  - name: Borja Neira
    url: https://www.linkedin.com/in/bneira/
  - name: Jevgenijs Kazanins
    url: https://www.linkedin.com/in/kazanins/
metrics:
  - value: "3"
    label: Product families for bank tokenized money
  - value: 100%
    label: Stablecoin redemption-liability LCR outflow under SCO60
  - value: 85%
    label: NSFR required stable funding for principal third-party stablecoin inventory
reportUrl: /report/tokenized-money-for-banks
pdfUrl: /reports/tokenized-money-for-banks.pdf
readerUrl: /report/tokenized-money-for-banks/print
blogUrl: /blog/tokenized-money-for-banks
locale: en
canonical: https://tempo.xyz/report/tokenized-money-for-banks/
---

# Tokenized Money for Banks: A Bank Treasury Guide to Institutional Settlement on Tokenized Rails

A primer for banks evaluating tokenized deposits, first-party stablecoins, and third-party stablecoin settlement products.

**For:** Bank treasury, ALCO, transaction banking, and digital asset teams

## Three product families, three balance-sheet outcomes

The report works through the tokenized money choices available to banks and shows how each product changes the deposit claim, liquidity ratios, venue reach, and operational burden.

- How tokenized deposits preserve the bank claim
- Where first-party stablecoins re-engineer the liability profile
- When third-party stablecoins reach venues bank claims cannot
- How LCR, NSFR, and RWA shape the product decision

## Key metrics

- **3** — Product families for bank tokenized money
- **100%** — Stablecoin redemption-liability LCR outflow under SCO60
- **85%** — NSFR required stable funding for principal third-party stablecoin inventory

## Read the report

- [Report landing page](/report/tokenized-money-for-banks)
- [Download the PDF](/reports/tokenized-money-for-banks.pdf)
- [Open the reader](/report/tokenized-money-for-banks/print)

---

**_A Bank Treasury Guide to Institutional Settlement on Tokenized Rails._**

## **Executive Summary**

Tokenized money is becoming a bank product because the cash leg is being pulled into new market infrastructure. GFMA’s April 2026 report identifies three active capital-markets use cases for digital money: securities settlement, repo and securities finance, and derivatives margin. In each, the same issue appears: assets, collateral and margin can move faster than the bank money used to fund them. DTCC’s May 2026 collateral work puts numbers behind the problem, estimating that intraday repo on digital rails could cut intraday funding costs roughly in half while reducing liquidity buffers and capital requirements. Institutional clients now require settlement assets that match this velocity to address innovations directly impacting their positions. This primer covers the three products a bank can offer in response. The first family keeps the claim as a deposit. The second converts the claim into a redemption contract against a segregated reserve pool. The third routes the claim through a third-party stablecoin issuer.

Balance-sheet constraints dictate product architecture. Retaining the claim as a deposit defends core funding but degrades token velocity. Building an internal rail via segregated reserves fixes mobility, but fundamentally re-engineers the bank's liability profile. Relying on a third-party asset accesses broader liquidity pools at the cost of leaking the deposit completely off-balance sheet. Every structural pivot is a strict trade-off, hard-coding a distinct penalty or capacity release across LCR, NSFR, and RWA.

**Family 1: Tokenized Deposits: Bank claim tokens** that represent a customer's deposit at the bank. A bank in this family issues a token, the customer holds it in a wallet, and the underlying claim against the bank stays a deposit.

**Family 2: 1st party stablecoin** Stablecoins the bank issues itself, with a segregated pool of reserves backing the redemption obligation.

**Family 3: 3rd party stablecoin.** Products a bank can offer using a 3rd party stablecoin, the dominant institutional dollar stablecoin, as the settlement asset

The rest of the primer covers each family in depth. Section 1 explains why tokenized money is now on the bank product agenda. Section 2 introduces the three families together. Sections 3, 4, and 5 walk through each family product by product, with the journal entries, the ratio impacts, and the conditions under which each fits a bank's franchise. Section 6 names the strategic, regulatory, and operational questions a bank should answer before committing. Section 7 covers the infrastructure layer underneath whichever product the bank chooses.

## **1\. Why we are here**

Bank tokenized money is not a new idea. The first internal blockchain settlement systems at major banks went live in 2019, beginning with J.P. Morgan's JPM Coin, which moved wholesale payments between institutional clients on a private ledger. Citi launched Citi Token Services for internal liquidity management in 2023\. HSBC and BNY Mellon ran parallel pilots over the same period. In all of these, the bank tokenized its own deposit liabilities on infrastructure it controlled, the tokens never left the bank's network, and the customer's experience was a more efficient version of the same wholesale payment the bank had been offering for decades. The technology worked. The customer relationship was preserved. The regulatory questions were small because the products were closed-loop.

What changed between 2024 and late 2025 was the regulatory and product environment around bank tokenized money. The GENIUS Act, enacted in July 2025, created a federal framework in the United States for bank-issued payment stablecoins, requiring issuance through a permitted issuer subsidiary with 1:1 reserves in high-quality liquid assets. In Europe, MiCA’s stablecoin regime began applying in June 2024, creating a harmonized framework for asset-referenced tokens and e-money tokens across the EU. The Basel Committee finalized SCO60, the cryptoasset chapter of the prudential framework, with implementation effective 1 January 2026\. These frameworks together gave banks a defined regulatory perimeter for issuing tokenized money to institutional clients on public infrastructure, not just on internal networks.

The market arrived in parallel. Institutional weekend volume on digital-asset venues passed an inflection point in late 2025\. Hyperliquid's HIP-3 markets, which let qualified builders launch perpetual futures markets on synthetic indices and equities, reached $500 million in daily volume within weeks of launch in October 2025\. Trade.XYZ, an institutional perpetual venue built on Hyperliquid, has cleared the S\&P 500 perpetual under license from S\&P Dow Jones Indices since March 2026, with cumulative volume above $100 billion on an annualized run rate of $600 billion. Every contract on these venues is margined in stablecoins.

## **2\. The families of products**

![Figure 1](/reports/figures/tokenized-money-for-banks-figure-01.png)

**The first family is tokenized deposits.** A bank in this family issues a token that represents a customer's deposit. The customer holds the token in a wallet, and the underlying claim against the bank stays a deposit. Two product variants are possible: a tokenized deposit that moves only within a permissioned garden (1A), and a deposit token that moves “freely” across wallets on a public or institutional blockchain (1B). The bank's deposit franchise is preserved in both cases. The legal nature of the claim, the deposit guarantee, and the regulatory capital framework continue to apply.

**The second family is a 1st party stablecoin.** A bank in this family issues a coin against a segregated reserve pool. The customer's claim converts from a deposit at the bank into a redemption contract against the reserve pool. Three structural choices are possible: the bank can issue on its consolidated balance sheet (2A), through a separately incorporated permitted issuer subsidiary (2B), or through a consortium with peer banks (2C). The strategic value of the family is a settlement rail the bank controls, denominated in money it issues. The cost is the regulatory treatment of the issued liability under Basel SCO60.

**The third family is a 3rd party stablecoin.** A bank in this family offers settlement using a third-party stablecoin as the settlement asset. The customer settles on a digital-asset venue using a stablecoin issued by a third-party, and the claim leaves the bank's balance sheet entirely. Two structural choices are possible: the bank can hold the stablecoin inventory on its balance sheet for delivery on demand (3A, prefunded), or it can extend a fiat loan secured by a blocked customer deposit with the stablecoin delivered to the venue directly from Circle (3B, secured loan). The bank's role is intermediation rather than issuance.

The three families are not interchangeable. Each carries a different prudential cost, fits a different range of institutional venues, and serves a different strategic position for the bank. The next three sections cover each family in depth.

## **3\. Family 1: Tokenized Deposits**

![Figure 2](/reports/figures/tokenized-money-for-banks-figure-02.png)

A bank claim token is a digital representation of a customer's deposit at the bank. The bank issues a token that the customer holds in a wallet, and the underlying claim against the bank remains a deposit on the bank's balance sheet. The token is the wrapper. The wrapper changes nothing about the legal nature of the underlying instrument. The customer's relationship with the bank is preserved, the deposit guarantee continues to apply, and the regulatory capital framework continues to apply unchanged.

Under SCO60.107, the tokenized claim is treated as an unsecured funding instrument when four conditions hold: the token is issued by a regulated and supervised bank, it represents a legally binding claim on the bank, it is redeemable in fiat currency at par value, and its value is supported by the creditworthiness and asset-liability profile of the issuing bank rather than by a segregated pool of reserves. When those conditions hold, the LCR runoff factor and the NSFR ASF category map to the underlying deposit type, with two important constraints. The maturity is set by the earliest contractual redemption right available to the holder. The liability cannot be classified as a stable retail deposit, which means a 24/7 transferable token attached to an institutional operating deposit requires the bank's internal LCR overlay to price the additional velocity.

There are two products in this family. Both keep the claim as a deposit. The difference is transferability, and that difference shapes the venue compatibility and the operational requirements of each.

### **1A. Tokenized deposit**

A tokenized deposit is the first variant in the family. The bank issues a token that moves only within a defined garden of vetted participants. Wallets are KYC'd. Transferability is restricted to permitted counterparties. The network can be the bank's own ledger (the simplest configuration), a permissioned shared ledger between participating banks, or a consortium chain. In all three configurations, the token's lifecycle is closed-loop: the bank mints the token into a customer wallet, the token transfers between wallets inside the network, and the bank redeems the token back into a deposit at the customer's request.

The journal entry is a reclassification of an existing deposit line. No new liability is created. No reserve pool needs to be funded.

**![Figure 3](/reports/figures/tokenized-money-for-banks-figure-03.png)**

The ratio impact is calibrated by the underlying deposit type. An institutional operating deposit moving into a tokenized deposit retains the Basel 25% LCR runoff and the 50% NSFR ASF category for operational wholesale funding below one year, provided the deposit's operating-relationship character is preserved. The bank loses no funding stability by tokenizing the deposit, because no funding stability has been added or removed in the journal entry. The customer's claim and the bank's funding base are unchanged.

A bank can choose 1A when the institutional client's settlement need is within the bank's network. Common use cases are intra-bank treasury movements, settlement between participating banks on a permissioned consortium chain, and atomic delivery-versus-payment exchange of tokenized securities for tokenized cash on a permissioned settlement venue.

### **1B. Deposit token**

A deposit token is the second variant in the family. The bank issues a token that is transferable across wallets the bank does not directly supervise, including institutional custody addresses, vetted counterparty wallets, and (in some configurations) institutional wallets on public blockchains. The token still represents a legally binding claim against the issuing bank. What changes from 1A is the velocity of redemption and the surface area of operational risk.

The journal entry is still a reclassification, identical to 1A. The ratio impact is not:

**![Figure 4](/reports/figures/tokenized-money-for-banks-figure-04.png)**

A deposit token that can move from the bank's network to a counterparty wallet on a Saturday morning faces a stress profile that a tokenized deposit recorded on the bank's ledger does not. The counterparty can post the token as margin on a venue the bank does not operate. The token can be redeemed back into a deposit at the bank on the same Saturday. The bank's internal LCR overlay prices that velocity. The starting point is the 25% Basel runoff for operational wholesale deposits, but the operating-relationship character weakens with every layer of transferability the bank grants. A bank running a deposit token at institutional scale should expect to assign a runoff factor closer to the 40% non-operational wholesale rate.

The live example is JPMD. J.P. Morgan launched its USD deposit token on Base, an Ethereum Layer 2 blockchain built within Coinbase, in November 2025\. JPMD is a permissioned deposit token, meaning only vetted institutional wallets can hold it, but those wallets transact on a public blockchain alongside other tokens issued by other institutions. The token is yield-bearing, a feature the bank can offer on a deposit token because the underlying instrument is a deposit, and deposits can carry interest. A stablecoin issued by a US bank cannot pay yield to holders under the GENIUS Act framework. JPMD is integrated with the Mastercard Token Network, which lets it settle alongside card-network flows in real time, and the bank's institutional clients can use it to fund collateral positions on partner venues without going through correspondent banking.

A bank can choose 1B when three conditions hold together. The bank's institutional clients trade on venues that accept tokenized bank claims as margin or settlement collateral. The bank wants to preserve the deposit franchise rather than convert deposits into redemption contracts. The institutional flow is large enough to justify the engineering investment in protocol-level compliance, custody, and onchain-to-offchain reconciliation.

The constraint on 1B is venue acceptance. Permissionless crypto derivatives venues that require non-restricted, fungible settlement assets do not accept bank-claim tokens with transfer restrictions or jurisdiction-specific KYC requirements. Where the institutional flow clears on those venues, the bank cannot use a deposit token to serve it, and Family 3 becomes the operative choice.

## **4\. Family 2: 1st Party Stablecoin**

![Figure 5](/reports/figures/tokenized-money-for-banks-figure-05.png)

A bank in this family issues its own stablecoin. The bank stops being the holder of the customer's deposit and becomes the issuer of a redemption contract against a segregated pool of reserves. The customer keeps a dollar claim of the same face value, but the legal and prudential character of the claim has changed.

The liability shift is the move that defines the family. Before issuance, the bank funds itself with the customer's deposit, which is a stable wholesale liability under Basel rules. An institutional operating deposit runs off at 25% in the LCR over a 30-day stress horizon and contributes at the 50% ASF rate in the NSFR.

After issuance, the bank funds itself (or its subsidiary or consortium issuer funds itself) with a redemption liability that is treated under SCO60.108 as a 100% LCR outflow on the redeemable amount and a 0% ASF for any maturity less than thirty days. The funding base, measured in regulatory terms, has shifted from the most efficient category Basel recognizes into the least efficient.

Reserves must be 1:1 in cash, central bank reserves, short-dated Treasuries, Treasury-backed reverse repos, and government money market funds.

### **2A. Own balance**

A bank in 2A issues the stablecoin on its own consolidated balance sheet. There is no subsidiary to incorporate, no consortium to negotiate, no inter-group settlement to reconcile. The redemption liability sits directly on the parent bank's books, and the parent's regulatory ratios absorb the issuance in full. This is the simplest legal structure and the most expensive prudential structure.

Two balance-sheet moves are possible when the bank issues on its own balance sheet. They differ in where the cash comes from to back the issuance, and the difference matters for what the issuance actually costs the bank.

**The first move is an external mint.** A new customer brings cash from outside the bank, the bank mints a stablecoin against that cash, and the redemption liability is established alongside a new asset position in central bank reserves:

**![Figure 6](/reports/figures/tokenized-money-for-banks-figure-06.png)**

In an external mint, the bank's HQLA goes up by the amount of the issuance. So does the LCR outflow under the 100% rule. The net LCR impact depends on whether the new reserves are segregated for the stablecoin or merged into the bank's general HQLA stock. If the bank segregates the reserves and does not double-count them in eligible HQLA, SCO60.108(1)(b) allows the bank to offset the 100% outflow up to the segregated amount, net of LCR haircuts. If the reserves are merged into the general HQLA stock, they count toward the bank's existing LCR but cannot offset the new outflow. In practice, banks issuing on their own balance sheet structure the issuance to maximize the offset, which is the entire reason the reserve segregation requirement exists in the GENIUS Act and MiCAR. The ASF assigned to the redemption liability is based on the earliest date the stablecoin could be redeemed, which for a weekend-active settlement product is “now” and assigns 0% ASF, the most punitive NSFR category.

**The second move is a conversion.** An existing customer with a deposit at the bank converts the deposit into a stablecoin. The bank's balance sheet sees a reclassification of liability lines without new cash entering:

**![Figure 7](/reports/figures/tokenized-money-for-banks-figure-07.png)**

The conversion move is the most expensive of the three from the bank's perspective, and the reason is mechanical. Before conversion, the bank was funded by an institutional operating deposit at a 25% LCR runoff and a 50% ASF. After conversion, the bank is funded by a redemption liability at a 100% LCR runoff and a 0% ASF. Because no new HQLA enters the balance sheet in a conversion, the SCO60.108(1)(b) offset is not available. The full 100% outflow hits the LCR without compensation from segregated backing reserves. The bank has paid the cost of the franchise migration without receiving any new cash for it. The customer's claim looks identical from the customer's seat. The bank's funding profile has weakened on both ratios.

A bank can choose 2A when it has the capital headroom to absorb the LCR outflow on the redeemable amount without straining its existing ratio, when it wants the simplest legal and operational structure, and when it accepts that the franchise migration cost will be borne by the parent's funding base. The choice fits banks with deep wholesale deposit franchises and existing LCR buffers well above regulatory minimums.

### **2B. Subsidiary**

A bank in 2B issues the stablecoin through a separately incorporated subsidiary that is a permitted issuer in its jurisdiction. The subsidiary is separately capitalized, separately licensed, with its own reserve pool and its own redemption obligations. The parent's standalone balance sheet does not carry the redemption liability. The parent's group balance sheet carries an equity investment in the subsidiary, and the consolidated regulatory ratios reflect both the parent's existing book and the subsidiary's issuance.

What the journal entry shows for 2B depends on how the cash flows between the parent and the subsidiary. In a first case, the customer converts a deposit at the parent into a stablecoin issued by the subsidiary, and the subsidiary places the reserves back at the parent as a fiduciary reserve deposit. The parent's deposit line moves from a customer operating deposit to an interbank deposit, and the parent keeps the cash on its balance sheet:

**![Figure 8](/reports/figures/tokenized-money-for-banks-figure-08.png)**

The first case is worse for the parent than it appears. An interbank deposit from a financial institution carries a 100% LCR runoff under Basel rules, because financial-institution funding is the most volatile wholesale category. The parent has replaced a 25% runoff customer deposit with a 100% runoff interbank deposit. The cash is still on the balance sheet, but the funding stability has collapsed.

In a second case, the customer converts the deposit into a stablecoin and the subsidiary places the reserves with a third-party custodian or with another bank entirely. The cash leaves the parent:

**![Figure 9](/reports/figures/tokenized-money-for-banks-figure-09.png)**

In the second case, the parent's standalone balance sheet shrinks. The customer's deposit goes out, the cash goes out, and no new liability comes in. From a standalone capital ratio perspective the parent looks cleaner. From a franchise perspective the parent has lost the customer's deposit to its own subsidiary, and the cash to a third-party custodian.

A bank can choose 2B when it wants to protect the parent's standalone balance sheet from the LCR outflow on the issuance, when the regulatory regime requires a subsidiary structure (which the US framework does), and when it accepts that the consolidated group ratio will still reflect the issuance. The structural lesson of 2B is that a separately incorporated subsidiary isolates the parent's standalone capital but does not eliminate the support expectation. Under stress on the subsidiary's redemption queue, the market expects the parent to step in, and the ALCO should price the implicit support line into the consolidated risk view.

### **2C. Consortium**

A bank in 2C participates in issuing a tokenized wholesale settlement asset through a joint venture or industry consortium with peer banks. The consortium structure spreads the issuance risk across multiple banks, dilutes the governance burden, and gives the resulting settlement asset a credibility no single-bank issuance can match. The cost is coordination: every consortium decision has to clear multiple banks' risk committees, multiple supervisors, and multiple jurisdictions.

The bank's role in 2C is participation rather than direct issuance. The bank takes an equity stake in the consortium entity, and the consortium becomes the issuer of the settlement asset. The bank's balance sheet sees an equity investment line, and the cash used to purchase the stake leaves the balance sheet:

**![Figure 10](/reports/figures/tokenized-money-for-banks-figure-10.png)**

The standalone capital impact of the equity stake is small. The strategic value is access to a settlement rail operated by a consortium that includes the bank's peer institutions, with governance the bank can influence through its equity position. The cost beyond the equity is coordination overhead, which compounds with every additional jurisdiction and every additional participant the consortium adds.

A bank can choose 2C when it wants the strategic benefits of a controlled settlement rail without the standalone balance-sheet impact of a single-bank issuance, when the consortium's settlement asset has a credit profile better than a private reserve pool, and when the bank can accept the governance overhead of consortium decision-making. The choice fits banks that participate in wholesale clearing infrastructure already and that see the consortium as an extension of that role.

## **5\. Family 3: 3rd party stablecoin**

![Figure 11](/reports/figures/tokenized-money-for-banks-figure-11.png)

A bank in this family does not issue a token. The bank facilitates the customer's access to a third-party stablecoin and the claim leaves the bank's balance sheet. The stablecoin is issued by a regulated third-party issuer and backed by a reserve pool held in cash, short-dated government securities, reverse repos, bank deposits, money market funds, or other eligible reserve assets under the applicable stablecoin framework. The reserve composition is disclosed under the issuer's regulatory and reporting obligations. The issuance is structured to meet the applicable requirements for regulated payment stablecoins.

The bank has four plausible roles when an institutional client wants to settle in a third-party stablecoin. The bank can act as agent, with no principal exposure to the stablecoin. The bank can prefund the customer, holding third-party stablecoin inventory on its own books. The bank can extend a fiat loan secured by a blocked customer deposit, with the stablecoin delivered to the venue directly from the issuer or from an approved liquidity provider. The bank can act as custodian, holding the customer's stablecoin keys. The two roles that move the bank's funded balance sheet are prefunded product and the secured loan.

### **3A. Prefunded**

A bank in 3A holds a third-party stablecoin as an asset on its own balance sheet, available to deliver to a customer on demand. The bank has converted a portion of its central bank reserves into a stock of stablecoin assets, sized to serve expected institutional weekend draw. When a customer needs the stablecoin for a Saturday settlement, the bank delivers from its inventory and debits the customer's deposit account.

The journal entry has two stages. In the first stage, the bank acquires the stablecoin inventory by purchasing it from the issuer or from a market maker, using cash from its reserves at the central bank:

**![Figure 12](/reports/figures/tokenized-money-for-banks-figure-12.png)**

In the second stage, the customer draws against the inventory, settling the draw against the customer's deposit balance at the bank:

**![Figure 13](/reports/figures/tokenized-money-for-banks-figure-13.png)**

The regulatory cost is concentrated in the first stage. The bank has converted a Level 1 HQLA position (central bank reserves, the highest quality money the bank can hold) into a Group 1b stablecoin asset (a regulated payment stablecoin with a separate prudential treatment). Under SCO60, the third-party stablecoin held on a bank's balance sheet does not qualify as HQLA in the LCR. The same stablecoin attracts an 85% required stable funding factor in the NSFR. The bank's regulatory liquidity position weakens twice: the HQLA stock falls by the amount of the conversion, and the funding requirement rises by 85 cents on the dollar of inventory held.

If the stablecoin fails to meet the Group 1b classification conditions on an ongoing basis, the treatment is more punitive. A Group 2 cryptoasset attracts a 1250% risk weight under the cryptoasset capital framework and counts against the bank's 1% Tier 1 cap on aggregate Group 2 exposures. A bank that prefunds the stablecoin takes a position on the issuer's continuing compliance, on top of a position on the stablecoin itself.

A bank can choose 3A when its institutional clients clear on venues that accept the third-party stablecoin but not bank-claim tokens (which describes most institutional crypto derivatives venues today), when the bank has the capital headroom to absorb the HQLA-to-stablecoin substitution and the 85% NSFR funding penalty without straining its existing ratios, and when the customer revenue from facilitating the stablecoin settlement exceeds the prudential cost of holding the inventory. For banks without that headroom, 3A absorbs balance-sheet capacity that could be deployed against loans or other higher-return assets, and the product rarely clears the standalone P\&L test.

### **3B. Deposit-secured fiat facility**

A bank in 3B does not hold the stablecoin on its books. The customer keeps the deposit at the bank, blocked and pledged as collateral. The bank books a short-term secured loan against the blocked deposit. The loan funds the stablecoin purchase, which is delivered to the customer's whitelisted venue directly from the issuer or from an approved liquidity provider. The bank never holds the stablecoin, which means the prudential cost of the stablecoin sits with the customer, not with the bank.

The journal entry shows reserves moving from the central bank into a secured loan asset, with the customer's deposit unchanged at the line level but encumbered through a security interest:

**![Figure 14](/reports/figures/tokenized-money-for-banks-figure-14.png)**

The ratio impact is calibrated to the secured loan, not to the stablecoin. A short-term loan fully secured by an unencumbered cash deposit at the same bank carries one of the lowest risk weights under the standardized approach to credit risk, with set-off against the deposit available as the default path on customer non-repayment. The LCR sees the reserve drop on the asset side and a contractual inflow from the loan's repayment, capped at the standard cap on inflows. The NSFR sees a short-term loan against stable secured collateral and a 25% LCR runoff operational liability (the blocked deposit) on the funding side. The bank has converted reserves into a loan, which is a category the bank's risk and capital framework already handles every day.

There is no principal stablecoin on the bank's books, so the 85% RSF question does not arise. There is no bank-issued stablecoin liability, so SCO60.108’s 100% LCR outflow does not apply. The bank's regulatory liquidity position holds, save for the cash that left for the loan and the timing of the contractual inflow.

A bank can choose 3B when it wants to serve customer stablecoin settlement without taking principal exposure, when it can price the weekend service as a financing spread (in basis points over the customer's blocked deposit rate) rather than as a stablecoin trading spread, and when its custody architecture and direct delivery relationship with the issuer is set up to handle weekend-active flows. The choice fits banks with strong secured lending capabilities and existing institutional credit lines that can be extended into a tokenized settlement context.

|PRODUCT|CLAIM LOCATION|TRANSFERABILITY|RESERVES|LCR OUTFLOW|NSFR|
|:-|:-|:-|:-|:-|:-|
|**TOKENIZED DEPOSIT**||||||
|Tokenized deposit|Bank|Permissioned (Internal)|Fractional|25–100%|ASF 50%|
|Deposit token|Bank|Permissioned|Fractional|25–100%|ASF 50%|
|**1ST PARTY STABLECOIN**||||||
|Own balance|Bank|Permissioned|HQLA|100%|ASF 0%|
|Subsidiary|Subsidiary|Permissioned|HQLA|100%|ASF 0%|
|Consortium|Central bank|Consortium|HQLA|0%|RSF 0%|
|**3RD PARTY STABLECOIN**||||||
|Prefunded|Issuer|Permissionless|HQLA (issuer)|100%|RSF 85%|
|Secured loan|Issuer|Permissionless|\-|Per facility|Per facility|

## **6\. Considerations for banks evaluating these products**

The framework above is the basis for product selection. The selection itself depends on the bank's specific franchise position, regulatory regime, capital headroom, and operational readiness. This section names the questions a bank should answer before committing to a product.

### **Strategic considerations**

**Which family of products fits the bank's franchise position?** A retail-deposit-heavy bank with limited institutional capital markets activity has a different answer from a transaction banking bank serving hedge funds and corporate treasuries.

A bank with captive institutional clients clearing on its own permissioned venues has a different answer from a bank whose clients clear on third-party public venues. The bank should map its existing institutional client base against the venues those clients use for digital-asset flow, then identify which family's products reach those venues.

**Is the bank trying to defend an existing franchise or to capture a new revenue line?** A bank that already holds the institutional client's primary deposit relationship has reason to defend that relationship against stablecoin leakage by offering a bank-claim token or a deposit-secured fiat facility. A bank that wants to enter institutional settlement as a new business line should evaluate whether the consortium model gives it access to a credible settlement rail without the standalone capital cost of issuing alone.

**Will the bank build product capability in-house or partner for it?** Building a deposit token program or a permitted issuer subsidiary is a multi-year investment in legal, regulatory, technology, and custody capabilities. Partnering with infrastructure providers can compress the timeline but introduces operational dependencies and revenue-sharing arrangements. The strategic answer constrains the regulatory and operational choices that follow.

### **Regulatory considerations**

**Which prudential regime applies, and what is the implementation timeline in the bank's jurisdiction?** Basel SCO60 took effect 1 January 2026 in jurisdictions implementing on the international timeline. Several major jurisdictions, including the United States and the United Kingdom, have not committed to a fixed implementation date and may be operating under transitional frameworks through 2026 and 2027\. The European Union, Canada, the Hong Kong Monetary Authority, and the Monetary Authority of Singapore are implementing on schedule.

**Does the bank's primary regulator accept the subsidiary path for stablecoin issuance, and on what conditions?** US banks issuing under the GENIUS Act must work through the OCC's permitted issuer framework for national banks, or the FDIC's framework for state-supervised insured depository institutions. The OCC issued its notice of proposed rulemaking in February 2026\. The FDIC issued its in December 2025\. The detailed conditions for approval, including capital, governance, and reporting requirements, are still being finalized through the rulemaking process.

**For Family 1 products, how does the bank's regulator treat the tokenized deposit's deposit-guarantee coverage?** Tokenized deposits remain in scope of the deposit-guarantee framework when they meet the statutory deposit definition, both in Europe and in the United States. A bank issuing a deposit token should confirm that its specific product structure preserves the deposit-guarantee coverage that institutional clients will expect.

**For Family 3 products, how does the bank's regulator treat the bank's principal holding of a third-party stablecoin?** The Group 1b classification under SCO60 depends on the issuer's continuing compliance with the prudential conditions, and a bank holding the stablecoin takes a view on that compliance.

### **Operational considerations**

**Can the bank's incident response operate on chains that never close?** Settlement assets on public blockchains create incident windows that conventional payment systems do not. A token issuance contract bug, an oracle failure, a sanctions list update that affects an existing wallet, a custodian outage: each of these can require immediate response, including pausing transfers, freezing balances, or coordinating with the chain's validator set, regardless of whether the event happens at noon on a Tuesday or at four in the morning on a Saturday.

**Is the bank's custody architecture ready for the products in scope?** Holding principal third-party stablecoin inventory requires qualified custody infrastructure. Issuing a stablecoin requires custody for the reserve pool. Issuing a deposit token requires custody for the institutional wallet-level holding addresses. The custody question is different for each family and should be answered before the product launches.

**Are the bank's reconciliation systems set up to match onchain and offchain ledgers in real time?** The bank's existing ERP and treasury platforms were built for batch-based reconciliation against the bank's internal accounts and a fixed set of external counterparties. Real-time reconciliation against a public blockchain requires integration against the relevant blockchain events, the wallet-level state, and the bank's internal records of issuance and redemption.

**What is the bank's wallet-level sanctions screening capability, and how does it scale to the transaction volumes the institutional flow will generate?** The bank's existing AML and sanctions infrastructure was built for SWIFT-message volumes. Onchain transfers generate event streams that require different screening architecture.

> Interactive report gate is available on the HTML page.

---

## Site links

- [Tempo home](/)
- [Privacy policy](/privacy-policy/)
- [LinkedIn](https://www.linkedin.com/company/tempo)
- [X](https://x.com/tempo)
- [YouTube](https://www.youtube.com/@tempo)

### Products

- [Earn](/earn/)
- [Routes](/routes/)
- [Zones](/zones/)

### Solutions

- [Agentic payments](/solutions/agentic-payments/)
- [Credit](/solutions/credit/)
- [Cross-border payments](/solutions/cross-border-payments/)
- [Institutional settlement](/solutions/institutional-settlement/)
- [Stablecoin accounts](/solutions/stablecoin-accounts/)
- [Tokenized deposits](/solutions/tokenized-deposits/)

### Developers

- [Documentation](/developers)
- [Tempo Explorer](https://explore.tempo.xyz/)
- [Tempo API](/developers/docs/api/)
- [Performance](/developers/performance)
- [Status](https://status.tempo.xyz/)
- [GitHub](https://github.com/tempoxyz)

### Resources

- [Blog](/blog/)
- [Customers](/customer-stories/)
- [Learn](/learn/)
- [OUSD](/ousd/)
- [Partners](/partners/)
- [Reports](/reports/)
- [Stablecoin Advisory](/stablecoin-advisory/)

### Company

- [About](/about/)
- [Careers](/careers/)
- [Brand kit](/brand/)
- [FAQ](/faq/)