PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

Enterprise payments capability and system landscape

Start with the whole estate: the customer asks, the bank controls and records, an external arrangement clears or settles, and operations prove the result.

Reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. The landscape shows one sending institution, one receiving institution, and one external arrangement. Real payments may cross several intermediaries, control platforms, ledgers, gateways, and settlement venues.

Audience and purpose

Aspiring payment architects, solution architects, business analysts, operations leads, and technology teams

Components

Customer or operations user

The person or system that asks the bank to move money.

Kind

actor

Owner

Customer, corporate treasury, or bank operations

Responsibilities

Provide the payment intent
Approve the instruction
Receive a clear outcome

Inputs

Invoice, beneficiary details, amount, currency, requested execution date

Outputs

Approved payment instruction

Controls

Strong authentication where applicable
Entitlement and approval limits

Failure modes

Incorrect details
Duplicate submission
Expired approval

Recovery

Repair before release
Cancel while still cancellable
Submit a new instruction only after outcome is known

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Payment channel

The controlled doorway through which an instruction enters the bank.

Kind

channel

Owner

Digital channels or corporate channels

Responsibilities

Capture data
Authenticate the user
Apply channel limits
Return immediate status

Inputs

Customer instruction and authentication evidence

Outputs

Normalised intake request

Controls

Authentication
Entitlements
Input validation
Rate and amount limits

Failure modes

Malformed request
Authentication failure
Channel timeout

Recovery

Reject safely before acceptance
Preserve a client reference for retry and enquiry

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Payment hub and processing core

The bank’s coordinator: it decides what happens next and remembers what already happened.

Kind

application

Owner

Payments technology and payments product

Responsibilities

Validate and enrich
Coordinate screening and fraud checks
Choose a route
Control posting and release
Track the complete lifecycle

Inputs

Accepted intake request
Reference data
Control outcomes

Outputs

Recorded payment state
Posting request
Network instruction
Status

Controls

Duplicate detection
Validation
State transition rules
Four-eyes repair where required

Failure modes

Stalled workflow
Conflicting status
Incorrect route
Partial downstream success

Recovery

Resume from the last durable state
Reconcile before replay
Escalate ambiguous outcomes

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Reference and standing data

The controlled facts used to validate, enrich, and route a payment.

Kind

data-store

Owner

Reference-data operations

Responsibilities

Provide BICs and clearing identifiers
Provide calendars and cut-offs
Provide standing settlement instructions

Inputs

Official directories
Scheme publications
Approved internal configuration

Outputs

Versioned routing and enrichment facts

Controls

Maker-checker updates
Freshness monitoring
Rollback
Provenance

Failure modes

Stale directory
Missing route
Incorrect effective date

Recovery

Stop affected routing
Restore a verified version
Revalidate impacted payments

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Screening and fraud controls

The checkpoints that decide whether processing may continue, must pause, or must stop.

Kind

control

Owner

Financial crime and fraud operations

Responsibilities

Screen relevant parties and text
Assess fraud risk
Return a reasoned outcome

Inputs

Payment parties, identifiers, addresses, remittance, device and behaviour signals

Outputs

Proceed, hold, reject, or investigate outcome

Controls

List currency
Decision trace
Threshold governance
Case correlation

Failure modes

Control unavailable
Alert spike
Unmapped field
Duplicate alert

Recovery

Apply the documented failure posture
Queue or stop safely
Re-screen after recovery

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Customer and internal ledger

The bank’s books: holds, debits, credits, suspense, fees, and settlement-account mirrors.

Kind

ledger

Owner

Core banking and finance

Responsibilities

Check available funds
Reserve or post value
Preserve balanced accounting
Expose booking evidence

Inputs

Authorised posting command

Outputs

Posting result and immutable accounting reference

Controls

Balanced entries
Posting uniqueness
Reversal instead of erasure
Account entitlement

Failure modes

Insufficient funds
Posting timeout
Conflicting duplicate
Unbalanced entry

Recovery

Query by posting key
Reverse with an equal and opposite entry
Never retry blindly

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Rail or network gateway

The edge adapter that speaks one external network’s protocol.

Kind

gateway

Owner

Payments connectivity

Responsibilities

Transform the outbound envelope
Sign and transmit
Receive acknowledgements and reports

Inputs

Released network instruction

Outputs

Delivery evidence, acknowledgement, status, report

Controls

Network entitlement
Message signing
Sequence and duplicate checks
Delivery reconciliation

Failure modes

Network unavailable
Transport rejection
Unknown delivery outcome

Recovery

Query network evidence
Resubmit only under the network’s duplicate rules
Escalate ambiguity

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Payment network or market infrastructure

The external arrangement that exchanges, clears, or settles obligations under its own rules.

Kind

external-network

Owner

Scheme, network, clearing system, or central bank

Responsibilities

Validate participant submissions
Apply service rules
Clear or settle as applicable
Return evidence

Inputs

Network-valid instruction

Outputs

Acceptance, rejection, clearing result, settlement result, reports

Controls

Participant eligibility
Message validation
Finality rules
Operational timetable

Failure modes

Scheme rejection
Liquidity queue
Service outage
Participant unavailable

Recovery

Follow scheme contingency and enquiry procedures
Preserve finality and duplicate rules

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Receiving institution

The institution that accepts the interbank instruction and credits or otherwise services the receiving account.

Kind

infrastructure

Owner

Receiving institution

Responsibilities

Validate receipt
Apply controls
Post the beneficiary side
Return status and reporting

Inputs

Interbank payment and settlement evidence

Outputs

Beneficiary posting, status, return or investigation

Controls

Beneficiary validation
Screening
Posting correlation
Return controls

Failure modes

Invalid beneficiary
Account closed
Posting delay
Return required

Recovery

Reject before finality where allowed
Return through the governed process after settlement

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Operations, investigations, and reconciliation

The people and queues that resolve anything the automated path cannot prove safely.

Kind

operations

Owner

Payment operations

Responsibilities

Monitor queues
Repair permitted data
Investigate holds
Reconcile postings and external evidence

Inputs

Exceptions, alerts, acknowledgements, statements, ledger entries

Outputs

Released, repaired, returned, escalated, or reconciled outcome

Controls

Segregation of duties
Reason codes
Service-level monitoring
Audit trail

Failure modes

Queue backlog
Incorrect manual release
Missing evidence
Premature closure

Recovery

Prioritise by risk and cut-off
Require evidence before release or replay
Reopen unresolved cases

Non-functional requirements

Traceable processing with stable identifiers
Capacity and availability matched to the supported payment service
Auditable state changes and operator actions

Interfaces

Payment request

customer → channel

Capture an authenticated request with a stable customer reference.

Contract

api · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Reject before acceptance and return a reusable correlation reference.

Accepted instruction

channel → payment-hub

Hand one normalised instruction to the processing core.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

The channel must distinguish not accepted from accepted but still processing.

Routing facts

reference-data → payment-hub

Supply versioned routing, calendar, and enrichment data.

Contract

api · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Do not guess a route when authoritative reference data is missing or stale.

Control decision

payment-hub → screening-risk

Obtain a proceed, hold, or stop outcome before the irreversible boundary.

Contract

control · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Apply the approved failure posture; never silently bypass the checkpoint.

Posting command

payment-hub → customer-ledger

Reserve or post value exactly once using a durable posting key.

Contract

posting · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Query the posting result before any retry when the response is unknown.

Released instruction

payment-hub → network-gateway

Transmit the scheme-specific payment only after release controls pass.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Record delivery evidence and prevent an unproved duplicate submission.

Network message

network-gateway → payment-network

Cross the institution boundary using the network’s secured transport.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

A transport acknowledgement proves delivery, not necessarily settlement or beneficiary credit.

Cleared or routed payment

payment-network → receiving-bank

Carry the accepted obligation and, where applicable, settlement evidence to the receiver.

Contract

settlement · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Apply the service’s reject, return, timeout, and contingency rules.

Status and settlement evidence

payment-network → operations

Feed acknowledgements, statements, and settlement results into monitoring and reconciliation.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Keep unmatched evidence in a controlled queue rather than inventing an outcome.

Internal books

customer-ledger → operations

Provide the internal side of posting and balance reconciliation.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

A missing or duplicate event creates a reconciliation break; it does not change the ledger fact.

Authored traces

One controlled credit transfer

Asha Traders sends one supplier payment from capture through reconciliation.

Capture the instruction — RECEIVED. Asha Traders asks Bank Alfa to pay its supplier.
Accept into processing — ACCEPTED. The bank records one instruction with a stable identity.
Resolve the route — ENRICHED. The hub reads current routing, calendar, and settlement facts.
Apply control decisions — CONTROLLED. Screening and fraud controls decide whether processing may continue.
Record the customer-side value — POSTED. The bank reserves or posts the value on its own books.
Release to the network — RELEASED. The bank creates and secures the network-specific instruction.
Clear or settle under the service rules — NETWORK_ACCEPTED. The external service validates and processes the instruction.
Service the receiving account — BENEFICIARY_CREDITED. The receiving institution credits the beneficiary when its rules and settlement evidence allow.
Prove the result — RECONCILED. Operations match internal postings, network evidence, and reporting to one economic payment.

Stress cases

Screening hold

The control service finds a possible sanctions-list match.

Last confirmed state

The payment is accepted and enriched but not released.

Settlement

Interbank settlement has not occurred.

Funds and entries

Any customer-side reservation remains controlled on Bank Alfa’s books.

Next owner

Sanctions investigation with payment operations monitoring the payment state

Safe action

Keep the instruction on hold until an authorised investigator records and applies a disposition.

Evidence required

Matched fields
Watchlist record and version
Investigator reasoning
Release or stop authority

Recovery

Resolve the alert
Apply the recorded outcome once
Resume from the held state or stop under policy

Ledger response timeout

The posting request times out after the ledger may already have accepted it.

Last confirmed state

Control checks passed; the posting outcome is unknown.

Settlement

The network instruction has not been released.

Funds and entries

The customer may already be debited or reserved, so a blind retry could double post.

Next owner

Payment-platform operations with core-ledger support

Safe action

Query the ledger using the original idempotency key before retrying or reversing anything.

Evidence required

Posting key
Ledger journal result
Payment state history
Operator decision

Recovery

Query
Correlate
Adopt the proven result
Retry only if the ledger proves no posting exists

Unknown network delivery outcome

The connection drops after transmission but before a delivery acknowledgement returns.

Last confirmed state

The instruction was released; external acceptance is not yet proven.

Settlement

Unknown until network evidence or reporting is received.

Funds and entries

The sending-side posting exists; the external outcome must be established before replay.

Next owner

Payment operations and network-connectivity support

Safe action

Use the network enquiry and duplicate-control procedure; do not create a new payment.

Evidence required

Original network reference
Transport log
Network acknowledgement or enquiry
Settlement report

Recovery

Hold automatic retry
Query delivery
Reconcile late evidence
Resume, return, or investigate based on proven status

Design decisions

Which component owns the authoritative payment lifecycle?

Payment hub — One processing record can coordinate channels and rails, but the hub must not pretend to own ledger or settlement facts.
Channel — Channel-specific state is simple at first but fragments processing and duplicate control across products.

Name one lifecycle owner and name the external facts it consumes; do not create two components that can both independently release the same instruction.

When does customer posting occur relative to network release?

Post or reserve before release — Controls funds before the payment leaves, but ambiguous downstream outcomes require careful reconciliation.
Post after external acceptance — Reduces some reversals but requires a safe reservation and exposes a different partial-failure window.

Specify reservation, posting, release, reversal, and reconciliation as separate states with idempotent commands.

What happens when an in-line control is unavailable?

Queue or stop — Protects the control objective but consumes the payment service’s time budget and creates an operations queue.
Use an approved alternate control — Can preserve service only if the alternate has documented coverage, evidence, and authority.

Write and test the failure posture per payment service; never discover it during an outage.

Sources and disclosed synthesis

Principles for financial market infrastructures — Principles 8, 9, 17, and 22 · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
ISO 20022 Catalogue of messages — Payments business area · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Whole-estate synthesis · Payments Signal reference architecture v1 · checked 2026-07-23 · The diagram is a vendor-neutral teaching construction. Real institutions split, combine, outsource, and duplicate these capabilities.
Payments Signal editorial teaching models — Component: Customer or operations user · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Payment channel · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Payment hub reference boundary · Payments Signal reference architecture v1 · checked 2026-07-23 · A real bank may distribute these capabilities across several products, services, or legacy platforms.
ISO 20022 Catalogue of messages — Payments business area and message catalogue · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Component: Reference and standing data · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Screening and fraud controls · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Customer and internal ledger · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Rail or network gateway · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — External payment network boundary · Payments Signal reference architecture v1 · checked 2026-07-23 · Clearing and settlement may be performed by different infrastructures and at different times.
Payments Signal editorial teaching models — Component: Receiving institution · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Operations, investigations, and reconciliation · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Interface: Payment request · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
ISO 20022 Catalogue of messages — Payments initiation message definitions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Interface: Routing facts · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Control decision · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Posting command · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Released instruction · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Interface: Network message · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Principles for financial market infrastructures — Principles 8 and 9 · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
ISO 20022 Catalogue of messages — Payments clearing and settlement and cash-management message definitions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Interface: Internal books · Payments Signal reference architecture v1 · checked 2026-07-23 · The transport and interface contract are illustrative; implementations select their own protocol.
Payments Signal editorial teaching models — Enterprise trace · Payments Signal reference architecture v1 · checked 2026-07-23 · The trace compresses institution-specific approval, posting, clearing, and settlement timing into one readable sequence.
ISO 20022 Catalogue of messages — Payments initiation, clearing and settlement, and cash-management catalogues · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Screening-hold stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · Legal treatment and failure posture depend on the applicable regime and institution policy.
Payments Signal editorial teaching models — Ledger-timeout stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · Posting APIs and recovery commands vary by ledger platform.
Principles for financial market infrastructures — Principle 17 — operational risk · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
Payments Signal editorial teaching models — Architecture decision: lifecycle ownership · Payments Signal reference architecture v1 · checked 2026-07-23 · Institutions choose different system-of-record boundaries.
Payments Signal editorial teaching models — Architecture decision: posting boundary · Payments Signal reference architecture v1 · checked 2026-07-23 · Rail rules, credit policy, and ledger capability determine the final sequence.