Two Settlement Paths, Two Different Ops Workflows
A single trading desk often runs both DTCC-eligible and bilateral OTC transactions simultaneously. The reconciliation logic, the break triggers, and the escalation paths are structurally different for each, and using the same workflow for both is one of the more reliable ways to create invisible settlement risk. Understanding how each path works operationally is the foundation for building a reconciliation process that handles both without confusion.
How DTCC Settlement Works for the Ops Desk
DTCC's National Securities Clearing Corporation (NSCC) acts as a central counterparty for most exchange-listed equity transactions and some fixed income instruments. When a trade is executed on a registered exchange or an ATS and submitted to NSCC, DTCC substitutes itself as the counterparty to both sides of the trade through a process called novation. The original buyer and seller no longer face each other. They each face DTCC.
Because DTCC novates the trade, the standard confirm and affirmation cycle looks different from bilateral. DTC-eligible trades are submitted by the executing broker to NSCC for matching and comparison. The counterparty's clearing broker receives the compared trade and has a window to affirm. Under T+1 settlement, affirmation must occur by 9pm on trade date for the trade to settle on schedule. DTC then handles the physical movement of securities and cash through its book-entry system.
The netting benefit is the most operationally significant feature for a desk running volume. DTCC nets all of a member's DTC-eligible positions at end of day. A desk that buys 10,000 shares of a security and sells 8,000 shares of the same security on the same day settles a net 2,000-share buy, not two gross transactions. For a high-volume desk, net settlement reduces the number of delivery and receipt instructions by a factor that can meaningfully cut settlement costs and fail risk.
From a reconciliation standpoint, the break triggers on DTC-eligible trades are relatively structured. If a trade appears in your internal records but not in NSCC's compared trade list, the comparison failed and needs to be investigated. If the counterparty's clearing broker did not affirm by the end-of-day window, the trade is not going to settle on schedule. DTC sends the break notification through standardized messages, which means the data is machine-readable and the alert timing is predictable. The ops workflow for DTC fails is well-defined: check NSCC status, check affirmation status, check DTC account position and fails queue.
How Bilateral OTC Settlement Works for the Ops Desk
OTC transactions, including bilateral fixed income, FX, and most OTC derivatives, do not go through DTCC. There is no central counterparty and no automatic netting. Each transaction is confirmed directly between the two parties, typically by email, SWIFT messaging, or through a bilateral confirmation matching platform, and each transaction settles gross between the two parties' custodian accounts.
For fixed income OTC, the confirm typically arrives by email or SWIFT MT54x message and contains more fields than an equity confirm: clean price, accrued interest, yield, face value, day-count convention, and sometimes a repo rate or spread for repo transactions. The confirm matching process has to reconcile all of these fields, not just price and quantity. Each field is a potential mismatch point, and fixed income mismatches are harder to diagnose quickly because the relationships between price, yield, and accrued interest depend on the exact day count the counterparty used.
Settlement for bilateral OTC typically occurs through custodian banks or international central securities depositories like Euroclear or Clearstream for cross-border trades. The settlement instruction has to be sent to the custodian separately from the trade confirm. If the confirm matches but the settlement instruction was never sent or was sent to the wrong account, the trade will fail at settlement even though the confirm reconciliation showed no break. This is an additional failure mode that does not exist in DTC-eligible settlement, where DTC generates the settlement instruction automatically once the trade is compared and affirmed.
There is also no netting in bilateral OTC settlement. A desk that trades 20 round-trip OTC corporates with the same counterparty on the same day settles 20 gross transactions, each with its own settlement instruction and each with its own fail risk. The aggregate exposure to a single counterparty can be substantial even for a desk that considers itself running modest OTC volume.
Different Break Triggers, Different Escalation Paths
The breaks that indicate a settlement risk are different for each path, and the response time requirement is different.
For DTCC-eligible trades, the critical breaks are: trade not in NSCC's compared queue by end of trade date (possible OMS submission failure), counterparty did not affirm in the affirmation window (counterparty-side issue requiring a phone call or SWIFT message), and DTC position deficit on settlement date (a long fail, often visible in the DTC participant fails report hours before the settlement window closes). The escalation path runs through the clearing broker or directly through DTC's participant portal, and the break messages are standard enough that many desks can monitor them with automated alerts.
For bilateral OTC, the break triggers are less standardized. A confirm that has not been received by mid-morning on T+1 for a T+2 settling trade is a warning sign that needs to be chased before the confirm window closes. A confirm that arrived but whose fields do not reconcile to your trade record is a dispute that needs direct counterparty contact before the settlement instruction can go out. A settlement instruction that was sent but whose custodian has not acknowledged by end of T+1 is a custody-side issue that requires a different escalation path than the counterparty break.
A single spreadsheet that mixes DTC-eligible and bilateral OTC positions cannot handle the different break types and escalation paths cleanly. The DTC break status comes from NSCC messages. The bilateral OTC break status comes from your incoming confirm log and your custodian's SWIFT messages. The data sources are different, the timing windows are different, and the resolution steps are different. Mixing them into a single break management column on a spreadsheet creates exactly the kind of false positive and missed break pattern that turns into a 4pm call.
What This Means for Reconciliation System Design
A reconciliation layer that handles both settlement paths needs to classify each trade by settlement path at ingest and route it to the appropriate matching and break detection logic. DTC-eligible trades get compared against NSCC's matched trade report. Bilateral OTC trades get matched against incoming confirms using field-level tolerance matching that accounts for accrued interest and day count differences.
We are not saying bilateral OTC is harder to manage than DTC-eligible, or that a desk should prefer one over the other for operational reasons. Both serve legitimate business purposes and both can settle cleanly when the confirmation and instruction workflow is correct. The point is that treating both settlement paths as interchangeable produces systematic gaps in break detection, and those gaps persist even when the desk is experienced and attentive, because the gaps are structural rather than procedural.
The desks that handle both settlement paths well tend to have explicit routing logic: this instrument class goes to this confirmation and break workflow, that instrument class goes to the other. The routing logic does not need to be sophisticated. It needs to exist and be applied consistently before the break management work begins.
