Equity confirms and bond confirms are not the same document with different instrument names. They carry different fields, express shared fields in different ways, and require different tolerances to produce accurate matching results. A reconciliation engine that applies the same matching logic to both will consistently produce one of two failure modes: false breaks on bond positions due to accrued interest not being normalized, or missed real breaks on equity positions due to tolerances set wide enough to absorb bond price variance. Neither is acceptable for a desk running a mixed book.
The Fields That Differ Between Equity and Bond Confirms
Quantity Expression
Equity quantity is expressed in shares. One share is one unit of the instrument. The matching comparison is straightforward: the desk's position record shows 500 shares, the counterparty's confirm shows 500 shares, and the quantity matches.
Bond quantity is expressed in face value. A US corporate bond with a $1,000 face value denomination means that a position of 500 bonds is expressed as either 500 bonds or $500,000 face value, depending on which convention the system uses. Many institutional systems express bond quantity in thousands of dollars, so the same position appears as 500 in one system and 500,000 in another when the latter is expressing in dollars not thousands.
The matching implication is that the quantity comparison for bonds cannot treat the raw number on the confirm the same way it treats the raw number on an equity confirm. The engine needs to know the denomination of the instrument and the quantity expression convention used by each counterparty to produce a valid comparison. Applying a share-count comparison logic to a bond face-value quantity produces a thousand-fold apparent discrepancy that is not a real discrepancy at all.
Price: Clean Versus Dirty
An equity price on a confirm is the price per share at which the trade was executed. There is no ambiguity about what that number represents. There is no accrued interest on an equity. The price comparison between the desk's record and the counterparty's confirm is a direct comparison of two numbers that should represent the same thing.
A bond price on a confirm may be a clean price (flat price, excluding accrued interest) or a full price (dirty price, including accrued interest from the last coupon date to settlement date). Whether the confirm carries a clean price, a dirty price, or both depends on the counterparty and the instrument type. US corporate bond confirms typically carry both. European government bond confirms may carry clean price only. Agency confirms may express differently again.
If a matching engine compares a clean price from the desk's position record against a dirty price on the counterparty's confirm, the comparison will fail by exactly the accrued interest amount. That failure is a false break. It is not a pricing discrepancy; it is a price-type normalization failure. The engine needs to normalize both prices to the same type before comparison, which requires the coupon rate, the last coupon date, the settlement date, and the day count convention for each bond position. Those fields are not on the confirm; they are in the instrument reference data.
Yield and Its Relationship to Price
Bond confirms frequently carry a yield alongside the price. The yield and the price should be mathematically consistent given the coupon rate, maturity date, and day count convention. When they are not consistent on a counterparty's confirm, it usually means one of the two was derived incorrectly by the counterparty's system, typically because of a difference in the day count convention applied.
The matching engine should not simply ignore the yield field on a bond confirm. A yield-price inconsistency on an incoming confirm is a signal that something is wrong with the confirm itself, independent of whether the price matches the desk's record. A confirm where the yield and price are internally inconsistent should be flagged for review even if the price matches, because the counterparty's records may reflect a different trade from the one the desk believes it executed.
Tolerance Design: Why the Same Tolerance Does Not Work for Both
Price tolerance in a matching engine defines how large a price discrepancy is acceptable before a match attempt fails and a break is raised. For equities, a typical tolerance is expressed in absolute price terms per share: within $0.01 per share, for example, to absorb rounding differences.
For bonds, expressing tolerance in absolute price terms is problematic because bond prices are quoted as a percentage of face value, and the economic significance of a given percentage difference depends on the face value of the position. A 0.02 point difference on a $100,000 face value corporate bond position is $20. The same 0.02 point difference on a $10 million face value position is $2,000. An absolute tolerance of 0.02 points treats these identically, which is not appropriate risk management.
The correct approach for bond matching is to express tolerance either as a percentage of the notional value or as an absolute dollar amount that reflects the desk's acceptable threshold per the risk profile of the position. A per-basis-point threshold is common in institutional operations: a discrepancy of less than one basis point on price (0.01% of par) is within tolerance; a discrepancy of more than two basis points is a break that requires investigation.
For equities, the equivalent expression is typically in cents per share or as a percentage of the trade price. A one-cent difference on a $40 stock is 2.5 basis points of the trade price. The same one-cent difference on a $200 stock is half a basis point. Whether the tolerance should be expressed in absolute cents or relative to the trade price depends on how the desk's risk management framework handles small price discrepancies.
Settlement Date Matching: Calendar Differences by Instrument
Settlement date matching is straightforward when the instrument type and settlement cycle are consistent. US equities settle T+1 since the 2024 rule change. The settlement date comparison is a direct date comparison against the equity's T+1 calendar date.
Corporate bonds generally settle T+2 under standard convention, though same-day settlement is possible for some transactions. Government bonds may settle T+1. Municipal bonds have historically settled T+2, but dealer-specific conventions can vary. When a desk's position record carries a settlement date that reflects one convention and the counterparty's confirm carries a date that reflects a different convention, the settlement date comparison will fail even if both parties are following their respective standard practices.
The correct matching logic for settlement dates is not simply to compare the two dates and flag any difference. It is to compare the date against the standard settlement cycle for that instrument type, flag differences that exceed one business day as genuine discrepancies, and route one-business-day differences to a calendar-check review rather than a break escalation. This requires the matching engine to know the standard settlement cycle for each instrument class, which again requires instrument reference data as an input.
Practical Matching Architecture for Mixed Books
A matching engine for a desk running both equities and fixed income should not apply a single set of rules to all positions. The instrument class determines which fields are relevant, how those fields should be normalized, what tolerances apply, and how discrepancies should be classified.
The simplest viable architecture is to route each confirm to an instrument-class-specific matching module at ingest time, based on the ISIN or CUSIP resolving to an equity or fixed income instrument in the reference data. The equity module applies share-count quantity comparison, direct clean price comparison with per-cent tolerances, and T+1 settlement date validation. The fixed income module applies face-value quantity normalization, clean price derivation from full price or direct clean price comparison depending on what the confirm carries, basis-point price tolerances scaled to notional value, and instrument-specific settlement cycle validation.
We are not saying that implementing this correctly is trivial. Instrument reference data integration is a non-trivial engineering task, and maintaining accurate reference data for a mixed book with OTC and exchange-traded positions requires ongoing data management. But the alternative, applying a single tolerance-based comparison to all confirms and managing the resulting false break volume manually, has a higher operational cost over time. The false break rate on bond positions in a single-logic matching engine is not an occasional inconvenience; it is a daily manual overhead that does not go away unless the normalization problem is addressed at the matching layer.
