Settlement Systems
Settlement systems discharge financial obligations by transferring a defined settlement asset between participants under rules that establish timing, liquidity use and finality.
An accepted payment is not necessarily settled. A message can reach the receiving institution, a clearing function can calculate the amount due, and a beneficiary can even receive a provisional credit before the underlying obligation has been finally discharged.
Rulebook and law
Direct participants
Settlement system
Asset, liquidity and finality
Clearing obligations
Finality event
Settlement record
Liquidity access
Settlement asset
Settlement Determines When a Payment Becomes Final
Settlement architecture determines what asset moves, which accounts record the transfer, how liquidity reaches those accounts, when the transfer becomes irrevocable and who absorbs the consequences when a participant, connection or linked ledger fails.
A payment instruction asks institutions to move value. Settlement completes the financial obligation created by that instruction.
The distinction matters because speed at the customer interface does not identify the point at which exposure ends. A payer may see an immediate debit while the participating institutions settle later. A beneficiary may receive funds immediately because its bank advances value before interparticipant settlement. A transaction may also reach technical completion on one ledger while its legal finality depends on a rulebook, another system or an external settlement asset.
A complete settlement arrangement answers six questions:
- What obligation is being discharged? The obligation may arise from one payment, a bilateral position, a multilateral net position, a foreign-exchange trade or the cash leg of an asset transfer.
- Which asset discharges it? The asset may be central-bank money, commercial-bank money, tokenised central-bank money, a tokenised deposit or another legally defined claim.
- Where does the transfer occur? Settlement may occur on a central-bank ledger, a commercial-bank ledger, a payment-system ledger, a distributed ledger or across linked records.
- When does settlement occur? The system may settle each instruction immediately, settle batches at defined intervals or combine real-time processing with deferred settlement.
- When does finality arise? The legal rule, system record and operational event need to identify the point after which the transfer cannot be revoked through the ordinary process.
- Who carries risk before and after that point? The answer depends on prefunding, credit, guarantees, loss allocation, liquidity support and the treatment of failed participants.
These choices determine participant credit exposure, intraday liquidity demand, collateral use, recovery procedures and the credibility of every downstream status. They also determine whether the system can support continuous operation, cross-currency payment-versus-payment or linked settlement with tokenised assets.
How a Payment Obligation Reaches Final Settlement
Settlement belongs to a longer sequence. Each stage creates a different state, record and responsibility.
| Stage | What occurs | Principal record | Exposure that remains |
|---|---|---|---|
| 1. Instruction | A customer, institution or authorised agent requests a transfer | Payment instruction and authorization evidence | The request may still fail validation or authorization |
| 2. Validation and acceptance | A participant or system verifies eligibility, format, authority, limits and service availability | Acceptance, rejection or pending status | Acceptance creates processing responsibility but may not discharge the financial obligation |
| 3. Clearing | The arrangement validates transactions and calculates gross, bilateral or multilateral obligations | Accepted transaction set and clearing positions | Participants remain exposed until the resulting obligations settle |
| 4. Funding | Participants obtain balances, prefund accounts, pledge collateral, draw intraday credit or receive incoming liquidity | Balance, collateral, credit and reservation records | A shortfall can delay settlement even when the payment is valid |
| 5. Settlement submission | The system sends or creates the instruction that will transfer the settlement asset | Settlement instruction, queue entry or atomic condition | The instruction can remain queued, time out or fail a linked condition |
| 6. Ledger transfer | The relevant account or token balances change | Authoritative debit and credit entries | Legal finality may arise at this event or at another point defined by law and rules |
| 7. Finality | The transfer becomes irrevocable and unconditional within the applicable framework | Final settlement status supported by the rulebook and authoritative ledger | Operational, fraud, legal or restitution claims may continue without reopening the original settlement entry |
| 8. Posting and reconciliation | Participants update customer and internal ledgers, confirm outcomes and match records | Customer postings, confirmations and reconciliation evidence | Posting delays or record inconsistencies can remain after interparticipant settlement |
The sequence can compress without disappearing. A real-time gross settlement system may accept, fund and settle an instruction within seconds. A deferred net settlement system may process payments throughout the day and settle only the resulting net positions. A programmable platform may evaluate all required conditions and update several legs atomically.
The system still needs an authoritative answer for every state. “Sent,” “processed,” “completed” and “credited” carry limited meaning unless the operating model maps each label to acceptance, clearing, settlement, finality or beneficiary posting.
The broader path from initiation through records and exceptions belongs to the payment lifecycle. Settlement systems own the narrower transfer that discharges participant obligations.
Clearing Calculates the Obligation; Settlement Discharges It
Clearing and settlement can operate on the same platform and occur within the same processing sequence. They remain distinct functions.
| Question | Clearing | Settlement |
|---|---|---|
| Primary function | Validate transactions, match information and calculate what participants owe | Transfer the settlement asset and discharge the calculated obligation |
| Input | Accepted payment or trade records | A gross instruction or clearing position ready for settlement |
| Output | Gross, bilateral or multilateral obligations | Authoritative debit and credit entries in the settlement asset |
| Balance affected | Calculated positions or provisional records | Accounts or token balances that represent the settlement asset |
| Main efficiency tool | Netting, aggregation and offsetting | Queue management, liquidity reservations, credit and liquidity-saving mechanisms |
| Risk before completion | Incorrect calculation, unmatched records and changing participant exposure | Credit, liquidity, principal, legal and operational risk |
| Failure consequence | Obligations may need recalculation | Valid obligations remain undischarged or enter a defined failure procedure |
In a gross model, clearing may involve little more than validation and routing because each accepted instruction proceeds separately to settlement.
In a net model, the clearing function can transform a large set of payments into much smaller settlement obligations. The reduction in required liquidity comes with a longer period of mutual exposure and a stronger dependency on the rules for participant default, recalculation and loss allocation.
Netting itself does not settle an obligation. It replaces multiple gross obligations with a legally enforceable net obligation. Settlement occurs only when that net amount moves in the agreed settlement asset.
The distinction also clarifies incident ownership. A calculation error belongs to the clearing process. A liquidity shortfall belongs to the settlement process. A customer posting delay can arise after both functions have completed.
Settlement Systems Combine Multiple Design Choices
Labels such as RTGS, deferred net settlement or tokenised settlement describe only part of an architecture. A complete classification combines several independent choices.
| Design dimension | Principal options | Structural consequence |
|---|---|---|
| Unit of settlement | Individual instruction, bilateral position or multilateral position | Determines whether obligations settle gross or after netting |
| Timing | Real time, frequent batch, scheduled cycle or end of day | Determines the duration of exposure and the time available to obtain liquidity |
| Settlement asset | Central-bank money, commercial-bank money, tokenised central-bank money, tokenised deposit or private reserve-backed claim | Determines the credit, liquidity, redemption and legal characteristics of the value transferred |
| Funding model | Prefunded, balance-based, collateralised intraday credit, uncollateralised credit or guaranteed | Assigns liquidity cost and credit exposure |
| Queue model | Immediate reject, central queue, participant-controlled queue, offsetting or optimisation | Determines how valid instructions behave when balances are insufficient |
| Access model | Direct, sponsored, tiered or agent-based | Determines who holds settlement accounts and who remains responsible for indirect participants |
| Operating schedule | Business hours, extended hours, 24/5 or 24/7/365 | Determines when participants must fund, monitor and support the service |
| Ledger relationship | Single authoritative ledger, mirrored records, linked ledgers or synchronised external ledgers | Determines how systems coordinate state and recover from partial completion |
| Currency model | Single currency, multi-currency or cross-currency | Determines whether foreign-exchange principal risk requires payment-versus-payment controls |
| Finality model | Immediate on posting, rule-defined event, cycle completion or coordinated multi-leg completion | Determines when the transfer becomes legally and operationally conclusive |
Two systems can both describe themselves as real time while assigning risk differently. One may settle each instruction in central-bank money. Another may provide an immediate customer credit against prefunded commercial-bank balances and settle participants later. A third may transfer a private token immediately while redemption into central-bank money follows a separate process.
The useful classification therefore records the complete combination rather than relying on a product label.
The Settlement Asset Determines What Value Has Moved
The settlement asset is the financial claim transferred to discharge an obligation. Its issuer, legal form, backing and redemption mechanism determine the quality of settlement.
| Settlement asset | Claim transferred | Principal strength | Risk that remains |
|---|---|---|---|
| Central-bank account balance | A direct claim on the central bank recorded in its books | Eliminates commercial-bank credit risk in the settlement asset and anchors monetary singleness | Operational, liquidity, legal-scope and participant risks remain |
| Commercial-bank deposit | A claim on a commercial bank | Integrates readily with customer accounts, lending and correspondent banking | Exposure to the account-holding bank, access conditions and convertibility into central-bank money |
| Tokenised central-bank money | A central-bank liability represented on or connected to a programmable ledger | Can combine central-bank-money settlement with programmable or atomic workflows | Legal recognition, platform governance, access, cyber resilience and interoperability still require explicit design |
| Tokenised commercial-bank deposit | A commercial-bank deposit represented as a transferable token or ledger object | Supports programmable transfers while retaining a regulated bank liability | Issuer risk, interoperability, par convertibility, redemption and cross-ledger finality |
| Reserve-backed private settlement token | A claim on an issuer, operator or legal arrangement backed by segregated assets | Can support continuous transfer on private or distributed infrastructure | The holder depends on the legal claim, reserve custody, bankruptcy treatment and redemption process |
| Stablecoin used for payment | A privately issued token intended to maintain a reference value | Broad availability and programmable transfer on supported networks | Reserve quality, redemption, price deviation, issuer, ledger, bridge, governance and financial-integrity risk |
01
Central-Bank Money Anchors Interparticipant Settlement
Where systemically important obligations settle in central-bank money, the asset does not expose participants to the failure of a commercial issuer. This quality normally makes central-bank money the preferred asset for interparticipant settlement.
Even with that asset, settlement depends on sufficient balances or eligible collateral and on a sound legal basis, resilient operations, controlled access, accurate records and tested recovery procedures.
For a direct participant, settlement can occur in its own central-bank account. An indirect participant may instead hold a commercial-bank claim against its sponsor, even though the sponsor discharges the underlying interparticipant obligation in central-bank money.
02
Commercial-Bank Money Supports Most Customer-Level Transfers
At customer level, most money held by households and businesses is a claim on a commercial bank. An internal transfer can settle through entries on that bank’s ledger, whereas a transfer between banks creates an interbank obligation that may settle separately in central-bank money.
Because the customer and interbank layers can use different settlement assets, a beneficiary may receive a commercial-bank deposit while the participating banks exchange central-bank balances underneath it.
Across institutions and currencies, correspondent banking extends the same layered structure through multiple account relationships. Each entry becomes final only within its governing relationship and legal framework, so the end-to-end payment can depend on several separate settlements rather than one global transfer.
03
Tokenisation Changes Representation, Workflow and Connectivity
On a programmable platform, tokenisation can place the asset, transaction logic and transfer record in one workflow. Another arrangement may use a token only to represent an existing claim while final settlement remains on a separate ledger.
Because “tokenised” describes representation rather than issuer or credit quality, similar technical infrastructure can carry materially different claims: a central-bank liability, a commercial-bank deposit or a privately issued stablecoin.
Settlement quality follows first from the issuer and legal claim, then from backing, redemption at par, ledger control, access, finality and the mechanism connecting the token to other forms of money.
Timing and Liquidity Determine Settlement Capacity
Settlement speed depends on available liquidity, not only on processing performance. A technically valid instruction cannot settle when the paying participant lacks the required balance, credit or collateral.
| Model | Timing | Liquidity effect | Exposure effect |
|---|---|---|---|
| Real-time gross settlement | Each instruction settles individually when accepted and funded | Requires liquidity throughout the operating period; queues and intraday credit can reduce pressure | Ends interparticipant credit exposure instruction by instruction |
| Deferred net settlement | Net positions settle at scheduled times | Reduces the amount of settlement liquidity by offsetting obligations | Exposure accumulates until the cycle completes |
| Frequent batch settlement | Transactions settle in repeated short cycles | Balances liquidity savings against shorter exposure windows | Limits the duration of unsettled positions without requiring full RTGS liquidity |
| Hybrid or liquidity-saving settlement | Gross instructions settle continuously, with queued payments offset or optimised | Reuses incoming funds and identifies combinations that can settle together | Preserves transaction-level finality once each instruction posts |
| Prefunded instant settlement | Payments settle against balances funded in advance | Moves the liquidity burden to prefunding and replenishment | Reduces credit exposure but can fragment liquidity across systems |
| Credit-supported settlement | Valid instructions settle using collateralised or other permitted credit | Increases capacity during temporary shortfalls | Transfers risk into collateral, credit limits and central-bank or operator rules |
01
Liquidity Demand Is Path-Dependent
The same daily payment value can require different amounts of liquidity depending on transaction order, concentration and incoming flows.
A participant that sends large payments before receiving funds needs more opening liquidity. A central queue can delay lower-priority payments, release them when incoming funds arrive or settle offsetting instructions together. Participants can also reserve liquidity for critical payments and apply bilateral or multilateral limits.
Liquidity-saving mechanisms improve throughput without changing the settlement asset. Their value depends on transparent queue rules, predictable priority handling and a clear response when an instruction remains unsettled.
02
Continuous Operation Removes the Traditional Reset Point
A 24/7 settlement system has no universal end-of-day pause in which every participant can reconcile positions, replenish balances, deploy changes and investigate exceptions.
Continuous settlement therefore requires continuous liquidity monitoring, weekend and holiday funding, round-the-clock collateral or credit arrangements, live reconciliation, resilient staffing and change procedures that operate while the service remains active.
Connections between systems also matter. A payment service may operate continuously while a funding market, foreign-exchange market or collateral facility follows narrower hours. The participant then needs prefunding or another bridge across the availability gap.
Settlement liquidity examines funding sources, queues, collateral, intraday credit and liquidity-saving mechanisms in greater depth.
Finality Defines the Point at Which Exposure Ends
Settlement finality is the legally defined point at which a transfer becomes irrevocable and unconditional within the relevant system.
A database confirmation alone does not establish finality. The legal framework needs to recognise the transfer, the system rules need to identify the decisive event, and the authoritative record needs to show that the event occurred.
Finality also needs to withstand participant insolvency. If an insolvency administrator can unwind a transfer that the system treated as complete, the operational status and legal result diverge at the moment when certainty matters most.
01
Finality Has Several Connected Layers
| Layer | Required certainty | Failure if unclear |
|---|---|---|
| Legal basis | Applicable law recognises the system rules, netting and settlement transfer | A completed entry can face challenge or inconsistent treatment across jurisdictions |
| Rulebook | Rules identify the exact event that creates irrevocable and unconditional settlement | Participants use different interpretations of “final” |
| Authoritative record | The designated ledger or record proves that the event occurred | Several systems claim to be the source of truth |
| Operational completion | All required processing steps have reached their terminal state | A legal transfer exists while a linked operational leg remains incomplete |
| Participant records | Internal ledgers and confirmations map to the final system event | Customers and operators see conflicting statuses |
| Correction process | Returns, recalls, refunds and restitution create traceable subsequent actions | A later correction appears to erase or rewrite the original event |
Finality does not mean that no later action can affect the economic result. Fraud recovery, a court order, a refund or an erroneous-payment procedure may create a new transfer. The original settlement remains part of the audit trail, and the corrective transaction receives its own authority, identifier and finality.
02
Settlement Risk Changes Before and After Finality
| Risk | How it arises | Principal control |
|---|---|---|
| Credit risk | A counterparty may fail before discharging its obligation | Central-bank-money settlement, collateral, limits, guarantees and short exposure windows |
| Liquidity risk | A solvent participant cannot obtain the asset needed at the required time | Prefunding, intraday credit, queues, collateral and liquidity-saving mechanisms |
| Principal risk | One leg settles while the participant does not receive the other | Payment-versus-payment, delivery-versus-payment or atomic coordination |
| Legal risk | Law, rules and records do not produce the same final result | Enforceable rulebook, settlement-finality protection and jurisdictional analysis |
| Operational risk | Systems, connections, data or people fail during processing | Resilience, recovery, reconciliation and tested contingency procedures |
| Interoperability risk | Linked systems reach inconsistent states | Common identifiers, synchronized conditions, timeouts and deterministic recovery |
| Settlement-asset risk | The transferred claim loses value or cannot be redeemed at par | Asset eligibility, reserve, custody, redemption and issuer controls |
Settlement finality examines the legal event, irrevocability, insolvency protection and evidence that support a final transfer.
Linked Settlement Coordinates Value Across Currencies and Ledgers
When a transaction crosses currencies or tokenised platforms, speed on each individual system cannot coordinate the result by itself. The architecture must align separate assets, ledgers, rulebooks and operating clocks.
If one leg becomes final while another leg fails, partial completion exposes the successful participant to the full principal value of the missing leg. Preventing that state is the central linked-settlement problem.
01
Different Structures Produce Different Degrees of Coordination
| Structure | How value moves | Protection against partial completion | Principal dependency |
|---|---|---|---|
| Sequential correspondent settlement | Institutions debit and credit accounts through a chain of correspondents | Contractual controls, limits and operational sequencing | Each intermediary’s account relationship, liquidity and operating hours |
| Common payment-versus-payment system | Both currency legs settle through one coordinated arrangement | One leg settles only if the other can settle | Membership, eligible currencies, funding and common operating window |
| Linked RTGS systems | Separate central-bank ledgers coordinate reserved or conditional transfers | A synchronization mechanism connects the final entries | Compatible rules, message states, clocks and recovery procedures |
| RTGS-to-DLT synchronization | Cash settles in RTGS while an asset or second money leg moves on an external ledger | An orchestrator coordinates both authoritative systems | Legal recognition of both records and deterministic handling of timeouts or outages |
| Shared programmable platform | Several tokenised money and asset types move through one coordinated workflow | Smart-contract logic can reserve and execute all legs atomically | Platform governance, privacy, liquidity, access and cross-jurisdictional finality |
02
Payment-versus-Payment Controls Foreign-Exchange Principal Risk
Payment-versus-payment links the final transfer of one currency to the final transfer of another. Both legs complete, or neither completes.
Even when execution is linked, both currency legs need sufficient liquidity at the same time. Mismatched cut-offs, time-zone differences, sanctions or compliance holds, participant unavailability and a one-sided technical failure can otherwise prevent the conditions for simultaneous settlement from being met.
Since June 2026, TIPS has provided a live example of cross-currency instant settlement in central-bank money between euro, Swedish-krona and Danish-krone accounts. Its technical solution became available in October 2025, before joint testing and formal activation by the relevant central banks moved the service into live simultaneous settlement.
03
Synchronization Preserves Separate Sources of Truth
Synchronization allows each asset to remain on its native ledger while a coordinator controls the conditions under which both ledgers post final entries.
When a timeout or communication failure interrupts the sequence, each native ledger must recover to a deterministic state without creating an unpaired transfer. That dependency makes the coordinator a critical orchestration function, even though the model avoids moving every asset and participant onto one platform; its operator, permitted evidence, authority to release locked value and recovery rules all require explicit definition.
Through Project Meridian FX, the model was demonstrated both between RTGS systems and between an RTGS system and a distributed ledger. The Bank of England is now developing a production synchronization service with a current target of 2028.
04
Atomicity Requires Legal and Operational Alignment
Technical atomicity means that programmed state changes execute together. Settlement atomicity also requires each state change to be final under its governing legal framework.
For the technical result to become a final settlement result, a robust linked arrangement aligns:
- the assets and legal claims transferred;
- the authoritative record for each leg;
- the event that creates finality on each system;
- reservation, locking and release conditions;
- clocks, deadlines and timeout rules;
- data shared across the connection;
- incident authority and recovery procedures;
- liquidity and collateral in every currency or asset.
The wider routing, intermediary and corridor consequences belong to cross-border payments. Ledger ownership and record design belong to ledger architecture.
Settlement Infrastructure Is Becoming Continuous, Programmable and Multi-Ledger
Production settlement is changing alongside the payment interface as longer operating windows reach core infrastructure, cross-currency links coordinate central-bank money in real time and tokenised systems progress through several distinct stages.
Those stages carry different evidentiary weight. A live service settles production value under an operating rulebook, while controlled live use places limits around production operation. A pilot tests selected participants or use cases; user testing precedes launch; and a proof of concept demonstrates technical feasibility without establishing a production service.
01
Maturity as of 23 August 2026
| Development | Current position | Evidence | Structural consequence |
|---|---|---|---|
| Continuous wholesale RTGS | Live | RENTAS+ has operated 24/7/365 since 7 October 2025 | Wholesale settlement, liquidity monitoring and support can operate without a daily closing boundary |
| Cross-currency instant central-bank-money settlement | Live | TIPS formally activated simultaneous settlement across euro, Swedish krona and Danish krone in June 2026 | Payment-versus-payment capability can move into continuous instant-payment infrastructure |
| Extended RTGS operating days and hours | Planned and phased | Federal Reserve, Bank of England and ECB roadmaps contain separate 2027–2031 milestones | Major systems are expanding availability through different operating models rather than one uniform move to 24/7 |
| Regulated tokenised-deposit orchestration | Initial use and live-pilot preparation | Swift’s shared ledger was ready for initial use in July 2026; 17 banks are preparing live pilots | Tokenised commercial-bank money is gaining common orchestration infrastructure while existing systems retain final settlement roles |
| Integrated continuous clearing and tokenised liquidity | Live in a defined bank-to-bank service | Citi and Siam Commercial Bank launched continuous US-dollar clearing combined with Citi Token Services in July 2026 | Institutions can bridge tokenised internal liquidity and conventional external settlement within one operating service |
| Multi-currency programmable settlement | Prototype completed; real-value testing completed | Project Agorá ran 17 scenarios involving 28 institutions and central banks with approximately CHF 800,000 of real value in July 2026 | Tokenised deposits and central-bank reserves can coordinate atomic cross-border settlement while preserving jurisdiction-specific reserve ledgers |
| DLT access to central-bank-money settlement | User testing and planned initial operation | Pontes scheduled user testing for August 2026 and initial launch for the third quarter of 2026 | Market DLT platforms can connect to T2 without placing every asset on the central-bank ledger |
| Integrated European tokenised-finance architecture | Design and market-engagement phase | The ECB selected 61 Appia contact-group members in August 2026; work begins in September | The Eurosystem is defining a longer-term platform beyond the initial Pontes bridge |
| RTGS-to-external-ledger synchronization | Production development | The Bank of England targets a live synchronization service in 2028 | Cash can remain in RTGS while tokenised assets remain on external ledgers |
| Wholesale central-bank money on or linked to DLT | Production pilots and controlled live operation | Project Helvetia, BX Digital and Sterling Fnality connect tokenised workflows to central-bank money through different structures | Central-bank-money settlement is becoming available to tokenised markets without one universal ledger model |
| Liquidity-saving innovation | Proof of concept | Project Titus tested an auction-based liquidity-saving mechanism with RTGS transaction data | Optimization can release offsetting payments while preserving individual settlement records |
| Cross-border ISO 20022 harmonisation | Production baseline under managed maintenance | CPMI updated its harmonised data requirements in February 2026 and intends to avoid major changes until at least the end of 2027 | Structured data becomes part of interoperability and settlement control, not only message transport |
02
Continuous Settlement Is Expanding Through Several Models
With RENTAS+, 24/7/365 wholesale RTGS operation is supported by an automatic liquidity facility. Gross settlement of DuitNow obligations after each customer transaction connects retail instant payments directly to the continuous wholesale layer.
In TIPS, final and irrevocable central-bank-money settlement operates around the clock, and the cross-currency service lets separate currency communities coordinate simultaneous settlement through a common technical platform.
Rather than converge on one operating model, other operators are extending established systems in phases. Fedwire is due to add Sunday and weekday-holiday operation no earlier than 2028 while retaining a 22-hour operating day; CHAPS is scheduled to open earlier on weekdays from September 2027, with Sunday, holiday and broader 22×6 operation assigned to later phases; and the ECB is developing its own phased extension of T2 hours.
For funding and resilience design, expanded days, longer hours, continuous instant settlement and full 24/7 RTGS remain different operating states. A precise availability claim identifies which one the infrastructure actually provides.
03
Programmability Is Moving Closer to Production Money
On 9 July 2026, Swift announced that its blockchain-based shared ledger was ready for initial use, with 17 banks across six continents preparing to pilot live tokenised-deposit transactions. Its role is to provide orchestration and interoperability while regulated existing systems continue to perform final settlement.
That same day, Siam Commercial Bank and Citi announced a live service that combines 24/7 US-dollar clearing with Citi Token Services. The arrangement uses tokenised internal liquidity to support near-real-time cross-border payments while keeping the conventional US-dollar leg connected to Citi’s clearing infrastructure.
Across both models, programmability enters regulated bank money through an additional infrastructure layer rather than through replacement of the entire settlement system. Issuer liabilities, access rules, liquidity, reconciliation and finality across connected records continue to determine the settlement result.
04
Real-Value Testing Now Separates Feasibility from Operation
Project Agorá moved from prototype work into real-value testing using tokenised commercial-bank deposits and jurisdiction-specific central-bank reserve ledgers. In July 2026, 28 private-sector institutions and central banks completed 17 scenarios totalling approximately CHF 800,000.
Although the test demonstrates coordination of real value under controlled conditions, production adoption depends on permanent governance, participation, resilience, privacy, liquidity and legal arrangements.
For Pontes, the relevant maturity step is user testing rather than real-value experimentation: the service connects market DLT platforms to the Eurosystem’s T2 service for central-bank-money settlement. User testing was scheduled for August 2026 ahead of initial operation planned for the third quarter of 2026.
Beyond that initial bridge, Appia defines the longer-term direction toward an integrated European ecosystem for tokenised finance. The ECB selected 61 stakeholders for its contact group on 19 August 2026, and the group begins work in September.
05
Settlement Data Is Becoming a Control Surface
Since CPMI updated the harmonised ISO 20022 data requirements in February 2026, operators have had a stronger common cross-border baseline for parties, agents, accounts, purpose and remittance information.
If an institution truncates fields, maps them inconsistently or reduces precise states to incompatible status codes, acceptance of an ISO 20022 message does not preserve its operating value. Sanctions controls, liquidity forecasts, routing, reconciliation and exception handling can all lose the information they depend on.
By maintaining the requirements without major changes until at least the end of 2027, CPMI gives operators a more stable implementation horizon while leaving data governance across internal and external ledgers as an institutional responsibility.
06
Stablecoins Expand Access Without Resolving Every Settlement Property
On widely accessible networks, stablecoins provide programmable transfer, but an on-chain state establishes only one layer of settlement quality.
In June 2026, the BIS reported that 99.4% of fiat-backed stablecoin market value was linked to the US dollar and found uneven cross-border-payment performance once fees, spreads and on-ramp and off-ramp costs were included.
Whether the transfer provides a robust settlement outcome depends on the holder’s legal claim, reserve quality, redemption at par, access to liquidity, network governance, bridge security, financial-integrity controls and the legal status of ledger finality.
Taken together, these developments are producing a broader settlement landscape rather than one replacement architecture. Central-bank ledgers, commercial-bank books, shared ledgers, private tokens and synchronisation services are developing as connected layers with different sources of trust and risk.
A Settlement System Is Proven by Its Finality, Liquidity and Failure Rules
A credible settlement system can identify the asset, legal event, liquidity source, authoritative record and failure response for every payment state. Performance claims become meaningful only after those elements are clear.
| Assessment area | Evidence required | Decisive question |
|---|---|---|
| Obligation | Rulebook definition of the obligation submitted for settlement | What exactly is discharged: one instruction, a bilateral position or a multilateral net position? |
| Settlement asset | Issuer, legal claim, account or token terms, backing and redemption rules | What value does the receiving participant own after settlement? |
| Legal basis | Governing law, system designation, enforceability and insolvency treatment | Will the settlement result remain final if a participant fails? |
| Finality event | Rulebook clause and authoritative ledger state | Which event makes the transfer irrevocable and unconditional? |
| Timing | Operating schedule, cut-offs, cycle rules and service calendars | How long can an accepted obligation remain unsettled? |
| Liquidity model | Prefunding, balance, collateral, credit and replenishment rules | How does a participant obtain the asset needed at the moment of settlement? |
| Queue behavior | Priority, reservation, offsetting, cancellation and expiry rules | What happens when an otherwise valid instruction lacks liquidity? |
| Access | Direct, sponsored and indirect participation agreements | Who holds the settlement account and who carries responsibility for each indirect participant? |
| Credit and loss allocation | Limits, guarantees, collateral, default fund and loss-sharing rules | Who absorbs a shortfall if a participant cannot settle? |
| Linked legs | Locking, reservation, synchronization, timeout and atomic-execution logic | Can one asset or currency become final while the other fails? |
| Authoritative records | Ledger designation, identifiers, timestamps and evidence-retention rules | Which record proves the settlement result? |
| Reconciliation | Matching rules across clearing, settlement and participant ledgers | How does the operator detect a valid transfer that another record failed to reflect? |
| Operating resilience | Availability design, recovery-time objective, contingency processing and testing | Can critical settlement resume and complete within the required disruption window? |
| Cyber controls | Access, integrity, key management, detection and recovery evidence | Can an attacker create, alter, suppress or falsely confirm a settlement event? |
| Change and version control | Release, migration, rollback and participant-certification procedures | How does the system change while preserving continuous, consistent state? |
| Incident authority | Decision rights, escalation paths and communication rules | Who can suspend processing, extend a cycle, invoke recovery or declare the authoritative status? |
01
Customer Speed Needs a Funding Explanation
An immediate customer credit can reflect final interparticipant settlement, prefunded balances, a receiving-bank guarantee or credit advanced before deferred settlement.
The customer outcome may look identical across these structures. The liquidity owner and failure exposure differ. A credible operating model identifies which institution funds the promise and which record supports it.
02
Programmability Needs a Legal Explanation
A smart contract can execute conditions exactly as coded and still produce an uncertain legal result if the asset, rulebook or ledger lacks a clear legal basis.
The assessment therefore connects code execution to the governing claim, authorized participants, finality event, error procedure and insolvency treatment.
03
Resilience Needs an End-of-Disruption-Day Explanation
Recovery is not complete when the platform restarts. Participants need to know which instructions settled, which remain queued, which require resubmission and how every dependent ledger will reconcile.
The cyber-resilience standard for financial market infrastructures sets a two-hour recovery objective for critical operations and expects settlement completion by the end of the disruption day. A continuous system must define what that operating-day boundary means in practice.
Every Settlement Architecture Assigns Risk Differently
No architecture removes settlement risk. Each architecture changes its location, duration and owner.
| Architecture | Settlement asset and record | Timing and liquidity | Main risk concentration | Current position |
|---|---|---|---|---|
| Real-time gross settlement | Usually central-bank balances on the RTGS ledger | Individual settlement; continuous access to balances, collateral or intraday credit | Intraday liquidity, queue congestion and operational continuity | Established core infrastructure in major currencies |
| Deferred net settlement | Net obligations settle in the designated asset after a clearing cycle | Lower settlement liquidity through netting; exposure accumulates until cycle completion | Participant default, recalculation, guarantees and loss allocation | Established in retail and batch payment arrangements |
| Hybrid settlement with liquidity-saving mechanisms | Individual final entries supported by centralized queues and optimization | Incoming funds, offsetting and priority rules reduce gross liquidity demand | Queue governance, optimization dependency and liquidity concentration | Established in several wholesale systems; continuing area of design innovation |
| Instant central-bank-money settlement | Central-bank balances transfer for each instant payment | Prefunded or continuously funded accounts; 24/7 liquidity and support | Fragmented liquidity, out-of-hours funding and continuous operations | Live in services including TIPS and other central-bank instant-payment platforms |
| Correspondent settlement | Commercial-bank account entries across one or more correspondents | Sequential transfers and currency-specific funding | Intermediary credit, liquidity, cut-off, transparency and principal risk | Established global model with continuing modernization |
| Tokenised-deposit orchestration | Commercial-bank deposit claims represented or coordinated on a shared ledger | Potential 24/7 transfer; liquidity remains tied to issuing banks and conversion arrangements | Issuer, interoperability, redemption, privacy and cross-ledger finality | Controlled live services, initial use and live-pilot preparation |
| RTGS-to-DLT synchronization | Cash remains on the RTGS ledger while assets remain on an external ledger | Reserved or conditional liquidity released through an orchestrator | Orchestrator availability, timeout handling and legal alignment across ledgers | Proven in experiments; production services and pilots under development |
| Shared programmable or unified platform | Tokenised central-bank reserves, commercial-bank money and assets interact through coordinated ledgers | Atomic execution can reduce sequencing risk; each asset still needs liquidity | Platform governance, access, privacy, concentration and cross-jurisdictional law | Prototype and real-value testing, with longer-term public programmes in design |
| Private reserve-backed settlement token | A private token represents a claim backed by central-bank money or other reserves | Prefunded value can transfer continuously within the platform | Issuer, custody, bankruptcy treatment, redemption and ledger governance | Controlled live use in selected regulated structures; broader models vary widely |
RTGS reduces credit exposure by settling each obligation separately, then concentrates attention on intraday liquidity and operational availability.
Net settlement reduces funding demand, then concentrates attention on the period before settlement and the treatment of a failed participant.
Tokenised and linked-ledger models can reduce reconciliation and sequencing friction, then concentrate attention on legal claims, interoperability, orchestration and governance across multiple records.
The useful design question is therefore not which architecture appears newest or fastest. It is whether the allocation of finality, liquidity, credit, records and failure responsibility fits the obligations the system needs to settle.
Frequently Asked Questions About Settlement Systems
01
What is a settlement system?
A settlement system is the legal, technical and operational arrangement that discharges financial obligations by transferring an agreed settlement asset between participants. It defines the accounts or ledgers used, settlement timing, liquidity rules, finality and failure procedures.
02
What is the difference between a payment system and a settlement system?
A payment system can include initiation, messaging, validation, routing, clearing, settlement and participant rules. A settlement system performs the narrower function that transfers the settlement asset and discharges participant obligations.
03
What is the difference between clearing and settlement?
Clearing validates transactions and calculates what each participant owes. Settlement transfers the agreed asset to discharge those obligations. Netting can reduce multiple payments to one net obligation, but the net obligation remains unsettled until the asset moves.
04
What is settlement finality?
Settlement finality is the legally defined point at which a transfer becomes irrevocable and unconditional within the applicable system. The rulebook, governing law and authoritative ledger record need to identify the same event.
05
Is an instant payment always settled instantly?
An instant customer experience can rest on immediate interparticipant settlement, prefunded balances, a receiving-bank guarantee or credit advanced before deferred settlement. The customer status alone does not identify the underlying settlement timing.
06
What is real-time gross settlement?
Real-time gross settlement, or RTGS, settles each instruction individually in real time, normally in central-bank money. Payments settle when they meet system rules and the participant has sufficient balances or permitted credit.
07
Why do systems use deferred net settlement?
Deferred net settlement offsets incoming and outgoing obligations before moving the settlement asset. This can materially reduce liquidity demand, while exposure remains between participants until the net cycle completes.
08
Why is central-bank money preferred for systemically important settlement?
Central-bank money removes commercial-bank credit risk from the settlement asset. Participants still face liquidity, operational, legal and access risks, but the asset itself is a direct central-bank liability.
09
What happens when a participant lacks settlement liquidity?
The instruction may enter a queue, settle through incoming funds, use reserved liquidity, draw permitted intraday credit or fail under the system’s rules. Settlement liquidity explains how prefunding, collateral, queues and liquidity-saving mechanisms affect that outcome.
10
What is payment-versus-payment settlement?
Payment-versus-payment links the final transfer of one currency to the final transfer of another. Both legs settle, or neither settles, reducing the risk that a participant pays away one currency without receiving the other.
11
Can blockchain confirmation establish legal settlement finality?
A blockchain or distributed-ledger confirmation establishes a technical state under the network’s rules. Legal finality also depends on the governing law, the legal nature of the asset, the system rulebook and recognition of the ledger entry as the decisive settlement event.
12
How do tokenised deposits settle?
A tokenised deposit represents a claim on a commercial bank. Settlement may occur through transfer of that claim on the issuing bank’s or a shared ledger, while conversion and interbank obligations can require linked commercial-bank or central-bank-money settlement.
13
Does 24/7 operation eliminate settlement risk?
Continuous operation reduces timing gaps but increases the need for continuous liquidity, monitoring, reconciliation, support and recovery. Funding markets, collateral facilities and linked systems may still follow narrower operating hours.
14
What happens after a final payment needs to be returned?
The system creates a new return, recall, refund or restitution transaction linked to the original payment. The original final settlement remains in the audit trail rather than becoming historically unsettled.
Settlement Systems Sit Within a Wider Payment Architecture
Settlement design connects the payment system’s rules, settlement asset, liquidity arrangements and definition of finality. These related analyses examine each layer separately:
- Payment Systems explains the broader infrastructure, participants and functions through which payments are initiated, cleared and settled.
- Settlement Finality examines when a transfer becomes legally and operationally irrevocable.
- Settlement Liquidity covers prefunding, intraday credit, collateral, queues and liquidity-saving mechanisms.
Standards and Live Programmes Defining the Current Baseline
As at 23 August 2026, settlement-system development is being shaped by longer operating windows, cross-currency links, tokenised settlement assets, synchronisation across separate ledgers and stronger requirements for data and operational resilience.
Finality, Risk and Resilience
- Principles for Financial Market Infrastructures — the CPMI-IOSCO standards for legal basis, credit and liquidity risk, settlement finality, money settlements, operational resilience, access and governance.
- Tokenisation in the context of money and other assets — confirms that established financial-market-infrastructure risks remain relevant when assets or settlement processes move to programmable ledgers, although those risks may arise in different forms.
- Application of the PFMI to stablecoin arrangements — applies the PFMI to systemically important stablecoin transfer functions, including finality, the issuer claim, reserve assets and redemption arrangements.
- Guidance on cyber resilience for financial market infrastructures — establishes the expectation that an FMI should be able to resume critical operations within two hours and complete settlement by the end of the disruption day.
- Updated harmonised ISO 20022 data requirements for cross-border payments — the February 2026 version of the common data baseline, which CPMI intends to maintain without further major amendments until at least the end of 2027.
- FX settlement risk: an unsettled issue — the June 2026 BIS analysis estimates that more than $1.4 trillion of daily foreign-exchange turnover remains exposed to gross bilateral settlement risk.
- Anchoring trust in money: innovation beyond stablecoins — the June 2026 BIS assessment of tokenised money, stablecoins, interoperability, liquidity elasticity and the role of central-bank money in preserving monetary singleness.
Continuous and Cross-Currency Settlement
- RENTAS+ — Bank Negara Malaysia’s 24/7/365 RTGS system entered service on 7 October 2025 with an automatic liquidity facility and transaction-level settlement of DuitNow obligations.
- TARGET Instant Payment Settlement and its cross-currency service — final and irrevocable central-bank-money settlement around the clock. The technical cross-currency service became available in October 2025, and simultaneous settlement between the euro, Swedish krona and Danish krone went live in June 2026.
- Federal Reserve expansion of Fedwire operating days — plans to add Sundays and weekday holidays no earlier than 2028 while retaining a 22-hour operating day; this is expanded availability, not continuous 24/7 settlement.
- Bank of England consultation on extended RTGS and CHAPS hours — proposes a 01:30 weekday opening from September 2027, with Sunday and holiday operation considered for later phases.
- ECB roadmap for extending T2 operating hours — sets out a phased path beginning with additional weekend and holiday access for liquidity transfers, followed by further consultation in 2027.
Tokenised and Linked-Ledger Settlement
- Project Helvetia — the Swiss National Bank’s production pilot supports wholesale CBDC settlement on the SIX Digital Exchange and a production RTGS link for settling tokenised assets on BX Digital. The pilot is scheduled to continue until at least June 2028.
- Sterling Fnality Payment System — the United Kingdom’s first supervised wholesale DLT settlement system uses a Bank of England RTGS omnibus account and operates under limits while progressing through supervisory scaling stages.
- Project Agorá — tests a multi-currency architecture combining tokenised commercial-bank deposits with jurisdiction-specific central-bank reserve ledgers. Real-value testing began in 2026.
- Pontes and the ECB’s preparation for go-live — the Eurosystem’s short-term infrastructure links DLT platforms to T2 for central-bank-money settlement. User testing was scheduled for August 2026, with initial operation planned for the third quarter of 2026.
- Appia — the Eurosystem’s longer-term programme for an integrated tokenised-finance ecosystem. The ECB selected 61 market participants for its contact group in August 2026, with work beginning in September.
- Project Meridian FX — demonstrates how a synchronisation operator can coordinate payment-versus-payment settlement between two RTGS systems or between an RTGS system and a distributed ledger without merging the underlying ledgers.
- Bank of England wholesale-market synchronisation — targets a live synchronisation service in 2028 to coordinate cash movements in RTGS with transfers of assets on external ledgers.
- Swift’s shared ledger — reached readiness for initial use in July 2026, with 17 banks preparing live pilots. It acts as an orchestration layer while final settlement continues through regulated existing systems.
- Siam Commercial Bank and Citi’s 24/7 US-dollar service — a live July 2026 implementation combining continuous US-dollar clearing with tokenised internal liquidity transfers.
- Project Titus — a BIS Innovation Hub proof of concept that applies an auction-based liquidity-saving mechanism to wholesale settlement using RTGS transaction data.
Last reviewed: 23 August 2026