PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

Payment engine and payment-hub internals

Open the processing core: identity, validation, controls, routing, posting, message assembly, network release, exceptions, and the evidence plane that joins them.

Reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. The blueprint shows one processing core with one adapter per major dependency. Real estates may contain several payment engines, migration bridges, country platforms, shared services, and manual hand-offs.

Audience and purpose

Payment solution architects, product owners, business analysts, developers, testers, and operations leads

Components

Ingress and acceptance

Receives the instruction, authenticates its source, and decides whether the bank has accepted it for processing.

Kind

service

Owner

Payment platform

Responsibilities

Validate the envelope
Assign a durable identity
Return acceptance separately from completion

Inputs

Channel request

Outputs

Accepted canonical intake

Controls

Source authentication
Schema and envelope validation
Rate limiting

Failure modes

Invalid envelope
Repeated client reference
Acceptance response lost

Recovery

Query by client reference
Return the existing payment identity

Non-functional requirements

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

Canonical payment record

The bank’s stable internal description of the payment and its history.

Kind

data-store

Owner

Payment platform

Responsibilities

Preserve original data
Store normalised fields
Link every downstream identifier

Inputs

Accepted instruction and subsequent events

Outputs

Current state and complete event history

Controls

Immutable history
Optimistic concurrency
Data retention

Failure modes

Schema drift
Lost correlation
Conflicting update

Recovery

Reject incompatible events
Rebuild current state from the journal

Non-functional requirements

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

Identity and duplicate control

Determines whether a request is new, a safe repeat, or a conflicting duplicate.

Kind

control

Owner

Payment platform

Responsibilities

Own idempotency keys
Compare economic identity
Return the prior outcome for safe repeats

Inputs

Client, payment, message, transaction, and posting identifiers

Outputs

New, repeat, or conflict decision

Controls

Unique constraints
Time-window policy
Payload fingerprint

Failure modes

False duplicate
Duplicate missed
Key reused with changed data

Recovery

Stop conflicting reuse
Correlate against the authoritative record

Non-functional requirements

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

Validation and enrichment

Checks that the instruction is usable and fills only facts the bank is authorised to supply.

Kind

service

Owner

Payment product and reference-data operations

Responsibilities

Apply product and profile rules
Resolve parties and routes
Preserve provenance

Inputs

Canonical instruction
Profile rules
Reference data

Outputs

Validated and enriched payment or reasoned repair item

Controls

Versioned rules
No silent truncation
Field-level provenance

Failure modes

Missing data
Invalid profile
Stale enrichment

Recovery

Repair only permitted fields
Revalidate under the same or explicitly migrated rule version

Non-functional requirements

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

Lifecycle orchestrator

Runs the controlled sequence and records which command may happen next.

Kind

application

Owner

Payment platform

Responsibilities

Apply state transitions
Invoke controls
Coordinate posting and release
Handle timers

Inputs

Validated payment and downstream outcomes

Outputs

Commands, events, current state, exceptions

Controls

Allowed transition table
Command uniqueness
Timeout policy

Failure modes

Stuck state
Out-of-order result
Partial success

Recovery

Resume from durable state
Quarantine impossible transitions

Non-functional requirements

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

Screening adapter

Maps the payment’s relevant fields into the screening service and preserves its evidence.

Kind

control

Owner

Payments controls and financial crime technology

Responsibilities

Map all governed fields
Invoke the correct screening mode
Correlate alerts and dispositions

Inputs

Parties, agents, addresses, identifiers, and narrative

Outputs

Proceed, hold, or stop plus evidence reference

Controls

Field-coverage mapping
Configuration version
Case linkage

Failure modes

Unmapped field
Timeout
Duplicate alert

Recovery

Hold under the approved posture
Re-screen after recovery
Reuse a valid prior result only under policy

Non-functional requirements

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

Rail and route decision

Chooses a reachable service using amount, currency, speed, cost, cut-off, risk, and customer promise.

Kind

service

Owner

Payment product

Responsibilities

Assess candidate rails
Check reachability
Record the route decision

Inputs

Validated payment and current route facts

Outputs

Selected route and fallback constraints

Controls

No unsupported route
Cut-off and calendar checks
Customer promise consistency

Failure modes

No reachable route
Cut-off missed
Fallback changes semantics

Recovery

Queue, re-date, repair, or reject according to the product contract

Non-functional requirements

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

Message assembly and transformation

Creates the exact outbound message without inventing or silently losing meaning.

Kind

service

Owner

Payments integration

Responsibilities

Map canonical data
Apply the profile
Build headers
Record truncation or translation treatment

Inputs

Canonical payment and target profile

Outputs

Network message and transformation evidence

Controls

Profile validation
Data-loss checks
Message identifier uniqueness

Failure modes

Profile rejection
Truncation
Code translation error

Recovery

Repair source data or mapping
Never patch only the outbound copy without preserving provenance

Non-functional requirements

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

Ledger adapter

Turns a payment state transition into an idempotent accounting command and interprets the result.

Kind

service

Owner

Payments and core-banking integration

Responsibilities

Create posting keys
Separate reservation, posting, release, and reversal
Correlate journal evidence

Inputs

Posting intent

Outputs

Posting result and journal reference

Controls

Balanced accounting
Posting uniqueness
Unknown-outcome recovery

Failure modes

Timeout
Rejected posting
Already posted

Recovery

Query first
Adopt the proven result
Reverse through a separate authorised command

Non-functional requirements

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

Network adapter

Owns one network connection and translates its transport events into payment evidence.

Kind

gateway

Owner

Payments connectivity

Responsibilities

Secure the connection
Transmit
Receive acknowledgements
Expose service health

Inputs

Released network message

Outputs

Transport, network, and settlement evidence

Controls

Network entitlement
Signing
Sequence
Replay protection

Failure modes

Connection failure
Negative acknowledgement
Delivery ambiguity

Recovery

Use network enquiry and duplicate rules
Fail over only under approved sequencing controls

Non-functional requirements

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

Repair and case workbench

Shows the payment’s facts and permits only controlled actions appropriate to its state.

Kind

operations

Owner

Payment operations

Responsibilities

Explain the hold
Collect evidence
Apply authorised repair, release, return, or escalation

Inputs

Exception, history, evidence, permissions

Outputs

Reasoned operator command and case outcome

Controls

Segregation of duties
Permitted-action matrix
Reason and evidence capture

Failure modes

Unsafe action offered
Stale screen
Concurrent action

Recovery

Recheck current state before command
Reject stale or unauthorised actions

Non-functional requirements

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

Audit, metrics, traces, and reconciliation events

Makes every decision, command, dependency, and outcome observable without changing the payment.

Kind

operations

Owner

Platform operations and payment operations

Responsibilities

Correlate logs and traces
Measure queues and latency
Publish reconciliation evidence

Inputs

Events from every component

Outputs

Audit records, alerts, dashboards, reconciliation feeds

Controls

Sensitive-data minimisation
Clock synchronisation
Retention
Access logging

Failure modes

Telemetry gap
Uncorrelated trace
Sensitive-data leakage

Recovery

Restore collection
Reconstruct from authoritative journals
Treat missing evidence as a control issue

Non-functional requirements

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

Interfaces

Identify the request

hub-ingress → hub-dedup

Decide whether the instruction is new, repeated, or conflicting.

Contract

api · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Do not create a second payment for the same accepted identity.

Create or retrieve payment

hub-dedup → hub-canonical

Persist one authoritative record and return its existing identity for safe repeats.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Reject conflicting reuse and preserve the original record.

Validate and enrich

hub-canonical → hub-validation

Apply the correct product and profile rules.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Create a reasoned repair or reject outcome.

Start controlled processing

hub-validation → hub-orchestrator

Advance only after validation succeeds.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Keep validation failure outside the released path.

Screen relevant data

hub-orchestrator → hub-screening

Obtain a governed control outcome.

Contract

control · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Hold or stop under the documented failure posture.

Choose the service

hub-orchestrator → hub-routing

Select and record a reachable route.

Contract

api · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Queue, re-date, repair, or reject; never silently change the customer promise.

Reserve or post

hub-orchestrator → hub-ledger-adapter

Create the required balanced entries once.

Contract

posting · synchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Resolve unknown outcomes by posting key before retry.

Build target message

hub-routing → hub-transform

Apply the route’s exact profile and mapping.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Stop on data loss or profile failure.

Transmit released message

hub-transform → hub-network-adapter

Hand the secured network payload to its connection.

Contract

message · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Correlate transport evidence and prevent duplicate release.

Controlled exception

hub-orchestrator → hub-ops-case

Give operations the evidence and only the actions valid for the current state.

Contract

operator · operator

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Reject stale or unauthorised operator commands.

Lifecycle evidence

hub-canonical → hub-observability

Publish state changes and correlation data for monitoring and reconciliation.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Repair the evidence pipeline without rewriting the authoritative payment record.

Network evidence

hub-network-adapter → hub-observability

Publish delivery, acknowledgement, and service-health facts.

Contract

event · asynchronous

Controls

Authentication
Authorisation
Integrity
Correlation
Audit

Failure treatment

Surface evidence gaps and prevent premature reconciliation closure.

Authored traces

Process one new payment

Follow a new instruction through identity, controls, posting, and network release.

Accept the request — RECEIVED. The hub authenticates the source and separates acceptance from completion.
Prove it is new — IDENTIFIED. Identity controls decide whether this is a new payment or a repeat.
Create the payment record — ACCEPTED. One durable record now owns the lifecycle and its references.
Validate and enrich — VALIDATED. The hub checks profile and product rules and resolves authorised reference data.
Start controlled processing — PROCESSING. The state machine decides which commands are now permitted.
Obtain control decisions — CONTROLLED. The screening adapter submits every governed field and records the result.
Choose the route — ROUTED. The routing service records why this rail and profile fit the instruction.
Record value once — POSTED. The adapter uses one posting key and returns journal evidence.
Build the network message — ASSEMBLED. Canonical data becomes the exact versioned profile required by the selected route.
Release through the gateway — SENT. The secured connection transmits the message and returns network evidence.
Publish the evidence — TRACKED. Operations can now trace the payment without changing it.

Stress cases

Conflicting duplicate

The same idempotency key arrives with a changed amount or beneficiary.

Last confirmed state

The original payment remains authoritative; the new request is a conflict.

Settlement

The conflict creates no new settlement instruction.

Funds and entries

No second reservation or posting is permitted.

Next owner

Payment-platform operations

Safe action

Reject the changed reuse and return the original correlation reference without creating another payment.

Evidence required

Idempotency key
Original payload fingerprint
New payload fingerprint
Original payment state

Recovery

Preserve the original
Reject the conflict
Investigate the caller if repeated

Screening service timeout

The screening adapter receives no decision within its time budget.

Last confirmed state

The payment is validated but has no control clearance.

Settlement

No network release or interbank settlement has occurred.

Funds and entries

Any reservation remains under the bank’s documented hold treatment.

Next owner

Financial-crime technology and payment operations

Safe action

Apply the approved failure posture and keep control evidence explicit.

Evidence required

Control request
Timeout timestamp
Service health
Fallback or hold authority

Recovery

Hold or queue
Restore the control service
Re-screen
Resume once under the same payment identity

Unknown ledger outcome

The ledger connection fails after it may have accepted the posting.

Last confirmed state

The payment passed controls; the posting response is unknown.

Settlement

Network release remains blocked.

Funds and entries

The ledger may contain the reservation or debit.

Next owner

Payment-platform and ledger operations

Safe action

Query by posting key and adopt the proven result before any retry.

Evidence required

Posting command
Idempotency key
Ledger journal
Payment event history

Recovery

Query
Correlate
Adopt or retry
Record the recovery decision

Design decisions

Does the hub use a canonical internal model or keep each rail’s format end to end?

Canonical model — Centralises orchestration and controls but requires explicit, versioned mappings and data-loss governance.
Rail-native models — Preserves profile detail but duplicates logic and makes cross-rail operations harder to standardise.

Choose deliberately; if a canonical model is used, preserve original payloads and prove every transformation.

Which processing steps block the caller and which continue asynchronously?

Short synchronous acceptance — Protects channel latency and scales better, but customers need honest pending status and later updates.
Synchronous completion — Can simplify selected instant journeys but couples the channel to every downstream dependency and timeout.

Define acceptance, processing, settlement, and beneficiary credit as separate promises.

Sources and disclosed synthesis

ISO 20022 Catalogue of messages — Payments business model and message definitions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
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 — Payment hub synthesis · Payments Signal reference architecture v1 · checked 2026-07-23 · This is a capability architecture, not a description of one vendor product. Banks distribute the capabilities differently.
Payments Signal editorial teaching models — Component: Ingress and acceptance · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Canonical payment record · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Identity and duplicate control · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
ISO 20022 Catalogue of messages — Message definitions and implementation-community restrictions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Component: Lifecycle orchestrator · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Screening adapter · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Rail and route decision · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
ISO 20022 Catalogue of messages — Message catalogue and versioned schemas · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Component: Ledger adapter · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Network adapter · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Payments Signal editorial teaching models — Component: Repair and case workbench · Payments Signal reference architecture v1 · checked 2026-07-23 · Component boundaries and product names vary between institutions.
Principles for financial market infrastructures — Principle 17 — operational reliability, incident management, and capacity · CPMI-IOSCO Principles for financial market infrastructures · checked 2026-07-23
Payments Signal editorial teaching models — Interface: Identify the request · 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: Create or retrieve payment · 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: Validate and enrich · 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: Start controlled processing · 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: Screen relevant data · 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: Choose the service · 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: Reserve or post · 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: Build target message · 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: Transmit released message · 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: Controlled exception · 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: Lifecycle evidence · 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 evidence · 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 — Payment-hub trace · Payments Signal reference architecture v1 · checked 2026-07-23 · The sequence is a vendor-neutral state model; real products may parallelise or combine steps.
ISO 20022 Catalogue of messages — Payments message definitions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Duplicate-control stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · Idempotency windows and economic-identity rules are institution-specific.
Payments Signal editorial teaching models — Unknown-posting stress case · Payments Signal reference architecture v1 · checked 2026-07-23 · The exact query and reversal interfaces depend on the ledger.
ISO 20022 Catalogue of messages — ISO 20022 Business Model and message definitions · ISO 20022 catalogue — select the implementation community and message version in force · checked 2026-07-23
Payments Signal editorial teaching models — Architecture decision: canonical model · Payments Signal reference architecture v1 · checked 2026-07-23 · No standard mandates a bank’s internal data model.
Payments Signal editorial teaching models — Architecture decision: interaction style · Payments Signal reference architecture v1 · checked 2026-07-23 · Payment services have different time budgets and finality points.