For years, the case for tokenised bank deposits was made in the language of infrastructure: settlement efficiency, atomic delivery-versus-payment, reduced reconciliation. In 2026, the conversation inside corporate treasuries has shifted to a more practical question: which balances should sit on a tokenised rail, and what does that decision do to liquidity, counterparty risk and working capital? The answers are beginning to emerge from live deployments rather than pilot reports.
The Spectrum of Money Inside One Treasury Function
Traditional bank deposits now sit alongside tokenised deposits, stablecoins, tokenised money market funds and other digital representations of value. They are distinct instruments, but collectively they expand how value can be stored, transferred and deployed. A conventional deposit may remain the right choice for day-to-day operating balances. A tokenised deposit may be better suited to round-the-clock intragroup liquidity movement, where the ability to shift value outside banking hours has direct operational value.
That distinction is more consequential than it sounds. Treasury teams have historically managed liquidity around cut-off times, batch cycles and pre-funded accounts. Tokenised deposits compress those constraints. DBS’s experience with live tokenised deposit transactions shows clients transacting USD and SGD payments “any time, any day, including over a weekend”. For a corporate group with entities across time zones, the difference between a Friday afternoon settlement and a Sunday liquidity transfer is not a technical curiosity—it is working capital that no longer sits idle.
Interoperability Is the Real Treasury Test
The corporate use case weakens if tokenised deposits work only inside one bank’s network. Treasuries do not operate in single-bank silos; they manage relationships across multiple institutions, currencies and jurisdictions. Standard Chartered’s August 2026 cross-border bank-to-bank tokenised deposit transaction on Swift’s ledger illustrated how an orchestration layer can match and net obligations across separate bank infrastructures before final settlement through existing systems. The model does not require every bank to use the same ledger or the same technology stack. It requires a shared standard for how obligations are represented, matched and settled.
Project Guardian’s open-and-interoperable-network framework addresses this directly through trust anchors and verifiable credentials, allowing institutions to interact on open networks while restricting participation to verified counterparties. For treasurers, the practical implication is that tokenised deposit adoption is not an all-or-nothing migration. It is a portfolio decision: some balances remain conventional, some move to tokenised rails, and the treasury operating model must accommodate both without duplicating controls or losing visibility.
What Changes on the Balance Sheet
Tokenised deposits remain bank liabilities. They carry the same legal claim against the issuing bank as a conventional deposit, and they do not turn a corporate treasurer into a cryptoasset investor. That legal continuity is what makes them palatable to risk committees that would reject unregulated stablecoins. What changes is programmability and availability: smart contracts can automate intraday liquidity sweeps, conditional payments and collateral movements that previously required manual intervention or delayed settlement.
The unresolved question is not whether treasuries will use tokenised deposits. It is how quickly the supporting infrastructure—interbank interoperability, legal finality for on-chain records, and common asset-servicing standards—catches up with the commercial products already in the market. Standard Chartered, DBS, OCBC and UOB have given corporate clients live rails to test. The treasury operating model now has to evolve around them.
