OTC fixed income confirms and exchange-traded confirms are not the same document in different fonts. They carry different fields, express the same fields in different units, and settle through different counterparty structures. A reconciliation engine that treats them identically will produce false breaks on one side or miss real ones on the other. Most ops desks using a single spreadsheet-based workflow discover this the hard way when they add OTC positions to a book that was previously all exchange-traded.
The Structural Difference in Confirm Fields
An exchange-traded equity confirm, routed through DTC, carries a clean structure: CUSIP, quantity in shares, price per share, trade date, settlement date, and a net settlement amount. The fields are consistent across all DTC-eligible positions because the CSD standardizes the confirmation format. There is no ambiguity about which day count convention applies or how accrued interest is calculated, because there is no accrued interest on an equity position.
An OTC fixed income confirm is bilaterally generated by the counterparty. The fields it carries depend on the instrument: corporate bonds include accrued interest calculated on a 30/360 or actual/360 day count depending on the bond indenture; government bonds often use actual/actual; agency securities carry their own conventions. The same counterparty may send confirms for two bond positions using different day count conventions in the same email batch, because those are the correct conventions for those specific instruments.
The accrued interest field is the primary source of false breaks in OTC fixed income reconciliation. When a desk's position record carries a clean price and the counterparty's confirm shows a full price (which includes accrued interest), the price comparison fails, even though both sides are recording the same trade correctly. Normalizing to clean price before comparison is the right approach, but it requires knowing the day count convention and the coupon accrual period for each instrument, which means instrument reference data has to be part of the reconciliation engine, not just the position record.
Netting: Exchange-Traded Versus Bilateral
DTC-eligible positions net at the CSD level before settlement instructions are generated. If a desk bought 10,000 shares of a particular equity through one broker and sold 7,000 through another, DTC can net those to a 3,000-share delivery instruction in certain conditions. The net position is what the desk reconciles against, not the two gross trades.
OTC bilateral positions do not net at a central counterparty in the same way. Each trade settles individually between the two counterparties. A desk running a repo book with five active counterparties has five bilateral settlement instructions per position, not one netted instruction. Reconciling an OTC repo book means matching each bilateral confirm and each bilateral settlement confirmation separately.
The volume implication matters. A desk clearing 200 exchange-traded positions per day through DTC might generate 50 net settlement instructions after DTC netting. The same desk running 200 bilateral OTC trades generates 200 individual settlement events. The reconciliation workload is not proportional to trade count; it is proportional to the clearing structure of those trades. Adding OTC positions to an exchange-traded book without accounting for this can triple reconciliation volume with no change in nominal trade count.
Settlement Cycle Differences and the Timing Problem
US equities now settle T+1 following the SEC's 2024 rule change. Most US corporate bonds still settle T+2. Government bonds, depending on the transaction type, can settle T+1. Repo transactions often settle same-day or T+1 depending on the term. A desk running a mixed book with exchange-traded equities, corporate bonds, and short-term repo is managing three different settlement cycles simultaneously.
The bottleneck this creates is not just about knowing the settlement date for each position. It is about when the confirm arrives relative to settlement. Exchange-traded confirms arrive the same day through DTC's automated systems. Bilateral OTC confirms may arrive by email the same day or may not arrive until the following morning, depending on the counterparty's operations staff and their system setup.
A repo position that settles same-day and whose confirm arrives by email at 11am gives the ops desk approximately five hours to reconcile and issue a settlement instruction. If the confirm contains a discrepancy that requires counterparty communication, the effective window is much shorter. This is the scenario that most frequently produces settlement fails on OTC repo books, and it is not resolvable by working faster on the same manual process. The time constraint requires either that the confirm arrives earlier or that the reconciliation step is automated enough to run as soon as the confirm lands.
Why One Recon Workflow Cannot Handle Both Without Customization
The field structure is different. The netting approach is different. The settlement cycle is different. A single tolerance-based matching engine that applies identical rules to exchange-traded and OTC confirms will encounter three categories of problems.
First, it will produce false breaks on OTC fixed income positions because the price comparison is running against clean-versus-dirty price without normalization. These are not real breaks; the trade is fine. But they queue as breaks and consume analyst time.
Second, it will miss real breaks on exchange-traded positions that have settled by netting, because the engine is trying to match individual trade confirms against netted DTC settlement records and cannot find a one-to-one correspondence. The correct approach is to match the gross trades against DTC trade records before netting, and then validate the netted settlement separately.
Third, it will misclassify settlement date discrepancies on cross-market positions where T+1 equities and T+2 bonds are in the same matching batch. A one-day difference that is a calendar error on an equity position is a correct and expected settlement cycle difference on a corporate bond in the same book.
These are not edge cases. They describe the normal state of a mixed-book ops desk. We are not saying that running a unified reconciliation platform is wrong; we are saying that a unified platform needs instrument-class-specific matching rules to produce accurate results. A configuration that ignores the OTC versus exchange-traded distinction will create more manual break resolution work than the tool saves.
What Changes in the Reconciliation Workflow
Separating OTC from exchange-traded in the matching engine does not necessarily mean running two entirely separate reconciliation workflows. The core logic, compare confirm fields to position records and flag discrepancies, is the same. What changes is the set of rules applied during field comparison.
For exchange-traded: match on CUSIP, quantity in shares, clean price, and DTC settlement date. Apply the DTC holiday calendar. Check against net settlement instructions, not gross.
For OTC fixed income: match on ISIN, quantity in face value, clean price derived from dirty price using instrument-specific day count convention, and bilateral settlement date using the relevant clearing calendar for the instrument and counterparty jurisdiction. Check against individual bilateral settlement instructions, not netted.
For OTC repo: match on collateral ISIN, face value, haircut rate, all-in rate, start date, and maturity date. Settlement is typically same-day or T+1; the matching window is shorter and the alert trigger needs to fire earlier in the day to leave time for counterparty resolution.
The practical question for an ops desk evaluating a reconciliation tool is not whether the tool handles OTC and exchange-traded. It is whether the tool applies the right matching rules to each instrument class automatically, or whether that differentiation requires manual configuration per counterparty per instrument. At a desk processing mixed-book positions daily, an instrument-class-aware matching engine is not a nice-to-have; it is the difference between producing actionable break reports and producing a list of items that all require manual investigation before they can be classified.
