A Failed Trade Needs More Than a Status

What a status cannot tell you

Settlement systems can report different states and produce different evidence objects. Status advice and settlement confirmation, cancellation and reversal are not interchangeable. Source-native reason codes can also point to very different operational conditions.

The useful habit is simple: do not flatten them into one generic lifecycle. Keep the source-native state, reason, reference and timestamp from the relevant market or account-servicer workflow.

For example, the current online ISO 15022 User Handbook distinguishes PEND and PENF as different source-native concepts. It also lists distinct reason codes for conditions involving securities availability, money, holds, linked instructions, investigation and partial processing.

Treat those codes as reported evidence, not conclusions. They can tell you what the source said; they do not, on their own, establish root cause, blame or liability.

The failed-trade evidence chain

Start with two questions: what should have happened, and what does the source say was observed?

At minimum, a reviewer should be able to answer:

• Which source-native instruction or trade references identify the event?
• When was it meant to settle?
• What quantity and, for an against-payment trade, what amount and currency were expected?
• What source-native status and reason did the source report, and when?
• Did an effective settlement event occur later?
• If settlement was partial, what settled and what remained?
• Which evidence source supports each answer?

If settlement later succeeds, do not overwrite the earlier failing observation. If the intended settlement time and the effective settlement time are both available, keep both. The gap between them is part of the operational history.

The same goes for partial settlement. Source documentation can represent settled and remaining quantities or amounts. A partial confirmation can be useful evidence without implying that the whole exception is resolved.

A reason code is evidence, not blame

Keep the source-native reason code beside its original source and context.

A team may map native reasons into simpler internal categories such as SECURITIES_AVAILABILITY, CASH_OR_LIQUIDITY, TIMING_OR_CUTOFF, HOLD_OR_RELEASE, LINKAGE_OR_DEPENDENCY, or INVESTIGATION_OR_UNKNOWN.

That mapping is reviewer normalization, not a market standard. Keep the native code and narrative visible beside it.

Why this matters: a reported condition such as insufficient securities can help explain the observed settlement state. It does not establish why the shortage occurred, whether a control failed, or who is liable.

Cash break and position break are separate evidence questions

A failed settlement can leave two separate questions on the desk: what happened to the cash leg, and what happened to the security or position leg.

For cash, relevant evidence may include the expected settlement amount and currency, a source-reported settled or remaining amount, value-date information, and a cash-account report, statement or debit/credit notification reference when available.

For the security leg, the reviewer may need the expected quantity, the effectively settled quantity, the remaining quantity, and a holdings statement or transaction statement with its as-of or period context.

These are operational evidence questions. They do not decide journal treatment, valuation or NAV.

That is why a useful reviewer note is not NAV impact = X. It is closer to professional review required — position evidence unresolved or valuation/NAV question remains for the responsible specialist.

External action is part of the record

The status is only part of the story. What happened next belongs in the record too.

Depending on the source and market, that history may include an enquiry or investigation status, a hold or release, a partial settlement, a cancellation request, a cancellation of a prior confirmation, a reversal, a modification, or a new instruction linked to a prior instruction.

When available, keep the source-native action, timestamp and reference. That is more useful than forcing every event into one normalized label.

An action record shows that the source reported an action or status. It does not, by itself, show that the action was timely, effective, compliant or legally determinative.

One leg cleared does not automatically close the exception

A common shortcut is to see one successful event and call the whole exception finished.

If the security leg is evidenced as complete but cash evidence is still unresolved, the record still has an open cash question. If cash is evidenced but the remaining security quantity is not, the position question remains open.

Partial settlement, cancellation and reversal need the same care. They are events in the history, not reasons to erase what came before.

If later evidence changes a prior closure, keep the close event and record why and when the record was reopened, along with the evidence that triggered it.

The Failed-Trade Exception Record

For this reviewer artifact, a simple state model can help: OPEN → READY_FOR_REVIEW → CLOSED, with REOPENED as an explicit post-close state.

That state model is Treasury Desk author synthesis, not a universal settlement standard.

For this artifact, CLOSED means the bounded operational record is complete for the review job. The outcome is evidenced; the material cash and security questions are reconciled or explicitly handed off; relevant actions are linked; professional-review questions are cleared or transferred to the responsible function; and the closure owner, time, reason and evidence references are recorded.

That is intentionally narrower than legal finality, accounting correctness, audit clearance or compliance closure.

Wholly synthetic example — every value below is synthetic

What this does not prove

A reviewer-facing exception record does not establish:

• one universal lifecycle or taxonomy for failed trades;
• ultimate root cause, negligence, blame or legal liability;
• legal finality from a technical settlement timestamp or status;
• the correct accounting entry, valuation treatment, cutoff decision or NAV impact;
• audit assurance, compliance closure or control effectiveness;
• that one settled leg resolves the other leg or the whole exception;
• that a cancellation or reversal erases the original event history;
• that the proposed record or closure test is an industry requirement;
• that Treasury Desk executes, repairs, cancels, reverses, settles or moves assets or cash.