As we prepare for Sibos, banks are making decisions about how tokenized deposits and regulated stablecoins will fit into their payments businesses. Both can support programmable money movement, but their implications for deposit funding, customer access, and settlement differ. Those differences become particularly important when a payment crosses from one institution to another. A bank can issue a tokenized deposit and still leave its customers with a familiar problem: how to pay someone who banks elsewhere. The answer affects where banks hold liquidity, how they settle obligations, and what services they can offer corporate clients.

Recent U.S. initiatives bring the issue into focus. The Clearing House is developing a bank-led framework for clearing and settling tokenized commercial-bank money across institutions, enabling tokenized deposits to support payments at banking-system scale. BankChain Alliance, formed by 39 state bankers associations, is developing an industry-owned blockchain network to make tokenized deposits, stablecoins, and programmable payments with automated settlement accessible to banks of different sizes. It is targeting a 2027 launch.

In Europe, the Commercial Bank Money Token (CBMT) project is testing how tokenized deposits can move across banks and blockchain networks. Its predominantly German banking base has recently expanded to include BNP Paribas and ABN AMRO.  European stablecoin bank consortium Qivalis has expanded to 37 banks across 15 countries, with issuance pending regulatory authorization.  More recently BANCOMAT’s EUR.BANK initiative is beginning euro stablecoin testing with nine Italian banks.

The collaboration also extends beyond the U.S. and Europe. On September 1, 21 leading financial institutions across North America, Europe, East Asia, the Middle East, and Africa announced plans to establish a global stablecoin issuer, initially focused on a U.S. dollar offering targeted for the first half of 2027. The group plans to expand into other G7 currencies, with the euro as a priority.

Several banks are participating in multiple initiatives, exploring both tokenized deposits and stablecoins. At first glance, the two can look very similar. But as BIS General Manager Pablo Hernández de Cos recently observed:

“Both stablecoins and tokenised deposits use tokenisation to transfer value on programmable rails. But their differences are of first-order importance for the monetary system.” (BIS)

For banks assessing these developments, the choices extend well beyond issuing a token. Banks must decide which forms of money to support, how to connect them to existing payments infrastructure, and how to manage the resulting funding and settlement requirements.

Similar token mechanics, different money

A tokenized deposit represents a commercial-bank deposit. The issuing bank remains liable to the depositor, and the deposit remains part of the bank’s funding and credit model. Tokenization adds a programmable way to represent and use that liability.

A reserve-backed payment stablecoin has a different structure. Its value is supported by the issuer’s reserves, and it can circulate among supported wallets while remaining a claim on the same issuer. Redemption rights, reserve requirements, and transfer restrictions depend on the instrument and its regulatory framework.

Table 1 — Differentiating Tokenized Deposits and Stablecoins

The transfer distinction becomes especially important when a payment crosses a bank boundary. A stablecoin remains a claim on the same issuer as it moves among supported wallets. With tokenized deposits, if the recipient of a cross-bank payment is to receive money issued by their own bank, the payment must coordinate debiting the sender, crediting the recipient with the receiving bank’s deposit money, and settling the resulting interbank obligation.

The participating banks must also satisfy the applicable customer identification and transfer requirements. The scheme needs to define how those responsibilities are met across institutions, including any permitted reliance on another bank’s identity checks. These requirements shape how widely tokenized deposits can circulate and how banks make them interoperable.

Why banks may need both

Banks have reasons to support both tokenized deposits and regulated stablecoins rather than picking a single option.

Tokenized deposits add programmability to existing deposit relationships, including conditional payments and potentially 24/7 transfers. Regulated stablecoins can help banks serve clients operating through external wallets, public blockchains, and cross-border digital commerce. The appropriate instrument depends on the customer’s transaction and the networks available to both parties.

That suggests a dual strategy for digital money. Banks can anchor their strategy in tokenized deposits while selectively issuing, distributing, or servicing regulated stablecoins, including through participation in a stablecoin consortium.

A bank might issue tokenized deposits for corporate treasury services while supporting a third-party stablecoin for clients paying suppliers through external wallets. Another may choose to issue its own stablecoin or join a consortium whose reserve arrangements allow participating banks to hold a share of reserve deposits, subject to applicable requirements.

Each approach brings different responsibilities for custody, redemption, compliance, liquidity, and customer support. Those responsibilities need to be understood alongside the expected benefits for client reach, deposit funding, and service revenue.

Table 2 — A Dual Strategy for Digital Money

Supporting both also creates opportunities to reuse operational capabilities. As we discussed in our Digital Assets Data Nexus introduction, digital assets need to be integrated into financial products and bank operations. Common capabilities for asset lifecycle management, wallets, policy controls, and books and records can reduce the work required to support additional instruments while accommodating their distinct requirements. The strategic question is how to support both without building a separate operating model for each.

Tokenized deposits face a portability challenge

Consider Alice, who holds a tokenized deposit at Bank A, paying Bob, who wants the proceeds in his account at Bank B. In a tokenized deposit model where holders must be onboarded and verified under the issuing bank’s KYC requirements, Bob cannot simply receive Bank A’s token unless he meets those requirements. Even if he does, holding that token gives him a claim on Bank A. To receive the proceeds as a deposit at Bank B, the payment must coordinate the transition between the two banks’ liabilities.

Interoperability models, such as Commercial Bank Money Token (CBMT), address this challenge while allowing participating banks to retain their own deposit liabilities. The precise transaction sequence depends on the scheme. For example, Alice’s tokens may be locked pending completion and then debited or extinguished, while Bank B credits Bob with its own tokenized deposit money. The banks must also record and settle the corresponding interbank obligation. The scheme’s rules determine whether beneficiary credit occurs before, alongside, or after interbank settlement.

Payments practitioners will recognize the underlying obligations. Tokenization creates new ways to coordinate their execution, but the design still has to specify who owes whom, when funds become usable, and when settlement becomes final. A service that credits the beneficiary 24/7 may still depend on settlement infrastructure with more limited operating hours.

This is why interoperability matters to the commercial case for tokenized deposits. Clients need to pay counterparties beyond their own bank, and banks need an agreed way to coordinate those payments and settle the resulting obligations.

Swift’s blockchain-based ledger initiative illustrates this approach. Its shared orchestration layer coordinates payments involving tokenized deposits held on participating banks’ own blockchain ledgers, allowing banks to make funds available to customers around the clock. Participating banks determine how to settle the resulting interbank obligations through their agreed settlement arrangements, which may include netting multiple payments before settlement.

There is more than one way to make bank money interoperable

Several architectures are developing in parallel. They differ in what banks share, where liabilities are recorded, and how settlement is coordinated. The patterns can overlap, and the examples differ in maturity.

Table 3 — Interbank Coordination Approaches

These models have different implications for where banks hold or prefund liquidity, when beneficiaries can use their funds, and when interbank obligations are discharged. Those choices affect funding costs, counterparty exposure, and exception handling.

Where tokenized payments rely on existing interbank settlement flows, banks can use Oracle Banking Payments (OBPM) to process the corresponding settlement instructions, connect to payment schemes, and optimize routing and liquidity usage across payment rails. Integrating these capabilities with tokenized-deposit ledgers and core banking systems helps banks coordinate customer credit, funding, and settlement, while giving operations teams visibility into payment status and exceptions.

Interoperability creates more paths—and more choices

A bank participating in several networks may have multiple ways to execute the same corporate payment. A conventional payment rail, a tokenized-deposit network, and a stablecoin route can differ in availability, funding needs, FX cost, and the form of money the recipient can use.

Consider a supplier payment due over a weekend. A digital route may deliver usable funds sooner, provided the supplier can accept the instrument or redeem it when needed and the bank has sufficient liquidity on that network. However, conversion and funding costs may outweigh the time saved if the supplier does not need the funds until Monday.

Timing also affects the bank’s economics. A corporate treasury team might instruct its bank to transfer $20 million for arrival the following day. A lower-cost conventional fiat route may require the bank to commit funds today. Alternatively, the bank could retain the liquidity overnight to earn yield or avoid funding cost and use a higher-cost, real-time blockchain route tomorrow.

These decisions become harder as liquidity spreads across accounts, correspondent relationships, and digital wallets. Funds may be available in aggregate but unavailable on the network a payment requires. Unified books and records using Oracle AI Database can bring together balances and payment obligations across these systems. Combined with forecasts of incoming funds and transfer and redemption constraints, that view helps banks decide whether to use an existing balance, move funds, or wait for an incoming payment, reducing unnecessary prefunding while meeting payment deadlines.

Banks can begin with routing rules based on currency, destination, amount, available liquidity, and settlement deadline. As payment options grow, analytics and AI can help assess combinations that become difficult to manage through static rules alone.

Incorporating ledger history, smart-contract state, policy evaluations, and workflow outcomes into unified books and records gives banks a richer basis for analysis. Oracle AI Database’s graph, vector, and machine-learning capabilities can support anomaly investigation, liquidity forecasting, and assessment of execution options. Payment policies should define which decisions can be executed automatically and which require review, with enough supporting records to reconstruct each decision.

Payment orchestration helps the bank evaluate the route and funding timing together, balancing payment costs and liquidity needs while meeting the client’s deadline and acceptance requirements. The bank should be able to explain its recommendation: when the recipient can use the money, in what form, and at what total cost.

How banks can stand apart through orchestration

Corporate treasurers can define the outcome they need: a supplier paid by a deadline, a known FX rate, or less cash tied up in prefunded accounts. Banks can use those requirements and the relevant historical context from past transactions to select or recommend an instrument and execution path, within the client’s policies and the bank’s controls.

Table 4 — Optimization objectives and relevant factors

AI agent-initiated payments offer another potential service opportunity. The x402 protocol lets software clients, including AI agents, pay for APIs, data, and other online services through HTTP-based payment exchanges. Banks could operate as x402 facilitators, verifying signed payment payloads against a service provider’s payment requirements, submitting payments to supported blockchains, and returning settlement results. Banks could pair that service with client identity checks, agent spending limits, approval policies, and payment records integrated into corporate treasury systems.

Oracle Banking Payments provides payment-processing and intelligent orchestration capabilities, while Digital Assets Data Nexus adds digital-asset services, wallets, and connectivity. Both stream data into Oracle AI Database, providing a foundation for converged data and AI to support unified books and records and analysis across payment and ledger data. Together, these capabilities can help banks operate conventional and digital-asset payment flows through a unified operating model, with consistent controls, exception handling, and AI-powered supervision. Visibility into balances, obligations, and risk helps banks optimize payment execution and liquidity usage as they extend their existing infrastructure to support new instruments and networks.

Banks can turn these capabilities into services that address specific client needs: payment routing against agreed cost and delivery objectives, liquidity positioning informed by cash forecasts, and coordinated FX and settlement for cross-border obligations. They can also support transactions initiated by authorized AI agents, applying identity checks, spending limits, and approval policies before execution.

That gives banks a foundation for competing on the quality of execution they deliver to clients, rather than simply the number of rails they support.

Join us at Sibos

Join us at Sibos 2026 in Miami for our session, “Digital assets in a real-time, AI-driven banking world” on Monday, September 28 at 3:00 pm (Miami time) in Workshop Room 248+249. We’ll examine how tokenized deposits, stablecoins, and interoperability models affect payment execution, liquidity, and the services banks can offer their clients.  We’ll also explore AI’s role in payment initiation, intelligent routing, and transaction supervision.

Bring your questions about how to fit these approaches into your bank’s plans and what it will take to put them into practice.