HSBC and Standard Chartered Complete First Live Tokenized Deposit Transfer via Swift
HSBC and Standard Chartered have completed what is believed to be the first live tokenized deposit transfer executed across two separate banks using Swift's distributed ledger infrastructure. The transaction is not a proof of concept or a sandbox test. It is a live, production transaction, and it lands less than a month after Swift confirmed its DLT-based blockchain solution went live in July 2026 with 17 banks across six continents lined up to pilot the network. For accounting firms, auditors, and CFOs, the speed of this milestone matters as much as the milestone itself: the gap between framework announcement and live cross-bank settlement is now measured in weeks, not years. Stablecoin accounting and digital asset accounting software policies that were deferred to "when this becomes real" have run out of runway.
Why This Transfer Is Different from Prior Tokenized Deposit Pilots
To understand why this transaction is significant, it helps to understand the structural limitation it has just broken.
The single-bank silo problem
The overwhelming majority of tokenized deposit activity to date has taken place on proprietary, single-institution blockchains. A bank issues a tokenized deposit on its own ledger, and transactions are only possible between that bank's own customers. The value of the instrument is real, but the network effect is absent. It is the equivalent of a payment system that only works if both parties bank at exactly the same branch.
Swift's DLT network addresses this directly. By acting as an interoperability layer between those institutional silos, it allows a tokenized deposit held on one bank's ledger to settle against a counterpart on a different bank's ledger, across borders, and without the correspondent banking delays that characterise legacy SWIFT messaging. The network is also designed for continuous, 24/7 operation, which removes the settlement windows that currently create intraday liquidity risk.
Speed from announcement to live transaction
Swift confirmed its blockchain solution was live in July 2026. HSBC and Standard Chartered completed this cross-bank transfer the following month. For institutions of this size and with the compliance overhead they carry, that timeline is remarkable. Both banks' existing involvement in tokenized deposit initiatives is likely part of the explanation. HSBC and Standard Chartered have each participated in programmes coordinated by the Hong Kong Monetary Authority, as well as Bank for International Settlements initiatives. HSBC has also been active in multibank tokenized deposit programmes in the UK and the United States. Standard Chartered has its own parallel involvement in cross-border tokenized deposit work. That accumulated institutional experience shortened the journey from framework to live execution.
The Accounting Implications for Firms and CFOs
A tokenized deposit is, at its core, a claim on a bank denominated in fiat currency and recorded on a distributed ledger rather than in a traditional core banking system. The accounting treatment is therefore not the same as for a crypto-asset or a stablecoin issued by a non-bank entity, but it is not straightforwardly identical to a conventional bank deposit either. The distinction matters enormously once these instruments start flowing across institutions at production scale.
Recognition and derecognition at settlement
Under IFRS 9, a financial asset is derecognised when the contractual rights to its cash flows expire or are transferred. In a conventional correspondent banking chain, the moment of derecognition is often ambiguous because messages pass through intermediaries and settlement is not instantaneous. DLT-based settlement, if designed with atomic finality, collapses that ambiguity. Derecognition on the sender's ledger and recognition on the recipient's ledger can, in principle, occur at the same moment.
Whether Swift's current implementation actually achieves atomic finality, or whether it relies on a sequential confirmation model, is a question accounting teams must resolve with their technology counterparts before drafting policy. The source material does not confirm the settlement mechanics at that level of detail, and firms should not assume finality without verification. What is clear is that the network is designed to support 24/7 settlement, which itself creates new questions about the accounting period in which a transfer is recognised, particularly for cross-border transactions spanning multiple time zones.
Classification: deposit, e-money, or something else
A tokenized deposit issued by a regulated bank and redeemable one-for-one in fiat currency sits in a different accounting category from a stablecoin issued by a non-bank payment institution or a decentralised protocol. Under current IFRS, a bank deposit is a financial instrument measured at amortised cost. If the tokenized deposit retains that legal character regardless of the medium of issuance, the classification should follow. However, if the instrument is structured differently, for example as a bearer token without the depositor's name explicitly attached to the bank's liability, the analysis changes.
Firms advising clients who hold or plan to hold tokenized deposits via Swift-connected networks should document their classification rationale now, before positions are established at scale. Retrofitting accounting policy to a live balance sheet is far harder than building the policy before the first transaction hits the ledger. The same discipline applies to any digital asset accounting software or crypto bookkeeping software that will be used to capture and report these positions: it must be capable of recording the instrument type, the issuing institution, the settlement mechanism, and the currency denomination separately, not treating every token-denominated asset as a generic crypto entry.
Functional currency and FX considerations
Cross-border tokenized deposit transfers introduce a layer of FX complexity that single-bank, single-currency pilots avoided. If a Hong Kong entity receives a tokenized deposit denominated in a foreign currency via the Swift DLT network, IAS 21 requires translation at the spot rate on the transaction date, with monetary items retranslated at the closing rate at each reporting date. The 24/7 settlement window means that "transaction date" must be defined precisely in the accounting policy, and system timestamps from the DLT ledger will need to feed directly into the general ledger to avoid manual restatement errors.
Regulatory Context Across Key Jurisdictions
Hong Kong
The Hong Kong Monetary Authority has been an active coordinator of tokenized deposit initiatives, and both HSBC and Standard Chartered have participated in HKMA-led programmes. The HKMA's Project Ensemble has explicitly explored interoperability between tokenized money forms. This live Swift transaction builds on that foundation and is likely to draw regulatory attention as a data point for the HKMA's ongoing policy development on wholesale digital money.
United Kingdom
HSBC is a participant in UK multibank tokenized deposit initiatives. The Bank of England and the Financial Conduct Authority have been studying the wholesale digital pound and tokenized deposit frameworks separately. A live cross-border transaction involving a UK-regulated entity and a non-UK counterpart raises questions about which regulatory perimeter governs the instrument at the point of transfer, and whether existing e-money or deposit-taking rules apply at the moment of settlement.
United States
HSBC's involvement in US tokenized deposit initiatives means the Swift network now potentially connects US-regulated entities to cross-border DLT settlement for the first time at production scale. Given the active legislative environment around stablecoins and digital money in the US, accounting teams at US entities receiving or sending tokenized deposits via Swift should monitor whether Treasury or banking regulators issue guidance specifically addressing the treatment of these instruments as the network scales.
What Accounting Firms and CFOs Should Do Now
Audit the current policy gap
Most accounting policy frameworks written before 2025 do not contemplate cross-bank DLT settlement. Firms should identify clients in financial services, corporate treasury, or trade finance who are most likely to encounter tokenized deposits on Swift-connected networks within the next 12 to 18 months and assess whether their existing accounting policies cover recognition, measurement, derecognition, and disclosure for these instruments.
Engage technology and operations teams early
The accounting treatment of a tokenized deposit is partly a function of its technical design. Settlement finality, custody arrangements, and the legal enforceability of the claim all affect classification and measurement. Accounting leads who wait for the finance team to receive the first transaction before asking these questions will be behind. The time to engage is now, while the network is still in its early rollout phase and technical documentation is being produced.
Review digital asset accounting software readiness
Any crypto accounting software or digital asset accounting software in use must be capable of distinguishing tokenized bank deposits from stablecoins, from crypto-assets, and from e-money balances. These are not the same instrument and should not share the same accounting treatment. If current tooling cannot make that distinction at the transaction level, the gap needs to be addressed before live positions appear on the balance sheet. For related context on how stablecoins are being approached from an accounting and assurance perspective, see our coverage of stablecoin accounting and assurance under ICAEW guidance.
Watch for network expansion
Seventeen banks across six continents are preparing to pilot the Swift DLT network. HSBC and Standard Chartered's live transaction will accelerate that process. The network effect of tokenized deposits improves dramatically with each additional institution that joins. Firms with clients across multiple jurisdictions should track which local banks are joining the network and update client risk assessments accordingly. For a parallel perspective on how regional regulators are approaching DLT-based interoperability, our analysis of Singapore's Project Pigeon and permissionless blockchain risk for APAC banks provides useful comparative context.
Frequently Asked Questions
Is a tokenized deposit the same as a stablecoin for accounting purposes?
No. A tokenized deposit issued by a regulated bank is a liability of that bank, recorded on a distributed ledger but retaining the legal character of a bank deposit. A stablecoin issued by a non-bank entity is a different instrument with a different legal and regulatory basis. The accounting classification, and therefore the measurement approach, can differ significantly between the two. Firms should document the distinction clearly in their accounting policies.
Does DLT settlement finality change how derecognition is recorded under IFRS 9?
In principle, yes. If the DLT network achieves atomic finality, the moment of derecognition for the sender and recognition for the recipient can be precisely determined from the ledger timestamp. However, firms must verify the actual settlement mechanics of the specific network before writing policy. Not all DLT systems achieve true atomic finality, and the accounting treatment must reflect the actual mechanics, not an assumption.
Which accounting standard governs the FX translation of a cross-border tokenized deposit transfer?
IAS 21, The Effects of Changes in Foreign Exchange Rates, applies to monetary items denominated in foreign currencies, including financial instruments such as bank deposits. A cross-border tokenized deposit transfer must be recorded at the spot rate on the transaction date, with the balance retranslated at the closing rate at each reporting period. The 24/7 settlement window means the transaction date must be defined precisely in the accounting policy, tied to the DLT ledger timestamp.
What should CFOs prioritise before their institution handles tokenized deposits on the Swift network?
Three things: first, confirm the accounting classification with reference to the legal terms of the specific instrument; second, ensure the general ledger and any digital asset accounting software can capture the instrument type, issuing institution, denomination, and settlement timestamp separately; third, review disclosures to ensure that tokenized deposits are presented appropriately in financial statements, distinct from crypto-assets and from conventional deposits if the presentation would be misleading.
How quickly might other banks join the Swift DLT network?
Swift announced 17 banks across six continents preparing to pilot the network in July 2026. HSBC and Standard Chartered completed a live cross-bank transfer within a month. The pace suggests momentum is building faster than previous tokenized deposit initiatives. Accounting firms and CFOs at institutions not yet involved should monitor their primary banking partners' participation, as the network's reach will affect the likelihood and timing of their own first exposure to these instruments.
Source: Ledger Insights