SWIFT's 24/7 Token Ledger: Real Progress, Real Limits for Digital Asset Accounting
SWIFT is preparing a dedicated ledger capable of routing tokenised-asset transfers around the clock, a meaningful step toward continuous settlement in institutional finance. But the initiative comes with a caveat that every accounting firm and CFO managing digital asset positions needs to understand: the actual finality of those transfers still depends on the underlying payment rails, which have not changed. For teams relying on crypto accounting software to close positions, reconcile balances, and produce auditable records, that gap between transfer instruction and true settlement is not a technicality. It is an open accounting risk.
What SWIFT Is Actually Building
SWIFT's initiative centres on a new ledger layer designed to accept and route transfer instructions for tokenised assets at any hour, any day of the week. The network has framed this as a direct response to pressure from institutional participants experimenting with tokenised securities, tokenised money-market funds, and other on-chain representations of traditional financial instruments.
The instruction layer versus the settlement layer
The distinction matters enormously. SWIFT is building infrastructure for the instruction side of the transaction, the part that says "move this tokenised position from account A to account B." What it is not building, at least not yet, is a new settlement mechanism. The cash leg of most tokenised-asset transactions still clears through conventional correspondent-banking channels and central-bank money systems that operate on fixed windows, often with cut-off times and overnight gaps.
In plain terms: a transfer instruction can be sent and received at 2 a.m. on a Sunday, but the cash that funds the settlement may not move until Tuesday morning when the relevant payment system opens. That mismatch is not new in financial markets, but it takes on added complexity when one leg of a transaction is recorded on a distributed ledger and the other leg runs through RTGS infrastructure with its own timing rules.
Why correspondent banking rails constrain the vision
SWIFT itself has acknowledged that true delivery-versus-payment (DvP) settlement, where the asset leg and the cash leg move simultaneously and finally, remains constrained by the legacy architecture of the payment systems that sit beneath its messaging network. Central-bank settlement systems in most jurisdictions run on schedules. Even where real-time gross settlement exists, cross-border cash finality across multiple currency zones introduces additional latency. Until central-bank digital currencies (CBDCs) or equivalent instruments are widely available at the wholesale level, the cash leg will continue to lag.
Accounting and Audit Implications for Firms and CFOs
For accounting practitioners, the SWIFT announcement raises a set of questions that go well beyond market structure. How a firm records, times, and evidences the settlement of tokenised-asset transactions will depend critically on where exactly in this new pipeline the accounting event occurs.
When does a transfer become a recognised settlement?
Under both IFRS and US GAAP, the derecognition of a financial asset and the recognition of the corresponding consideration generally require that the risks and rewards (or, under IFRS 9, control) have transferred. A transfer instruction routed through SWIFT's new ledger at 11 p.m. does not, by itself, transfer legal title or extinguish counterparty credit risk if the cash leg will not settle until the next business day.
This means that the "trade date" and "settlement date" distinction, long managed through standard accruals, becomes even more important when one leg of the transaction is running on 24/7 infrastructure and the other is not. Firms using crypto bookkeeping software or broader digital asset accounting software need to ensure those tools can capture the instruction timestamp separately from the settlement confirmation, and that the reporting layer reflects the correct date for each.
Reconciliation gaps and audit evidence
The practical reconciliation challenge is straightforward to describe and difficult to solve. If a tokenised-asset transfer instruction is sent over SWIFT on a Friday evening, the on-chain leg may record immediately while the cash leg settles Monday. The firm's books for Friday close with an open position: the asset is gone from the ledger, but the cash has not yet arrived. That is a classic pending-settlement entry, but the audit trail now spans two very different systems, a distributed ledger and a correspondent-banking chain, each with its own data format, timestamp standard, and evidence trail.
Auditors will need to reconcile those two trails. Accounting firms advising clients on digital asset positions should be reviewing now whether their existing close procedures and audit programs can handle this kind of asynchronous evidence, or whether process changes are required before these instruments become material on balance sheets.
Credit risk exposure in the window between instruction and finality
During the period between instruction and final settlement, counterparty credit risk has not been eliminated. If the counterparty fails after the asset transfer is recorded on-chain but before the cash leg settles, the firm faces a replacement-cost exposure. That exposure needs to be measured, disclosed where material, and managed within existing credit-risk frameworks. For CFOs with treasury mandates covering tokenised instruments, the risk window created by asynchronous settlement deserves explicit treatment in credit-risk policies.
Regulatory Context: Where the EU Stands
SWIFT's initiative does not exist in a vacuum. European regulators have been actively shaping the environment for tokenised assets. The EU's DLT Pilot Regime, which allows trading and settlement of tokenised securities on distributed ledger technology under a regulatory sandbox, has already surfaced many of the same settlement-finality questions at a smaller scale. The European Securities and Markets Authority and the European Central Bank have both highlighted that settlement finality, especially in cross-border scenarios, requires clear legal certainty that current frameworks do not always provide.
The broader EU MiCA Review Consultation: what accounting firms and CFOs must act on has opened questions about how tokenised traditional assets interact with the crypto-asset perimeter. Depending on how MiCA's review resolves those boundary questions, some instruments routed through SWIFT's new ledger may fall within or close to MiCA's scope, with corresponding reporting and custody obligations.
Settlement finality under EU law
The EU Settlement Finality Directive establishes when a transfer order becomes irrevocable in designated systems. A SWIFT-routed instruction for a tokenised asset would need to pass through a system designated under that directive, or an equivalent national framework, before finality protections apply. If the instruction layer and the settlement system are not fully integrated within a designated system, there may be a legal gap where the instruction has been sent but finality has not been achieved under statute.
Accounting firms advising EU-regulated entities on tokenised-asset transactions should be tracking how SWIFT's new ledger interacts with the settlement systems designated under the directive, and whether any gap exists that could affect the timing of derecognition in client financial statements.
Operational Readiness: What Firms Should Do Now
SWIFT's ledger is not live at scale yet, and the practical timeline for wide adoption of tokenised-asset routing at institutional volumes remains unclear. But the directional shift is not in doubt. Tokenised securities, tokenised funds, and on-chain representations of other financial instruments are moving from pilot programs into early production at a number of large custodians and asset managers. Firms that wait for the infrastructure to mature before updating their accounting and audit procedures will find themselves behind.
Review your settlement-date accounting procedures
The most immediate practical step is a review of whether current close procedures correctly identify the settlement date for tokenised-asset transactions, not the instruction date, not the on-chain recording date, but the date on which both legs of the transaction have achieved finality. For instruments where the two legs settle at different times across different systems, that review should result in documented procedures covering how the timing difference is recorded, disclosed, and evidenced for audit.
Assess your crypto accounting software's data model
Not all crypto accounting software is built to handle the distinction between instruction, on-chain recording, and final settlement as separate timestamps on the same transaction. If your current tooling collapses those into a single event, it may misstate the settlement date, create incorrect accruals, or produce audit evidence that does not match the actual economic timing. This is a configuration question worth raising with your technology provider before these instruments become material.
Update counterparty credit-risk policies
If tokenised-asset transactions will create a window of unsettled exposure between instruction and cash finality, that exposure needs a home in credit-risk policy. Treasury teams and CFOs should define the maximum acceptable settlement window, the credit limits that apply during that window, and the collateral or netting arrangements that can reduce the exposure. Those policies should also address what happens if a counterparty defaults during the window.
Alongside these operational steps, consider the wider point about digital sovereignty as a board-level risk: infrastructure dependencies, including reliance on a single messaging network for tokenised-asset routing, are now firmly within the scope of board-level technology risk governance.
The Longer Road to True 24/7 Settlement
The honest conclusion from SWIFT's announcement is that the industry is building the instruction layer faster than the settlement layer can follow. That is not a criticism of SWIFT's initiative, which represents genuine progress. It is a structural observation about how financial infrastructure evolves: the messaging and coordination layer tends to move faster than the legal, regulatory, and central-bank plumbing that gives transactions finality.
Wholesale CBDCs are the most-discussed candidate for closing that gap. Several central banks, including the ECB through its exploratory work on a digital euro wholesale instrument, are actively investigating how central-bank money could settle tokenised-asset transactions on a continuous basis. Until that infrastructure is in place and legally designated, the settlement window will persist, and accounting firms and CFOs will need to manage the resulting timing, credit, and disclosure risks explicitly rather than assuming that a 24/7 instruction network means 24/7 settlement finality.
Frequently Asked Questions
Does a SWIFT transfer instruction for a tokenised asset mean the transaction has settled for accounting purposes?
No. Sending a transfer instruction, even over a 24/7 capable network, does not constitute settlement for accounting purposes. Both IFRS and US GAAP require that the risks and rewards, or control, of the asset have transferred and that the consideration has been received or is receivable with finality. If the cash leg has not yet cleared, the transaction remains in a pending-settlement state and should be reflected accordingly in the books.
How should firms handle the timing mismatch between on-chain recording and cash settlement?
The standard approach is to record the on-chain transfer and the pending cash receivable or payable separately, with the settlement date determined by when the final leg achieves legal finality. The period between the two legs should be treated as an open unsettled position, with any counterparty credit exposure measured and, where material, disclosed. Firms should document their chosen accounting policy and apply it consistently.
Which EU legal framework governs settlement finality for tokenised assets routed through SWIFT?
The EU Settlement Finality Directive is the primary framework. It protects transfer orders from being unwound after a designated point in a designated system. Whether SWIFT's new ledger, or the downstream settlement systems it connects to, qualifies as a designated system under the directive is a question firms should seek legal clarity on before treating a transfer as final under EU law.
What should accounting firms check in their crypto accounting software before these instruments become material?
The key configuration question is whether the software records instruction date, on-chain recording date, and settlement finality date as separate fields for the same transaction. If those timestamps are collapsed into one, the tool may produce incorrect accruals or misaligned audit evidence. Firms should also check whether the software can reconcile data from distributed ledger sources with data from correspondent-banking confirmations, since both will be needed to close the audit trail.
Is SWIFT's initiative relevant only to large banks, or should mid-market accounting firms pay attention?
The initial wave of tokenised-asset activity is concentrated in large custodians and asset managers, but the accounting and audit implications flow downstream quickly. Mid-market firms that audit or advise clients with exposure to tokenised funds, tokenised money-market instruments, or on-chain securities should be developing their own competency in these settlement-timing questions now, before those instruments appear on client balance sheets in material amounts.
Source: Decrypt