ISO 20022 gives payments a language, not a memory

ISO 20022 gives payment systems shared words and structures. A pacs.008 can carry a credit transfer; a pacs.002 can report its status; defined elements can identify parties, amounts and references.4 The ISO 20022 repository supplies a data dictionary, business-process catalogue, message documentation and schemas so that participants can interpret those fields consistently.12 None of that records which internal service accepted a message, which validation ran, where a timeout occurred, who owned the next action or why an operator retried it.

That is the boundary: ISO 20022 is a language for exchanging financial information, not an operational memory. Reconstructing a payment requires a second system of evidence—stable correlation across business objects, execution traces across software components, explicit ownership of state transitions, and durable telemetry about every attempt. A valid message can exist while that evidence is missing.

A schema explains the message, not the journey

ISO 20022 is more than an XML layout. Its business model provides agreed definitions for financial concepts, and its catalogue publishes approved message definitions, reports, schemas and, where available, example instances.12 That makes a debtor, creditor, instructed amount or payment status less dependent on bilateral interpretation.

But conformity at the message boundary does not settle every implementation choice. The ISO 20022 Registration Authority says implementation depends heavily on the requirements of the adopting community and that there is no official ISO 20022 certification authority.3 The Committee on Payments and Market Infrastructures (CPMI) makes the practical consequence explicit: inconsistent deployment and data use can preserve cross-border friction even after participants adopt the common standard.4

This distinction matters during failure. Suppose a gateway validates a credit-transfer message, stores it and submits work to a clearing adapter. The adapter times out after the external system has accepted the payment. A retry arrives, one status response remains pending, and another later reports settlement completed—a sequence reflected in Fedwire guidance for possible duplicates and pending pacs.002 responses.7 Every message may be well formed. The unanswered questions are operational: Did the first adapter call complete? Was the second call suppressed? Which response belongs to which attempt? What evidence changed the local payment state?

The schema cannot answer because those facts are not properties of the financial instruction. They are properties of its execution.

One payment needs several identities

A reliable system should not ask one identifier to perform four jobs.

The business identity follows the payment across organisational boundaries. CPMI recommends a unique end-to-end transaction reference (UETR) for cross-border payments because commonly used transaction identifications are not necessarily unique across every payment and participant.4 The UETR is therefore valuable for tracking and reconciliation.

The message identity distinguishes one envelope from another. A payment instruction, status report, return or investigation message is a separate communication, even when each concerns the same payment. Their relationship must be retained; equality must not be assumed.

The attempt identity distinguishes executions. A timeout followed by a retry may produce two network calls for one message and one business intent. Reusing the business reference can help correlate them, but safe retry behaviour needs a stored idempotency decision: whether the earlier operation is unseen, in progress or completed, and whether the new request has the same intent. Public engineering guidance on payment APIs describes the core ambiguity: a call can succeed while its response is lost, leaving the caller unable to know whether a retry is safe without an idempotency contract.5

The trace and span identities describe the runtime path. W3C Trace Context defines traceparent and tracestate so tracing systems can propagate a trace across services; each operation can have its own parent or span relationship inside that trace.6 These identifiers answer “which execution path produced this log?” They do not replace a UETR, which answers “which financial transaction is this about?”

The useful record is the mapping among all four.

Correlation is a preserved relationship

Putting a UETR into a field is not the same as building correlation. The reference must survive parsing, transformation, routing, status handling, returns and investigations. Derived records must point back to the source record that caused them.

Public Fedwire guidance shows why field presence alone is insufficient. UETR is mandatory for specified value messages, but Fedwire checks its format rather than validating its uniqueness. Duplicate handling uses another identifier, the Input Message Accountability Data (IMAD); when a sender marks a message as a possible duplicate, Fedwire checks whether that IMAD has already been processed.7 One reference follows the transaction. Another supports message accountability and duplicate control.

An internal correlation model should preserve this separation. For every received or emitted message, retain its message identifier, business reference, parent message, attempt identifier and any external acknowledgement reference. When a status message changes local state, store a causal edge from that message to the transition. When a return creates a new money movement, link it to the original payment without treating it as the same operation.

Without those edges, searching by UETR produces a pile of related records. With them, it produces a sequence that can be explained.

Tracing explains execution, not financial truth

Distributed tracing fills a different gap. W3C Trace Context exists so a request can remain identifiable while it crosses software components and tracing vendors.6 In a payment path, spans can show time spent in validation, sanctions screening, routing, persistence, queueing and an external adapter. They can expose the precise branch in which latency or an error appeared.

Yet a trace is not the system of record. The W3C sampled flag is only a recommendation and does not guarantee that trace data will be recorded.6 Trace context may also be restarted at trust boundaries for privacy reasons, and W3C prohibits putting personally identifiable information into tracestate.6 A payment may outlive the retention window of the tracing backend.

The design implication is simple. Propagate trace context where policy allows it, but write the local trace ID onto the durable payment event. If a boundary creates a new trace, record the link between the old business identity and the new local trace. Operational reconstruction should still work when no sampled trace remains; the trace adds timing and call-path detail to an already coherent history.

Telemetry needs durable events and accountable owners

OpenTelemetry separates traces, metrics and logs because each signal answers a different question: traces describe a request path, metrics capture runtime measurements, and logs record events.8 Its log data model includes event and observed timestamps, trace and span IDs, severity, the originating resource and extensible attributes.9 That is a useful transport model for evidence, but teams must still decide what payment events to emit.

A reconstructable lifecycle needs an immutable event for every consequential boundary: message received, schema rejected, duplicate detected, validation passed, route selected, external submission started, acknowledgement received, status changed, manual decision made and reconciliation completed. Each event should carry the business, message, attempt and trace identities; event and observation times; the producing service; the result; the previous and next state; and a reason code. Sensitive payloads need controlled retention and access, but redaction must not remove the identifiers and hashes needed to prove which message was processed.

Ownership must be data, not folklore. A state such as pending_review should name the queue, service or operational role responsible for resolving it. A manual override should record the actor class, reason and evidence used. An alert can then identify both the broken invariant and the owner of the next move. Without that field, a timeline may show what happened while leaving nobody accountable for what happens next.

Metrics sit above this history. Rates of pending payments, duplicate detections, rejected messages and transition latency reveal systemic degradation. They should lead an operator to the affected events, not substitute for them. A counter can say that twelve transitions failed; it cannot establish which payment was retried or why one later succeeded.

The reconstruction test

The strongest reliability test is not “Can the system parse every required ISO 20022 message?” It is: given one business reference, can an operator reconstruct the payment without guessing?

The answer should show the original instruction and every related message; the identity and outcome of every attempt; the state before and after each decision; the external acknowledgements that support those decisions; the traces and logs still available; and the owner of any unresolved state. It should distinguish “message accepted” from “payment settled,” and “retry received” from “side effect executed twice.”

ISO 20022 makes that reconstruction easier because financial facts arrive in a shared vocabulary. It does not perform the reconstruction. The memory comes from preserving identity, causality, execution and ownership around the messages—especially when acknowledgements disappear, retries overlap and the last status is not yet the truth.

Sources

1. The ISO 20022 Repository — ISO 20022 Registration Authority. https://www.iso20022.org/financial-repository (opens in a new tab)
2. Catalogue of messages — ISO 20022 Registration Authority. https://www.iso20022.org/catalogue-messages (opens in a new tab)
3. Frequently asked questions — ISO 20022 Registration Authority. https://www.iso20022.org/faq (opens in a new tab)
4. Harmonised ISO 20022 data requirements for enhancing cross-border payments — Committee on Payments and Market Infrastructures, Bank for International Settlements. https://www.bis.org/cpmi/publ/d230.pdf (opens in a new tab)
5. Designing robust and predictable APIs with idempotency — Stripe Engineering. https://stripe.com/blog/idempotency (opens in a new tab)
6. Trace Context — World Wide Web Consortium. https://www.w3.org/TR/trace-context/ (opens in a new tab)
7. Fedwire Funds Service ISO 20022 Format Frequently Asked Questions — Federal Reserve Financial Services. https://www.frbservices.org/resources/financial-services/wires/faq/iso-20022/format (opens in a new tab)
8. Signals — OpenTelemetry. https://opentelemetry.io/docs/concepts/signals/ (opens in a new tab)
9. Logs Data Model — OpenTelemetry. https://opentelemetry.io/docs/specs/otel/logs/data-model/ (opens in a new tab)