RTGS on DLT: How Real-Time Settlement Changes Banking

Real-time gross settlement has been the backbone of high-value payments in the regulated financial system for more than three decades. Every major economy operates an RTGS system — Fedwire in the United States, CHAPS in the United Kingdom, TARGET2 in the eurozone, PRISM in Pakistan — and the aggregate daily value settled across these systems runs to many trillions of dollars. The systems do their core job. What they do not do, in their legacy form, is match the expectations of the participants that build on top of them: 24/7 operation, programmable settlement, shared visibility, and the ability to settle against tokenised assets rather than only against central-bank-money claims.

Distributed ledger technology changes the substrate. An RTGS system implemented on DLT retains the finality, the central-bank-money anchor and the supervisory oversight of the legacy form, while adding shared infrastructure, continuous availability, richer data, and atomic settlement against tokenised instruments that move on the same ledger. The shift is not cosmetic. It changes how commercial banks hold reserves, how treasuries manage liquidity, how capital markets settle trades, and how cross-border payments complete. This pillar article sets out what RTGS on DLT actually is, why it matters, what changes for each category of participant, and how Bridge's implementation on Corda 5.2 fits into the broader landscape.

Real-time gross settlement is defined by two properties. Settlement is real-time — payments settle continuously through the operating day rather than netting at end-of-day. And settlement is gross — each payment settles individually rather than being offset against counter-payments in a net batch. RTGS systems are the settlement asset of last resort for wholesale payments: claims that settle on an RTGS are final, central-bank-money claims that extinguish obligations fully.

The counterpart to RTGS in most systems is a deferred net settlement scheme for retail or low-value payments, where economies of scale justify netting at the cost of longer latency and additional settlement risk. The structural trade-off is clear: RTGS gives finality but requires each participant to fund each payment in full; DNS is liquidity-efficient but carries unwind risk in the event of participant default.

In practice RTGS is the settlement venue for interbank payments above the scheme's minimum threshold, for the cash leg of securities trades settled on a delivery-versus-payment basis, for foreign-exchange trades settled through CLS-equivalent schemes, and for the central-bank operations — open-market operations, standing facilities, reserves management — that underlie monetary policy. The RTGS system is, in infrastructure terms, the most critical shared service in the economy.

The stakes in RTGS reform are therefore high. A system that is indispensable to the payment system and to monetary policy cannot be replaced casually, and incumbents are appropriately cautious about change. But the pressure for modernisation is also real, because the demands on the settlement layer have changed.

The design premises of legacy RTGS systems are a product of their time. Three constraints stand out.

The first is operating hours. Most RTGS systems operate during an extended business day rather than 24/7. Cut-off windows and end-of-day processes mean that payments initiated outside operating hours queue for the next day, and that cross-timezone flows collide with local cut-offs in ways that delay settlement. An economy that runs on continuous commerce — payment rails, securities markets, cross-border flows — is served by a settlement layer that does not.

The second is data. Legacy RTGS messaging used SWIFT MT-style structures, which lack the rich data that modern compliance, reconciliation and analytics workflows expect. Most major systems completed the ISO 20022 migration by November 2025, which is a significant improvement, but the underlying architectural assumption — that messaging and settlement are separate events tied together by central clearing — remains. Our separate article on ISO 20022 and tokenised settlement addresses the data layer in more depth.

The third is interoperability with tokenised assets. Legacy RTGS systems settle claims on central-bank money against book-entry records held by participant banks. They do not natively settle against tokenised assets that exist on other ledgers. Delivery-versus-payment on tokenised securities, for example, requires coordination between the RTGS cash leg and the tokenised asset leg through external mechanisms, which reintroduces timing risk and reconciliation cost. Genuine atomic settlement of cash against tokenised asset requires the two legs to live on the same ledger or on ledgers interoperable by design.

These constraints are not faults; they are features of a system built for a different era. The question is whether the modernisation path is incremental — longer hours, richer messages, adjacent tokenisation sandboxes — or architectural. The case for architectural change is the case for RTGS on DLT.

Settlement finality is the moment at which a payment becomes legally and operationally irrevocable. In a legacy RTGS it is defined by scheme rules and achieved by the central bank debiting one participant's reserve account and crediting another's. In a DLT-based RTGS it is defined by the ledger's consensus rules and achieved by the inclusion of the transaction in a canonical ledger state shared among participants and supervisors.

Two architectural choices matter for how this works. The first is the ledger's consensus model. A permissioned ledger operated among regulated institutions — Corda is the leading example in regulated finance — uses notarisation to deliver settlement finality deterministically, without the probabilistic finality of public-chain consensus. When a transaction is notarised by an authorised notary, participants can treat it as final, full stop. This is a legally meaningful property and it is the model most relevant to central-bank and commercial-bank settlement.

The second choice is the settlement asset. A DLT-based RTGS can settle against several forms of on-ledger money: a wholesale central bank digital currency (wCBDC), a tokenised reserve liability of the central bank, a tokenised deposit issued by a commercial bank, or a regulated stablecoin. The legal and operational properties differ — wCBDC gives the strongest finality, tokenised deposits and stablecoins introduce credit exposure to the issuer — but the ledger infrastructure can accommodate any of them. A practical system will support more than one.

Atomic settlement is the single largest operational gain. When the cash leg and the asset leg of a transaction both live on the same ledger, they can be bound into a single transaction that either completes in full or not at all. Delivery-versus-payment becomes a native property rather than a coordination problem. The same principle applies to payment-versus-payment in foreign exchange, and to more complex multi-leg transactions such as collateral swaps, repo and triparty arrangements.

The combination of deterministic finality, shared state and atomic multi-leg transactions is what makes DLT-based RTGS different from a faster legacy RTGS. The difference is architectural rather than incremental.

RTGS on DLT changes not only the transaction mechanics but the supervisory model. In a legacy RTGS the supervisor sees the net settlement position of each participant on the central bank's books but has limited real-time visibility into the transaction-level activity that produced it. The gap is filled by reporting — regulatory returns, supervisory data calls, transaction reporting under applicable regimes — which is necessarily retrospective.

On a shared ledger, the supervisor can be a participant with read access to transaction-level state. This is not a blanket loss of transaction privacy among participants — permissioned ledgers designed for regulated use, such as Corda, use per-transaction privacy so that only parties to a given transaction see its detail — but it does mean that the supervisor, with appropriate authority, has a richer and more timely view than legacy reporting provides. The direction of travel is toward supervisor-as-node rather than supervisor-as-reporting-target.

This change has implications for how supervisory intervention works. A supervisor with direct visibility into live settlement state can identify patterns sooner, can intervene with more precision — freezing a specific account or transaction rather than shutting a participant out of the scheme — and can reduce the cost of routine reporting because the data is already shared. The trade-off is that the supervisor's own resilience becomes part of the infrastructure: supervisor nodes must be operated to the same standard as participant nodes.

Multi-party consensus also changes participant governance. A DLT-based RTGS is typically operated under a scheme rulebook that governs onboarding, notarisation, change control and the operation of the ledger itself. The rulebook is a central piece of the design and is typically developed in consultation between the central bank, the participants and the technology provider. Firms planning to participate in or to integrate with a DLT-based RTGS should expect to engage with rulebook design as well as with the infrastructure build.

The near-term use cases for RTGS on DLT fall into three categories.

Central banks are the primary use case. A wholesale CBDC operated on a DLT-based RTGS gives the central bank a native settlement asset for tokenised finance while preserving the familiar monetary-policy operating model. Pilots across multiple jurisdictions have demonstrated the technical viability; the pace of production rollout is determined by governance, legal and interoperability considerations rather than by technology. Pakistan's digital payments trajectory, covered in our SBP digital payments article and in the broader Pakistan digital payments opportunity, includes these discussions as part of the forward agenda alongside the current domestic instant-payment scheme Raast.

Commercial banks are the second category. Banks issue tokenised deposits that settle on the same infrastructure as central-bank money, which lets clients move value across institutions at RTGS-level finality without going through a legacy correspondent chain. Tokenised deposits are not a speculative product — they are a representation of the same deposit liability the bank already has on its balance sheet, with a different settlement mechanism. The benefit to corporate clients is 24/7 treasury, programmable payments, and atomic settlement against tokenised assets held elsewhere.

Capital markets are the third. Tokenised securities settle against tokenised cash on a DLT-based RTGS with native delivery-versus-payment, eliminating the settlement-window risk that has historically required significant collateral buffers. Repo, collateral management and triparty arrangements can be restructured to reduce working-capital needs. Cross-venue settlement — trades executed on one platform settled on a shared infrastructure — becomes cleaner. The implications for market structure are material, and early adopters are already testing the operational model in controlled environments.

Cross-border use cases span all three categories. A DLT-based RTGS in one jurisdiction that interoperates with an equivalent in another — through a bridging ledger, a shared corridor infrastructure or a federated network — compresses cross-border settlement from days to minutes. This is the infrastructure story behind the modern corridor architecture described in our cross-border payment infrastructure pillar and the corridor-building guide.

Moving from pilot to production on a DLT-based RTGS raises five implementation questions.

The first is scheme design: who operates the notary, who sets the rulebook, how participants onboard and exit, how the ledger is versioned and upgraded, how incidents are managed. These are governance questions as much as technology questions, and they are typically the longest lead-time items in a rollout.

The second is legal certainty. Settlement finality must be grounded in law, not only in ledger state. Most jurisdictions have settlement finality directives that cover legacy RTGS; extending them, or enacting equivalent provisions, for DLT-based settlement is a precondition for credible rollout. Regulators have been active on this front, and the direction of travel is clear, but specific legal questions — whether a notary signature is sufficient, how insolvency affects on-ledger positions, how cross-border conflicts are resolved — require jurisdiction-specific answers.

The third is interoperability. A DLT-based RTGS does not exist in isolation. It must interoperate with the legacy RTGS during a transition period of indefinite length, with domestic instant-payment schemes, with securities settlement systems, and with foreign RTGS systems. The interoperability layer is where much of the engineering cost sits and where many of the operational risks cluster.

The fourth is resilience. An RTGS system is systemically critical infrastructure. Availability, disaster recovery and cyber-security expectations are at the highest end of what any infrastructure supports. DLT architectures have specific resilience properties — decentralised state replication, deterministic finality — but they also introduce specific risks, including consensus halts, notary compromise and smart-contract errors. Production rollouts include extensive operational testing, including adversarial testing, before live traffic is admitted.

The fifth is adoption. A network is only as useful as the set of participants it connects. Central banks that launch DLT-based RTGS systems typically onboard participants in waves, starting with the largest and highest-readiness institutions and extending to the long tail over time. Participants planning to engage should start readiness work early: their core banking systems, treasury systems and settlement operations all need to be capable of interacting with the new infrastructure at production scale.

Bridge Intelligence's settlement infrastructure is built on Corda 5.2 for regulated DLT settlement, wrapped with the identity, custody, ledger and compliance layers required to operate in a regulated environment. Corda's permissioned design, deterministic notarisation and per-transaction privacy model make it a natural fit for an RTGS-class workload. The same properties that let a central bank operate a wholesale CBDC on Corda let a regulated commercial bank or a corridor operator participate in a shared settlement network without exposing transaction detail to other participants.

The Bridge stack is modular. The settlement platform is the DLT-based settlement rail. The custody platform provides the key management and wallet infrastructure for participants that hold tokenised assets. The identity platform provides KYC, sanctions screening and Travel Rule capability as native services rather than as adjuncts. The combination means that a participant joining a Bridge-operated network or building its own on Bridge infrastructure inherits a reference implementation rather than assembling components.

Bridge's work with Pakistan's ecosystem — including the PVARA perimeter, the Raast integration and the tokenisation frameworks — illustrates the approach in a specific jurisdiction. A regulated firm operating on Bridge infrastructure can settle against tokenised fiat, tokenised securities or tokenised real-world assets, with the same compliance and finality properties across all of them. The Pakistan tokenisation page and the tokenisation platform cover this in more detail.

The trajectory for RTGS on DLT is not a binary replacement of legacy systems. It is a parallel build-out, with DLT-based settlement addressing the use cases where it provides the clearest benefit — wholesale CBDC, tokenised securities settlement, cross-border corridors — while legacy RTGS continues to handle the flows it already serves well. Over time the centre of gravity shifts as the DLT-based layer accumulates adoption, and the legacy layer becomes a compatibility envelope for flows that have not yet migrated.

Institutions that position for this shift early — by participating in pilots, by building the internal capability to interact with DLT-based settlement, by testing tokenised deposits and settlement in controlled environments — acquire a multi-year lead on those that wait. The technology and regulatory pieces are in place. The remaining question is operational readiness, and operational readiness is an earned capability, not a bought one.

If you are evaluating participation in or integration with a DLT-based RTGS — as a central bank, a commercial bank, a capital markets participant or a regulated fintech — Bridge's settlement platform is designed for this workload and operates alongside the custody and identity components that production settlement requires. Reach out via our contact page to arrange a technical review.