Most settlement fails that show up on the end-of-day report look similar at first glance: a field mismatch between the desk's records and the counterparty's confirm. But the cause of that mismatch, and the correct response, depends on which pattern is underneath it. A recurring price tolerance slip is not the same problem as a one-off ISIN mismatch, even though both appear as a failed match on the morning break report. Four patterns account for the large majority of fails that ops desks encounter regularly, and each one has a characteristic signal that distinguishes it from the others before the 4pm settlement cutoff.
Pattern One: Recurring Price Tolerance Drift
This pattern presents as a price field that mismatches by a small, consistent amount on the same instrument or with the same counterparty over multiple settlement cycles. The desk's records show one price; the counterparty's confirm shows a price that is off by two or three basis points every time.
The signal that distinguishes this from a one-off discrepancy is repetition. When the same mismatch amount appears on the same counterparty ID for three or more consecutive settlements, the cause is almost never a genuine trade dispute. The cause is a difference in rounding convention between the two systems, a difference in yield calculation methodology (30/360 versus actual/360 day count), or a difference in how one side applies the price from the execution record to the confirm field.
The correct response is a tolerance adjustment, not a match reject and escalation. Escalating a $0.02 price delta per $1,000 face value to a counterparty relationship manager every time it appears is not productive. The desk should configure a bilateral tolerance for that counterparty and document the delta source. What it should not do is quietly set a wide global tolerance to absorb this one situation, because a wide global tolerance will mask the next pattern.
Pattern Two: ISIN Versus CUSIP Identifier Confusion
This pattern presents as a match failure where everything looks correct on both sides of the trade but the instrument identifier does not resolve. The desk's system carries the position under a CUSIP. The counterparty's confirm carries the ISIN. The matching engine does not find a corresponding open position because it is comparing CUSIP characters to ISIN characters without conversion.
The signal here is that the discrepancy is on the identifier field only. Price, quantity, and settlement date match when you look at them manually. A desk analyst who opens the confirm and the position record side by side sees immediately that these are the same trade. The system does not see it because the identifier namespace was not normalized before comparison.
This situation is common when a desk that primarily trades US equities starts adding OTC international positions or structured products. US domestic equity positions are widely identified by CUSIP in internal systems. When those systems are asked to reconcile against a confirm from a European counterparty that uses ISIN, the translation step is often missing. The fix is identifier normalization at the ingest point: convert CUSIP to ISIN before the match attempt, or maintain a dual-identifier cross-reference for positions. Doing neither and relying on manual resolution for every cross-identifier fail is a volume problem waiting to surface.
Pattern Three: Settlement Date Calendar Mismatch
This pattern presents as a settlement date on the counterparty's confirm that is one business day off from the desk's record. Both sides of the trade agreed on the settlement terms at execution time. The discrepancy entered the system during the confirm generation step, when one side's system applied a different settlement holiday calendar.
The signal that distinguishes this from a genuine settlement instruction error is the one-day gap and the cross-market nature of the position. A US equity traded through a domestic broker-dealer and settling at DTC has a well-defined settlement calendar. There is no ambiguity about which day T+1 falls on. When the settlement date discrepancy appears on a cross-border or cross-currency OTC position, the calendar mismatch is the likely cause.
Desks that clear cross-border positions frequently see this pattern around Federal Reserve bank holidays that are not observed in London or Tokyo, and around local market holidays in foreign jurisdictions that are not reflected in the desk's internal calendar. The correct response is to identify the positions where this mismatch appears systematically and update the holiday calendar for the affected instruments. Escalating it to the counterparty as a fail every time it appears is not the right resolution; the underlying calendar difference does not go away on its own.
Pattern Four: Quantity Expression Inconsistency in Fixed Income
This pattern is specific to fixed income positions and presents as a quantity mismatch where the numbers appear to be off by a factor of 1,000. One side has recorded the position as 1,000 units. The other side shows 1,000,000. The reason is that fixed income quantity can be expressed in bonds (one bond equals $1,000 face value for most US corporate issues) or in dollars of face value, and the two systems involved did not normalize to the same expression.
The signal is the factor-of-1,000 relationship between the two quantities. If the price fields match and only the quantity is off by exactly that ratio, it is almost certainly a units-versus-face-value discrepancy rather than a genuine quantity error. A genuine over-delivery or short delivery would show up as a partial quantity mismatch, not a clean thousandfold ratio.
This pattern surfaces most often when a desk that runs a primarily equity book starts adding corporate bond or government bond positions. The quantity conventions are different by instrument class, and a system built for equity operations often carries forward the share-count quantity model without adjustment when fixed income positions are added. A matching engine that does not know the instrument class of the position being matched will misread this discrepancy as a serious error every time.
Reading the Break Report Before the Cutoff
The four patterns above are not exhaustive. But they account for a high proportion of the confirms that queue as breaks on any given morning, and they each have a resolution path that is faster than a full counterparty dispute process.
The practical issue on a desk is time. The morning break report arrives between 8 and 9am. The settlement cutoff is at 4pm. If the desk is processing all breaks as equivalent, a calendar mismatch gets the same attention and response effort as a genuine quantity dispute. The calendar mismatch should take three minutes to resolve. The genuine dispute may take two hours.
Triage by pattern type is not just an efficiency consideration; it is a risk-management one. When the 4pm cutoff approaches and the desk still has a backlog, the items that should remain open for counterparty escalation are the genuine disputes. The recurring tolerance drifts, the identifier mismatches, and the calendar discrepancies should be resolved long before the deadline so that attention is concentrated on the breaks that actually require human judgment.
What Catena surfaces in the break report is not just the list of mismatched confirms. It tags each break with a pattern classification based on the characteristics above, so the desk can triage by category rather than by position size or alphabetical order. A tolerance drift on a $10M bond notional should not queue behind an identifier mismatch on a $100M equity position just because the equity was alphabetically earlier in the list.
The classification is not right every time. A recurring discrepancy that has the signature of a tolerance drift may occasionally be a genuine error that the counterparty has been passing along in the same amount. The analyst has to exercise judgment. What the classification does is reduce the number of items that require fresh analytical attention on every morning report, which is where the time savings actually come from.
