PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

ISO 20022 validation, enrichment, transformation, and canonical-data architecture

Separates secure parsing, base schema, usage-guideline rules, semantic transformation, lifecycle state, and downstream status so one green check cannot falsely imply scheme compliance.

Payments Signal reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. The blueprint separates logical responsibilities so validation claims remain precise. A bank may use one product for several layers, different XML technologies, or no enterprise canonical model. The current implementation profile and its business rules remain authoritative.

Audience and purpose

Solution architects, business analysts, message engineers, test leads, and payment operations

Components

Channel or upstream producer

Creates a payment intent in an API, file, legacy message, or internal contract.

Kind

channel

Owner

Channel or source-system team

Responsibilities

Capture the complete business intent
Supply stable identifiers and profile context

Inputs

Customer instruction
Legacy message
Rail and service choice

Outputs

Inbound payment document or canonical request

Controls

Authentication
Entitlement
Input size and media-type checks

Failure modes

Unknown schema version
Incomplete party data
Duplicate request

Recovery

Reject before acceptance with a precise reason
Preserve the client reference for safe correction

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

Envelope and transport verifier

Checks the transport, Business Application Header, sender, receiver, and duplicate evidence before business processing.

Kind

gateway

Owner

Messaging platform

Responsibilities

Authenticate the transport peer
Validate envelope and header consistency

Inputs

Transport frame
Business Application Header
Business document

Outputs

Authenticated document with correlation metadata

Controls

Peer authentication
Integrity
Replay detection
Message-size limit

Failure modes

Header and document mismatch
Repeated technical identifier
Untrusted sender

Recovery

Reject at the messaging boundary
Retain non-sensitive audit evidence and correlation

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

Secure XML parser

Turns the document into a controlled data structure without resolving external content.

Kind

service

Owner

Messaging platform

Responsibilities

Establish well-formed XML
Disable unsafe external entity and network resolution

Inputs

Authenticated XML document

Outputs

Parsed document tree or technical rejection

Controls

DTD disabled
External entities disabled
Depth and size limits

Failure modes

Malformed XML
Entity expansion attempt
Resource exhaustion

Recovery

Stop before schema or business processing
Return a non-sensitive technical error

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

Base XSD validator

Checks whether the XML shape and base data types satisfy the selected message schema.

Kind

control

Owner

Messaging platform and standards team

Responsibilities

Select the intended message-definition schema
Report structural errors with safe diagnostics

Inputs

Parsed XML
Pinned base XSD set

Outputs

Base-XSD result and diagnostic locations

Controls

Approved schema checksum
No external schema retrieval
Version pinning

Failure modes

Wrong schema selected
Missing mandatory element
Invalid data type

Recovery

Reject or route to controlled repair according to the channel contract
Do not reinterpret invalid content

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

Usage-guideline and business-rule validator

Applies the implementation community’s restrictions and rules that a base XSD cannot prove.

Kind

control

Owner

Payment product and standards governance

Responsibilities

Apply profile cardinality and code restrictions
Apply cross-field and business rules

Inputs

Base-valid document
Versioned market-practice profile

Outputs

Profile result with rule identifier

Controls

Maker-checker rule deployment
Regression tests
Effective-date control

Failure modes

Base-valid but profile-invalid message
Stale profile rules
Ambiguous effective date

Recovery

Return the profile rule and safe correction path
Quarantine uncertain version selection

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

Canonical payment model and provenance

Holds the bank’s internal payment meaning and records where every material value came from.

Kind

application

Owner

Payment hub and data architecture

Responsibilities

Map external semantics without silent loss
Retain original identifiers and transformation provenance

Inputs

Profile-valid message
Enrichment facts

Outputs

Canonical payment command and transformation record

Controls

Field-level lineage
No silent truncation
Version compatibility tests

Failure modes

Meaning cannot be represented
Conflicting identifiers
Unapproved default

Recovery

Stop and expose the data-loss decision
Repair only with authorised source data

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

Payment orchestration and state

Makes business decisions using a validated, provenance-aware instruction.

Kind

application

Owner

Payments technology and operations

Responsibilities

Apply lifecycle and routing decisions
Correlate status, return, recall, and reporting messages

Inputs

Canonical payment command
Control outcomes
Network status

Outputs

Network-ready command
Durable payment state
Operational work item

Controls

Allowed state transitions
Duplicate business-reference checks
Audit

Failure modes

Out-of-order status
Unknown reference
Partial downstream outcome

Recovery

Reconcile by business and technical references
Resume only from a confirmed durable 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

Network adapter or downstream consumer

Receives a profile-correct outbound document or returns a status, exception, or report.

Kind

external-network

Owner

External payment infrastructure or internal consuming system

Responsibilities

Accept the agreed profile and transport
Return correlated technical and business outcomes

Inputs

Outbound Business Application Header and document

Outputs

Acknowledgement, status, exception, report, or settlement evidence

Controls

Counterparty trust
Sequence and duplicate checks
Cut-off and availability controls

Failure modes

Technical rejection
Business rejection
Timeout with unknown outcome

Recovery

Enquire before replay when acceptance is ambiguous
Follow the applicable exception 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

Interfaces

Inbound document

iso-producer → iso-envelope

Carry the payment intent and envelope into the controlled messaging boundary.

Contract

message · asynchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

A transport or envelope failure is rejected before the payment enters business processing.

Authenticated XML

iso-envelope → iso-parser

Pass only an authenticated, size-bounded document to the secure parser.

Contract

message · synchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

The parser is not called when header or peer checks fail.

Parsed document

iso-parser → iso-schema

Establish base schema conformance after safe parsing.

Contract

control · synchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

Malformed XML stops here and cannot be treated as a business rejection.

Base-valid document

iso-schema → iso-profile

Apply community rules only after base structure is known.

Contract

control · synchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

A profile failure remains distinct from a base-XSD failure for diagnosis and reporting.

Profile-valid semantics

iso-profile → iso-canonical

Map agreed external meaning into the internal model with provenance.

Contract

message · synchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

Unsupported meaning stops transformation; it is never silently discarded.

Canonical payment command

iso-canonical → iso-orchestrator

Start controlled lifecycle processing from a durable semantic record.

Contract

event · asynchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

Delivery is retried idempotently; ambiguous state is reconciled before replay.

Profiled outbound message

iso-orchestrator → iso-consumer

Send the selected message version and profile to its consumer.

Contract

message · asynchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

A timeout is an unknown outcome until transport and network evidence are reconciled.

Status, exception, or report

iso-consumer → iso-orchestrator

Correlate downstream outcomes without overwriting a later confirmed state.

Contract

message · asynchronous

Controls

Authentication and authorisation
Integrity and replay protection
Correlation and audit evidence

Failure treatment

Unknown or out-of-order references enter investigation instead of changing state automatically.

Authored traces

pacs.008 from intake to correlated status

Follow one customer-credit-transfer message through secure parsing, layered validation, controlled transformation, and lifecycle processing.

Intent becomes a message — Created. The upstream producer supplies the message version, profile, identifiers, and payment intent.
Peer and envelope are trusted — Transport accepted. Transport identity, header consistency, size, and replay evidence are checked.
XML is safely parsed — Well-formed. The parser establishes XML well-formedness without resolving external content.
Base schema passes — Base valid. The selected pacs.008 XSD confirms structure and base data types.
Usage guideline passes — Profile valid. The implementation profile adds restrictions and business rules beyond the base XSD.
Meaning is mapped with lineage — Normalised. Every mapped, defaulted, and unsupported value is recorded; no data disappears silently.
Lifecycle processing starts — Accepted for processing. The payment engine applies business controls and selects the downstream route.
Consumer receives the message — Submitted. The current outbound profile is sent and the response remains correlated to the original instruction.

Stress cases

Base-valid, profile-invalid

The XML passes the base XSD but violates the selected usage guideline.

Last confirmed state

Base valid; no business acceptance has occurred.

Settlement

No clearing or settlement instruction has been released.

Funds and entries

Customer funds remain in the pre-release position defined by the channel.

Next owner

Standards support or payment repair

Safe action

Return the exact profile rule and repair only from an authorised source value; never bypass the profile.

Evidence required

Message version
Profile version
Rule identifier
Original message checksum

Recovery

Correct the source data
Re-run every validation layer
Retain both failed and corrected evidence

Transformation would lose meaning

A source value has no approved canonical target or would be truncated.

Last confirmed state

Profile valid; canonical acceptance is not confirmed.

Settlement

Nothing has been submitted for settlement.

Funds and entries

No downstream financial posting should be released.

Next owner

Payment product, data architecture, and operations

Safe action

Stop the mapping, disclose the loss, and obtain an approved mapping or controlled repair decision.

Evidence required

Source field and value
Mapping version
Target constraint
Authorised decision

Recovery

Add or approve a loss-aware rule
Regression-test both directions
Reprocess idempotently

Timeout after network submission

The outbound send times out after the adapter may have handed the message to the network.

Last confirmed state

Accepted for processing; downstream acceptance is unknown.

Settlement

Unknown until network and settlement evidence are checked.

Funds and entries

Internal reservation or posting remains unchanged until the outcome is reconciled.

Next owner

Payment operations and network support

Safe action

Use technical acknowledgement, network enquiry, and business identifiers before any resend.

Evidence required

Technical message identifier
Business reference
Transport logs
Network status

Recovery

Reconcile the original submission
Replay only under the duplicate policy
Escalate if settlement evidence conflicts

Design decisions

Where should profile validation run?

Messaging boundary — Early rejection and shared rule packs, but the platform must understand each profile.
Payment engine — Business context is close, but channels may duplicate structural checks.
Layered — Technical checks run once and business rules run with context; rule ownership must be explicit.

Separate the outcomes even when one product performs several layers. A base-XSD pass is never a scheme-compliance verdict.

Should the bank use one canonical payment model?

One enterprise model — Fewer internal contracts, but the model can become over-general and slow to change.
Domain models — Rail meaning stays clearer, but transformations and lineage multiply.
Canonical core plus profile extensions — Common semantics remain stable while explicit extensions preserve rail-specific meaning.

Choose by ownership and change cadence. Whatever the model, prohibit silent truncation and record transformation provenance.

Sources and disclosed synthesis

ISO 20022 Catalogue of messages — Financial repository and message catalogue · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — CBPR+ usage guidelines · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
ISO 20022 Catalogue of messages — Business domains and message definitions · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Business application header (BAH) — Business Application Header purpose and elements · ISO 20022 Business Application Header · checked 2026-07-23
Payments Signal editorial teaching models — Secure XML parsing boundary · Payments Signal reference architecture v1 · checked 2026-07-23 · ISO 20022 defines messages, not a bank's parser product or security configuration.
ISO 20022 message XSD schemas — Message schema catalogue · ISO 20022 message schemas · checked 2026-07-23
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — Usage guideline restrictions beyond the base message definition · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
ISO 20022 Catalogue of messages — Message definitions and constraints · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Payments Signal editorial teaching models — Canonical model and provenance · Payments Signal reference architecture v1 · checked 2026-07-23 · ISO 20022 does not mandate a bank's internal canonical model. This component makes transformation risk visible.
ISO 20022 Catalogue of messages — Payment message families and business transactions · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Payments Signal editorial teaching models — Internal lifecycle orchestration · Payments Signal reference architecture v1 · checked 2026-07-23 · The state machine is an institutional design, not an ISO 20022 prescription.
ISO 20022 Catalogue of messages — Business transaction and message-set definitions · ISO 20022 financial repository and message catalogue · checked 2026-07-23
ISO 20022 Catalogue of messages — Payment initiation and clearing message sets · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Business application header (BAH) — Business Application Header · ISO 20022 Business Application Header · checked 2026-07-23
ISO 20022 message XSD schemas — Published message schemas · ISO 20022 message schemas · checked 2026-07-23
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — Profile validation is additional to base-message validation · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
ISO 20022 Catalogue of messages — Semantic message definitions · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Payments Signal editorial teaching models — Transformation boundary · Payments Signal reference architecture v1 · checked 2026-07-23 · Internal mapping rules remain institution-specific.
Payments Signal editorial teaching models — Canonical command interface · Payments Signal reference architecture v1 · checked 2026-07-23 · This is a common architecture pattern, not an ISO 20022 requirement.
ISO 20022 Catalogue of messages — Business transactions and message catalogue · ISO 20022 financial repository and message catalogue · checked 2026-07-23
ISO 20022 Catalogue of messages — Payment status, return, investigation, and reporting message sets · ISO 20022 financial repository and message catalogue · checked 2026-07-23
ISO 20022 Catalogue of messages — pacs.008 message definition · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — CBPR+ pacs.008 usage guideline · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — Usage-guideline validation · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
Payments Signal editorial teaching models — Data-loss control · Payments Signal reference architecture v1 · checked 2026-07-23 · Mapping and canonical models are institution-specific.
Payments Signal editorial teaching models — Ambiguous-send recovery · Payments Signal reference architecture v1 · checked 2026-07-23 · Exact enquiry and duplicate procedures depend on the network profile.
ISO 20022 Catalogue of messages — Message schemas · ISO 20022 financial repository and message catalogue · checked 2026-07-23
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines — Usage-guideline restrictions · CBPR+ usage guidelines — current MyStandards profile must be checked · checked 2026-07-23 · The public architecture names message families. Exact CBPR+ elements, market-practice rules, and release versions remain in MyStandards.
Payments Signal editorial teaching models — Canonical model choice · Payments Signal reference architecture v1 · checked 2026-07-23 · No ISO 20022 publication mandates one internal modelling strategy.