Instant-payment processing, settlement, timeout, and 24×7 operations architecture

Payer channel and confirmation

Captures an always-available payment intent and tells the payer what is known within a short time budget.

Kind

channel

Owner

Digital channel

Responsibilities

• Authenticate and confirm the payer's intent
• Show a truthful pending, rejected, or completed outcome

Inputs

• Payer, payee, amount, account or proxy, confirmation

Outputs

• Idempotent instant-payment request

Controls

• Authentication
• Entitlement
• Confirmation
• Client idempotency key

Failure modes

• Repeated tap
• Channel timeout
• Stale payee verification

Recovery

• Enquire using the same reference
• Do not create a second payment while outcome is unknown

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

Sending instant-payment engine

Completes validation, controls, posting intent, routing, and submission inside the service time budget.

Kind

application

Owner

Sending payment product and technology

Responsibilities

• Validate and route quickly
• Coordinate screening and fraud decisions
• Reserve or debit under policy

Inputs

• Confirmed instant-payment request
• Reference and risk data

Outputs

• Network instruction and durable pending state

Controls

• Duplicate detection
• Account and funds check
• Time-budget enforcement

Failure modes

• Control exceeds time budget
• Unknown network outcome
• Internal posting lag

Recovery

• Stop or time out under the rail rules
• Reconcile before retry
• Release reservations from proven outcomes

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

Real-time fraud, sanctions, and payee controls

Returns a clear, reasoned outcome without letting a control timeout become an accidental approval.

Kind

control

Owner

Fraud and financial crime teams

Responsibilities

• Assess transaction and party risk
• Apply payee-verification outcome where the service uses it

Inputs

• Payment, customer, device, party, list, and behavioural data

Outputs

• Clear, stop, challenge, or controlled timeout

Controls

• Fail-safe policy
• List freshness
• Model/rule version
• Decision audit

Failure modes

• Control timeout
• False positive
• Stale list or model

Recovery

• Apply the documented fail-safe outcome
• Investigate without hiding the payment 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

Instant clearing and routing service

Validates and routes the payment or settlement instruction continuously under the rail’s timeout rules.

Kind

external-network

Owner

Instant-payment infrastructure operator

Responsibilities

• Confirm participant reachability
• Apply rail validation and duplicate controls
• Route or settle within the service clock

Inputs

• Instant-payment message

Outputs

• Acceptance, rejection, timeout, or settlement outcome

Controls

• Participant status
• Duplicate detection
• Service clock
• Availability

Failure modes

• Unavailable receiver
• Network timeout
• Duplicate or invalid message

Recovery

• Return the rule-defined outcome
• Support status enquiry and exception handling

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

Instant settlement accounts

Moves central-bank or designated settlement asset per transaction or under the rail’s funded model.

Kind

ledger

Owner

Central bank or instant-settlement operator

Responsibilities

• Check funded capacity
• Post the settlement movement
• Return finality evidence

Inputs

• Eligible instant settlement instruction

Outputs

• Settlement debit and credit

Controls

• Available funds
• Atomic posting
• Finality evidence

Failure modes

• Insufficient prefunding
• Settlement service unavailable
• Posting uncertainty

Recovery

• Reject or queue only where rules permit
• Reconcile the authoritative ledger 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

Receiving instant-payment engine

Validates the beneficiary and posts funds once the rail’s conditions and settlement evidence are satisfied.

Kind

application

Owner

Receiving payment product and technology

Responsibilities

• Validate the destination account
• Respond within the rail clock
• Post once and report availability

Inputs

• Instant payment
• Settlement outcome

Outputs

• Beneficiary posting and response

Controls

• Account status
• Duplicate posting protection
• Settlement-state check

Failure modes

• Invalid account
• Receiver response timeout
• Core ledger unavailable

Recovery

• Return the rule-defined response
• Repair posting idempotently after confirmed settlement

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

Status, exception, and reconciliation service

Connects customer status, network outcome, settlement, participant posting, return, and investigation evidence.

Kind

operations

Owner

Instant-payment operations

Responsibilities

• Answer status enquiries from authoritative state
• Reconcile timeouts and late outcomes
• Control returns and investigations

Inputs

• Network status
• Settlement evidence
• Participant postings
• Customer enquiry

Outputs

• Truthful customer status
• Resolved timeout
• Return or investigation

Controls

• Original-reference integrity
• Late-status ordering
• Four-eyes funds action

Failure modes

• Late positive response after customer timeout
• Duplicate return
• Conflicting participant states

Recovery

• Establish settlement first
• Correct customer status without duplicating value
• Use the rail's exception path

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

24×7 service operations and continuity

Maintains round-the-clock observability, capacity, failover, change, and incident ownership.

Kind

operations

Owner

Participant and infrastructure service operations

Responsibilities

• Operate without a daily recovery window
• Coordinate participant and infrastructure incidents
• Protect the service clock during failover

Inputs

• Latency, queue, error, liquidity, and dependency telemetry

Outputs

• Incident action, capacity action, continuity decision

Controls

• Error budget
• Change freeze and rollback
• Failover test
• On-call ownership

Failure modes

• Cascading dependency latency
• Capacity exhaustion
• Uncoordinated maintenance

Recovery

• Shed or stop safely under the rules
• Fail over without duplicate value
• Reconcile in-flight payments

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

Confirmed instant request

instant-payer → instant-sender

Start one idempotent payment and its end-to-end time budget.

Contract

api · synchronous

Controls

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

Failure treatment

A channel timeout preserves the client reference for enquiry.

Bounded control request

instant-sender → instant-controls

Obtain explicit fraud, sanctions, and payee-control outcomes.

Contract

control · synchronous

Controls

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

Failure treatment

Unavailable or late controls follow a documented fail-safe outcome.

Instant payment submission

instant-sender → instant-network

Submit the payment once participant checks and controls pass.

Contract

message · asynchronous

Controls

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

Failure treatment

An ambiguous send is enquired before any retry.

Per-payment settlement

instant-network → instant-settlement

Move funded settlement asset under the rail's model.

Contract

settlement · synchronous

Controls

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

Failure treatment

Insufficient funds or unavailable settlement returns the rule-defined outcome.

Routed payment and response

instant-network → instant-receiver

Deliver the payment and receive the beneficiary validation result.

Contract

message · asynchronous

Controls

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

Failure treatment

A missing receiver response becomes a precise timeout state, not an automatic success.

Settlement evidence

instant-settlement → instant-receiver

Prove the settlement state used by the receiver's posting policy.

Contract

event · asynchronous

Controls

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

Failure treatment

Delayed evidence is reconciled before duplicate or reversal action.

Beneficiary outcome

instant-receiver → instant-reporting

Record the receiving decision and posting state.

Contract

event · asynchronous

Controls

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

Failure treatment

Late or conflicting outcomes enter ordered reconciliation.

Customer outcome

instant-reporting → instant-payer

Tell the payer only the outcome supported by current evidence.

Contract

api · synchronous

Controls

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

Failure treatment

Unknown remains pending or timed out; it is not changed to failed merely to close the screen.

Service-clock telemetry

instant-network → instant-resilience

Expose availability, latency, error, and participant health.

Contract

operator · asynchronous

Controls

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

Failure treatment

Telemetry loss raises an incident and does not fabricate payment status.

One funded instant credit transfer

Follow one payment through payer confirmation, bounded controls, network routing, settlement, beneficiary posting, and customer status.

1. Payer confirms once — Customer confirmed. The channel creates one stable reference and starts the service clock.
2. Sender validates and funds — Participant accepted. Account, funds, duplicates, route, and time budget pass.
3. Controls clear — Controls cleared. Fraud, sanctions, and applicable payee checks return an explicit outcome.
4. Network admits the payment — Network accepted. The infrastructure validates participant, message, duplicate, and service timing.
5. Settlement moves — Settled final. Funded settlement asset moves under the rail's model.
6. Beneficiary posts — Beneficiary credited. The receiving participant validates and posts once.
7. Outcome reconciles — End-to-end confirmed. Network, settlement, and participant posting evidence agree.
8. Payer sees the proven result — Customer informed. The channel reports completed only when the authoritative state supports it.

Timeout with a late positive outcome

The payer-facing timer expires while settlement or receiver response is still in flight.

Last confirmed state

Network accepted; final settlement and beneficiary posting are not yet confirmed to the sender.

Settlement

Unknown until the settlement service returns authoritative evidence.

Funds and entries

The payer's debit or reservation stays under pending-outcome control; no second payment is created.

Next owner

Sending participant instant-payment operations

Safe action

Show a truthful pending or timed-out status, enquire with the original reference, and accept a late final outcome in state order.

Evidence required

• End-to-end reference
• Network timestamp
• Settlement result
• Receiver response

Recovery

• Reconcile late outcome
• Update the customer once
• Release or retain postings according to final state

Insufficient prefunding

The sender lacks the settlement asset required by the instant service.

Last confirmed state

Payment admitted to the service; settlement not completed.

Settlement

Not settled unless the rail explicitly permits queueing and later confirms it.

Funds and entries

Receiver has no settled funds; sender must apply the rail-defined rejection or liquidity treatment.

Next owner

Participant treasury and instant-payment operations

Safe action

Apply the documented liquidity response and do not report completion.

Evidence required

• Settlement balance
• Liquidity threshold
• Rail response
• Customer posting state

Recovery

• Fund the account for future payments
• Close or retry only if the rail and customer contract permit

Settlement final, receiver core unavailable

The instant settlement movement is final but the receiving participant cannot post the beneficiary account.

Last confirmed state

Settlement final; beneficiary posting pending.

Settlement

Final under the rail's settlement rules.

Funds and entries

The receiving participant holds settled funds and owes controlled resolution to the beneficiary.

Next owner

Receiving participant payment and core-ledger operations

Safe action

Repair the beneficiary posting idempotently; do not resend or reverse the interbank payment without the formal exception path.

Evidence required

• Settlement reference
• Receiving account result
• Posting journal
• Customer-status history

Recovery

• Restore core service
• Post once
• Report and reconcile the delay

What should the payer see when the service clock expires?

• Failed — Simple screen, but dangerous when network or settlement outcome is unknown.
• Pending or timed out — Truthfully preserves uncertainty and requires enquiry and later status update.

Use a state that represents evidence. A user-interface timer does not reverse network acceptance or settlement.

How should a real-time control outage behave?

• Fail closed — Stops risk but reduces availability and may breach customer expectations.
• Fail open — Preserves speed but creates explicit financial-crime or fraud exposure.
• Risk-tiered fallback — Uses bounded, pre-approved criteria and requires measurable governance.

The choice is a governed risk decision. Return an explicit unavailable outcome and never let a timeout look like a clean approval.