Correlation IDs are cross-system evidence

What the public implementation shows

SIPS Connect contains a dedicated CorrelationService with tests and preserves payment identifiers and message records across handlers and callbacks.

Correlation context travels with technical operations while MsgId, TxId, end-to-end ID, and UETR retain their financial meanings. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleCorrelation does not replace financial identity; it connects the evidence around it.

The decision behind the mechanism

Separating trace context from business identity avoids overloading one identifier while still making distributed evidence searchable.

Without propagation, each service can show a valid local log while operators cannot reconstruct the end-to-end conversation. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Never use correlation ID as the idempotency key by default.
• Propagate it through callbacks and repository calls.
• Store it with message and transaction audit records.
• Return it in operational query results where safe.

How the control should be operated

Every boundary should accept or create correlation context, propagate it downstream, log it structurally, and retain it with durable payment records.

An investigation can join network events and financial state without guessing from timestamps. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.