Trade Matching

Trade matching is the step at which the post-trade workflow either validates that a transaction is ready to proceed toward settlement, or surfaces the specific discrepancy that prevents it. After execution, buyer and seller each hold their own record of the trade. Those records were created independently — by different systems, at different times, sometimes from different data feeds — and they do not always agree. Trade matching is the mechanism that performs a structured comparison before settlement infrastructure is asked to act on instructions derived from those records.

The process is bilateral by design. Both sides independently submit their trade details to a matching utility without coordination. The utility compares the submitted records field by field against a defined match criteria set. If all core fields match within configured tolerances, the utility returns a matched status and the trade proceeds to the confirmation and affirmation workflow. If any core field differs — quantity, price, settlement date, place of settlement, counterparty identifier, or settlement method — the utility returns an unmatched status with the specific fields that produced the break. That unmatched status is the origin of a trade break; the trade cannot proceed to confirmation until the break is resolved.

Central Matching vs. Bilateral Matching

Trade matching operates through two structural models, each with different operational characteristics and regulatory implications.

In central matching, both counterparties submit their records to a shared utility that performs the comparison and reports the match or mismatch result to both parties simultaneously. DTCC's Central Trade Manager (CTM) operates on this model for US institutional equity: the buy-side and sell-side each submit independently, and CTM reports the field-level comparison result to both. Central matching eliminates the coordination problem of bilateral message exchange — neither side needs to initiate contact with the other to discover a break. The break status is reported automatically, with the mismatched field identified. This is the model that makes automated break detection at scale possible under T+1.

In bilateral matching, counterparties exchange confirmation messages directly and compare them against their own records. SWIFT message exchange — MT 515 for securities confirmation, being replaced by ISO 20022 sese.027 for matching status — operates bilaterally. Bilateral matching is more common in cross-border and OTC transactions where no central utility covers the counterparty pair or asset class. The operational downside is that bilateral breaks may not surface until one side notices a discrepancy in an incoming message, rather than receiving an automated break alert from a central utility.

The Match Algorithm: What Constitutes Agreement

A matched trade is one where both submissions agree on every core field within the utility's defined criteria. The core match fields for equities are instrument (ISIN or CUSIP), direction, quantity, price, settlement date, and settlement method. The settlement date match is particularly consequential: if one side has applied a different market convention — T+1 vs T+2, or a different holiday calendar for a cross-border instrument — the settlement date will differ, producing a break that requires counterparty agreement on the correct convention before the settlement instruction can specify a date.

Near-match tolerances allow some utilities to flag a potential match where price differences fall within a defined rounding range, prompting both sides to confirm agreement. These tolerance windows are configured conservatively — a price difference of more than a fractional basis point on a fixed income instrument, for example, is typically treated as a full mismatch rather than a rounding artifact. Quantity mismatches are almost never subject to tolerance: a difference in the number of shares matched implies one side recorded a partial fill differently and requires investigation, not tolerance.

The Matching-to-Break Connection

The relationship between trade matching and trade breaks is not incidental — it is structural. Every trade break that originates from a record discrepancy between counterparties begins as a matching failure. The matching utility is the detection mechanism; the trade break management workflow is the resolution mechanism. A trade that matches on all fields has no break to resolve. A trade that mismatches on settlement date produces a settlement date break. A trade that mismatches on quantity produces a quantity break. The field-level mismatch data returned by the matching utility is the first and most reliable signal for diagnosing break root cause — it identifies precisely where the records diverge, which determines what investigation and resolution action is required.

A DK (don't know) is the response issued by a counterparty that has no record of the trade at all — distinct from the matching utility returning an unmatched status on a field comparison. A DK cannot be resolved through field-level comparison because there is no submitted record on one side to compare. It requires out-of-band investigation — typically a review of execution logs and direct counterparty contact — to establish whether the trade was executed, routed incorrectly, or never captured. Under T+1, a DK received on trade date is an immediate priority escalation; there is no second day in which to establish a basic record of the transaction.

The accounting consequence of an unmatched trade extends beyond the exception queue. Because a settlement instruction cannot be generated until the break resolves, the accounting book of record (ABOR) cannot update position. The position remains in the investment book of record (IBOR) only — a reflection of an intended trade, not a completed one — until matching succeeds and the instruction proceeds through settlement. This IBOR-only state is the post-trade accounting manifestation of matching failure.