Clearing, RTGS, deferred-net settlement, liquidity, queues, and finality architecture

Sending participant and payment queue

Validates, prioritises, funds, and submits payments from the sending institution.

Kind

application

Owner

Participant payment operations and treasury

Responsibilities

• Release only eligible payments
• Maintain priority and liquidity intent
• Correlate every submission

Inputs

• Approved payment
• Priority
• Cut-off
• Liquidity position

Outputs

• Funded settlement instruction

Controls

• Eligibility
• Duplicate detection
• Priority
• Available-liquidity check

Failure modes

• Insufficient participant liquidity
• Missed cut-off
• Duplicate release

Recovery

• Keep the instruction queued
• Fund or reprioritise under policy
• Submit once with stable identifiers

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Infrastructure access gateway

Authenticates the participant, validates the service envelope, and protects the settlement boundary.

Kind

gateway

Owner

Financial market infrastructure operator

Responsibilities

• Authenticate participant and service
• Apply technical and message-profile checks

Inputs

• Signed or authenticated settlement instruction

Outputs

• Admitted instruction or precise rejection

Controls

• Identity
• Integrity
• Replay prevention
• Rate and size limits

Failure modes

• Invalid signature or certificate
• Malformed message
• Unavailable access channel

Recovery

• Reject before admission
• Use a tested alternative access path only under scheme rules

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Clearing and eligibility engine

Applies participant, message, timing, limit, and service rules before settlement.

Kind

control

Owner

Financial market infrastructure operator

Responsibilities

• Confirm participant and transaction eligibility
• Calculate or maintain bilateral/multilateral obligations where applicable

Inputs

• Admitted instruction
• Participant status
• Service calendar and limits

Outputs

• Eligible item, clearing obligation, or rejection

Controls

• Participant status
• Message validation
• Limits
• Cut-off and business-day control

Failure modes

• Ineligible participant
• Rule violation
• Invalid clearing cycle

Recovery

• Reject or defer according to the rulebook
• Preserve the original reason and state

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Central queue and liquidity-saving logic

Orders unsettled instructions and may offset or release them under documented liquidity-saving rules.

Kind

service

Owner

Settlement service operator

Responsibilities

• Maintain queue order and priority
• Apply gridlock-resolution or offset logic without changing the legal obligation

Inputs

• Eligible instruction
• Participant balance
• Priority and limit

Outputs

• Released, queued, offset, or expired instruction

Controls

• Deterministic ordering
• Participant controls
• No hidden overdraft

Failure modes

• Gridlock
• Starvation of lower priority
• Queue-state loss

Recovery

• Restore the durable queue
• Apply documented gridlock procedures
• Notify participants of expiry or rejection

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Central-bank or settlement-asset ledger

Makes the final debit and credit in the settlement asset under the infrastructure’s legal and operational rules.

Kind

ledger

Owner

Central bank or designated settlement institution

Responsibilities

• Check available settlement asset
• Post atomic debit and credit
• Record finality evidence

Inputs

• Released settlement instruction or net obligation

Outputs

• Final debit/credit and settlement confirmation

Controls

• No unapproved overdraft
• Atomic balanced posting
• Finality timestamp

Failure modes

• Insufficient funds
• Ledger unavailable
• Posting uncertainty

Recovery

• Queue or reject under the rules
• Recover the ledger from the last consistent checkpoint
• Reconcile before reopening

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Deferred-net clearing cycle

Calculates participant obligations for a defined cycle before those obligations settle.

Kind

service

Owner

Clearing-system operator

Responsibilities

• Accumulate eligible items
• Calculate transparent net obligations
• Handle default or unwind rules

Inputs

• Cleared bilateral items

Outputs

• Net debit and credit obligations

Controls

• Reconciliation to source items
• Cycle cut-off
• Limit and risk controls

Failure modes

• Unbalanced cycle
• Participant default
• Late or duplicate file

Recovery

• Stop the cycle
• Recalculate from immutable inputs
• Apply the documented default process

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Receiving participant and beneficiary posting

Receives confirmed outcome, updates internal books, and makes funds available under the service rules.

Kind

application

Owner

Receiving participant payment operations

Responsibilities

• Correlate the settled instruction
• Post the customer or bank account once
• Report the outcome

Inputs

• Settlement confirmation
• Payment details

Outputs

• Beneficiary posting and status/reporting

Controls

• Settlement-state check
• Account validation
• Posting idempotency

Failure modes

• Settlement confirmed but customer posting delayed
• Invalid beneficiary account
• Duplicate posting

Recovery

• Repair the customer posting without reversing settlement
• Return through the applicable process when required

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Liquidity, settlement, and reconciliation operations

Monitors queues, balances, cycles, settlement evidence, and participant incidents.

Kind

operations

Owner

Infrastructure and participant operations

Responsibilities

• Monitor liquidity and queue risk
• Reconcile instructions, obligations, settlement, and reports
• Coordinate continuity

Inputs

• Queue state
• Balances
• Settlement reports
• Participant incidents

Outputs

• Liquidity action
• Resolved break
• Controlled recovery

Controls

• Four-eyes liquidity action
• Evidence-based replay
• Incident command

Failure modes

• Unowned queue
• Unmatched settlement
• Premature customer reversal

Recovery

• Identify the last confirmed settlement state
• Separate participant posting from settlement
• Close every ledger break

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Settlement submission

clear-participant-a → clear-access

Carry an authenticated, profile-valid settlement instruction into the infrastructure.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

An ambiguous technical outcome is reconciled before replay.

Admitted instruction

clear-access → clear-rule-engine

Pass only authenticated and technically valid content to scheme eligibility.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Technical rejection remains distinct from business or liquidity rejection.

Eligible gross instruction

clear-rule-engine → clear-queue

Queue an RTGS-eligible instruction with priority and participant controls.

Contract

settlement · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Ineligible items do not enter the settlement queue.

Funded RTGS release

clear-queue → clear-settlement-ledger

Post the debit and credit once required settlement asset is available.

Contract

settlement · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Insufficient liquidity keeps the item queued or causes the rule-defined outcome.

Cleared cycle item

clear-rule-engine → clear-net-cycle

Add an eligible item to a defined deferred-net cycle.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Late, duplicate, or unbalanced inputs stop or defer the cycle.

Net settlement obligation

clear-net-cycle → clear-settlement-ledger

Settle calculated participant obligations in the designated asset.

Contract

settlement · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A participant funding failure follows the documented default and settlement process.

Settlement confirmation

clear-settlement-ledger → clear-participant-b

Provide finality evidence for participant posting and reporting.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A delayed confirmation is reconciled against the settlement ledger before customer action.

Queue and liquidity telemetry

clear-queue → clear-operations

Make queued value, priority, age, and liquidity need visible.

Contract

operator · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Telemetry loss raises an incident; it does not alter queue order or settlement state.

Ledger and finality evidence

clear-settlement-ledger → clear-operations

Reconcile submitted, settled, rejected, and reported positions.

Contract

operator · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A break remains open until instruction and ledger evidence agree.

One funded RTGS payment

Follow an eligible high-value payment from participant release through queue control, central-bank settlement, beneficiary posting, and reconciliation.

1. Participant releases a funded payment — Participant released. The sending bank confirms eligibility, priority, cut-off, and available-liquidity intent.
2. Infrastructure authenticates the submission — Technically admitted. Identity, integrity, duplicate, envelope, and message-profile checks pass.
3. Scheme eligibility passes — Eligible for settlement. Participant status, service, limits, timing, and transaction rules permit settlement.
4. Queue releases against liquidity — Funded and released. The payment has sufficient settlement asset or qualifies under the documented liquidity-saving mechanism.
5. Settlement books debit and credit — Settled final. The designated settlement ledger posts the atomic participant debit and credit.
6. Receiver posts the beneficiary — Beneficiary posted. The receiving bank acts on confirmed settlement and applies account controls.
7. Positions reconcile — Reconciled. Submission, queue, finality, participant posting, and reporting evidence agree.

Insufficient settlement liquidity

The sending participant lacks sufficient available settlement asset when the instruction reaches the queue.

Last confirmed state

Eligible and queued; not settled.

Settlement

No final settlement has occurred.

Funds and entries

The participant's customer and internal reservation follow its own pre-settlement policy; the receiving participant has no settled funds.

Next owner

Participant treasury and settlement operations

Safe action

Keep the payment queued, fund or reprioritise under the applicable rules, and do not report settlement early.

Evidence required

• Queue position
• Priority
• Participant balance
• Cut-off
• Liquidity action

Recovery

• Add eligible liquidity or wait for incoming funds
• Release once rules permit
• Expire or reject at the applicable cut-off

Settlement ledger unavailable

The queue is ready to release but the settlement ledger becomes unavailable.

Last confirmed state

Funded and ready; final posting is not confirmed.

Settlement

Unknown or not settled until the ledger's authoritative state is recovered.

Funds and entries

Participant funds must not be double-debited and receiving participants must not infer finality.

Next owner

Settlement service incident command

Safe action

Stop further release, recover the authoritative ledger state, and reconcile every in-flight instruction before reopening.

Evidence required

• Last consistent checkpoint
• Transaction journal
• Queue snapshot
• Participant confirmations

Recovery

• Recover ledger
• Reconcile in-flight instructions
• Resume under the continuity decision

Final settlement, delayed beneficiary posting

Settlement is final but the receiving participant's core ledger is unavailable.

Last confirmed state

Settlement final; beneficiary posting pending.

Settlement

Final settlement has occurred and must not be casually reversed.

Funds and entries

Receiving participant holds the settled position; beneficiary funds await internal posting.

Next owner

Receiving participant payment and core-banking operations

Safe action

Repair the customer posting idempotently from final settlement evidence; do not resend the interbank payment.

Evidence required

• Finality reference
• Receiving account
• Posting journal
• Duplicate check

Recovery

• Restore posting service
• Post once
• Report delayed availability and reconcile

Should the service settle each instruction gross or settle net obligations?

• RTGS — Immediate transaction-by-transaction finality with higher intraday liquidity demand.
• Deferred net — Lower liquidity need through offsetting, with cycle, default, and delayed-finality risk.
• Hybrid or liquidity-saving — Combines gross legal treatment with queueing or offset logic; operational rules become more complex.

Choose from legal finality, risk appetite, time budget, liquidity, volume, and failure treatment—not from message format alone.

When should participant customer books be posted?

• Before settlement under controlled risk — Can improve customer speed but creates participant credit and reversal exposure.
• After settlement confirmation — Aligns posting to proven funds but depends on timely finality evidence.

Document the exact evidence and exception treatment. Clearing acceptance, settlement, and beneficiary posting are distinct states.