Don't Know (DK) Notice
A DK is a counterparty's declaration that it cannot recognize or confirm an alleged trade — a data discrepancy that, unresolved before the affirmation deadline, significantly raises settlement fail risk.
Definition
A DK indicates that the receiving party cannot recognize or confirm a trade in its records. In post-trade operations, a DK arriving on trade date is not a minor data exception — it is a blockage in the settlement pipeline that must be cleared within hours. Under T+1 settlement, the combination of a compressed affirmation window and the counterparty dependency of the resolution process makes the DK one of the highest-priority exceptions an operations team manages.
The Alleged Trade Phase
When an executing broker submits a trade to a post-trade matching platform such as DTCC CTM, it appears in the investment manager's queue as an alleged trade — the broker is asserting that a transaction occurred under specific terms, and the IM has not yet confirmed or rejected those terms. The IM's operations team, their custodian, or an automated middleware system — platforms such as State Street Alpha, BlackRock Aladdin, or Charles River that auto-compare alleged trades against OMS records — must act on the alleged trade before the affirmation deadline.
An unresponded alleged trade carries a distinct liability risk. If the broker assumes that silence implies acceptance and the IM does not deliver the securities on settlement date, the broker faces a fail without a clear audit trail for the source of the discrepancy. A DK, by contrast, provides a reason code and a documented rejection that both parties can investigate. An alleged trade that expires unresponded is operationally harder to resolve than one that generates a DK, because the IM has not named the specific discrepancy.
Some DKs in automated environments arise from automation failures rather than genuine economic disagreements. If the middleware platform mismatches the alleged trade against the wrong order — due to a fund ID discrepancy, a CUSIP lookup failure, or a system timing issue — the auto-affirm fails and the trade surfaces as a DK even though the underlying economics may be correct. Operations teams must distinguish between a genuine data error and a platform-triggered DK before contacting the counterparty.
DK Reason Codes and Common Causes
The three most operationally significant DK causes are price mismatch, quantity mismatch, and wrong security.
A price mismatch is the most common DK. It arises when the execution price on the broker's submission differs from the price in the IM's OMS — often because the OMS booked a slightly different fill price than the actual execution price reported by the broker. Resolving it requires both sides to agree on the correct price, which means active counterparty contact.
A quantity mismatch typically flows from an allocation error or a step-out mismatch. In a step-out transaction — where the executing broker steps out the trade to the prime broker — the prime broker must present the trade to the IM's custodian under the correct fund identifier. If the prime broker's system does not recognize the fund ID, or if the step-out instruction references the wrong prime broker account, the custodian may DK the trade even though the underlying economics are correct.
A wrong security DK — where the CUSIP or ISIN submitted does not match the IM's instrument — is the most operationally dangerous. A single transposed character can produce a valid CUSIP that passes a check digit test but identifies an entirely different security. In this case, the trade record, the allocation, and any ABOR update that has already been applied are all wrong. Correcting the DK requires fixing the identifier at the source in the instrument master before any resubmission.
An account mismatch DK arises when the fund or account identifier on the submission is not recognized by the IM's custodian — common in prime brokerage step-out structures where fund identifiers must be pre-registered with the custodian. The broker cannot resolve this unilaterally; it requires confirmation from the IM's ops team of the correct account mapping.
DK reason codes — cause, resolution, and T+1 risk
| DK Reason | Root Cause | Resolution | T+1 Risk Level |
|---|---|---|---|
| Price mismatch | Execution price differs between broker OMS and IM records | Both parties agree correct price; broker amends and resubmits | High — most common; requires active counterparty contact |
| Quantity mismatch | Share count differs; often from partial-fill allocation or step-out error | Reconcile against original order and allocation; amend quantity | High |
| Wrong security (CUSIP) | Incorrect CUSIP or ISIN; may pass check digit but identify wrong instrument | Correct identifier at source; check instrument master; resubmit | High — may also corrupt enrichment and ABOR downstream |
| Settlement date | Broker submits T+1; IM expects different convention or ex-clearing | Agree settlement convention; resubmit with correct date | High |
| Account mismatch | Fund or account identifier on submission not recognized by IM custodian | Verify fund ID mapping; update SSI; contact IM ops | High — cannot self-resolve without IM custodian confirmation |
| Counterparty unknown | IM has no record of the stated executing broker for this trade | Verify executing broker identity and account; contact ops desk | High — requires bilateral communication to resolve |
| Duplicate submission | Same trade submitted twice by the same party | Cancel duplicate; confirm original is correctly matched | Low — typically self-resolving |
The Affirmation Window
In a T+2 settlement environment, a DK received at market close could be resolved the following morning. Under T+1, the DTCC same-day affirmation target of 9:00 PM ET on trade date applies. For a broker-dealer whose trading day ends at 4:00–4:30 PM, a DK received at market close leaves often fewer than five hours to investigate the discrepancy, establish contact with the IM's operations desk, agree on correct economics, amend the submission, resubmit, and receive affirmation. In practice, that window is frequently shorter: IM operations desks may close earlier, custodians batch-review alleged trades at set times, and each step in the resolution chain requires a responsive counterparty. If the IM's team is unavailable, the DK cannot be resolved regardless of how quickly the broker identifies the root cause.
Operations teams track DK aging in time buckets — 0–1 hour, 1–3 hours, 3–6 hours, and over 6 hours since issuance — to prioritize resolution effort against the remaining affirmation window. A DK in the over-6-hour bucket with fewer than three hours to the 9:00 PM ET target is in critical status; escalation to a supervisor and direct desk-to-desk contact with the IM are typically required. The DK rate — DK'd trades as a percentage of total trades submitted — is a standing operational KPI. A healthy DK rate is typically 0.1% to 0.5% of submitted trades; rates above 1% suggest systemic data quality issues in the OMS, enrichment layer, or allocation process, and typically trigger a management review.
Regulatory Framework
SEC Rule 15c6-2 requires broker-dealers to have written agreements with institutional customers establishing same-day affirmation procedures. A DK that remains unresolved past the 9:00 PM ET DTCC affirmation target significantly increases the probability of a T+1 settlement fail.
Under FINRA Rule 3110 (Supervision), FINRA Rule 4511 (Books and Records), and the standards of commercial honor under FINRA Rule 2010, broker-dealers must maintain and enforce written supervisory procedures for trade-date exception monitoring — including DK detection, investigation, and resolution. Every DK must be logged with a timestamp, the reason code, the corrective action, and the resolution outcome. Examiners reviewing a firm's T+1 affirmation performance will request DK logs; a pattern of unresolved DKs or DKs resolved after the affirmation window is an examination finding.
A T+1 settlement fail on the delivery side may trigger Regulation SHO Rule 204 close-out obligations if the fail results in a fail-to-deliver position. The broker-dealer must close out the fail by the beginning of regular trading hours on the third consecutive settlement day following the fail date; a buy-in may be required if the securities cannot otherwise be sourced.
Atomic Settlement and DK Reduction
DKs arise structurally from the asynchronous nature of traditional post-trade processing: the broker records the trade in one system, the IM records it independently, and the two records are compared after the fact through a matching platform. The time between execution and matching — the alleged phase — is where DKs originate. Atomic DvP settlement using smart contracts moves the matching requirement from the post-execution phase to the pre-execution signing phase. Both parties must sign identical trade parameters — price, quantity, security identifier, counterparty, and settlement date — before the transaction broadcasts to the ledger. If any parameter does not match, the transaction does not execute. This approach dramatically reduces the class of reconciliation breaks that produce traditional DKs. Token identifier errors, smart contract address mismatches, and on-chain settlement instruction mismatches can still occur on digital rails — but the structural DK that arises from two independent record-keeping systems comparing notes after a trade has already been executed is largely eliminated.
DK lifecycle — alleged trade through settlement or fail
Devancore Glossary · devancore.com
DK lifecycle — alleged trade through settlement or fail
Devancore Glossary · devancore.com
How it works
1. Trade Execution, Allocation, and CTM Submission
At execution, the broker's OMS generates a FIX execution report capturing price, quantity, security identifier (CUSIP/ISIN), executing broker identity, and settlement convention. The trade is allocated across accounts — a step where quantity errors frequently originate — and enriched with SSI and counterparty data. The enriched, allocated trade is submitted to a post-trade matching platform (DTCC CTM for US institutional equities). From the IM's perspective, the trade now appears as an alleged trade in their platform queue.
2. Alleged Trade Review
The IM's operations team, custodian, or automated middleware compares the alleged trade field-by-field against the IM's own OMS record. Automated systems (Alpha, Aladdin, Charles River) may affirm without human intervention if all fields match. If any field is out of tolerance — price, quantity, account, CUSIP, settlement date — the auto-affirm fails and the trade surfaces for manual review or an automated DK is issued.
3. DK Notification and Reason Code
The DK notification appears in the broker's exception queue with a reason code identifying the discrepancy. The operations team reads the code and immediately pulls the original FIX execution report to establish the broker's authoritative record of the trade economics and compare it field-by-field against the CTM submission.
4. Break Investigation
The team determines whether the discrepancy is broker-side (enrichment error, allocation mistake, wrong CUSIP from instrument master, step-out fund ID mismatch) or IM-side (booking at a different price, wrong account, OMS data entry error). This distinction determines the resolution path: if broker-side, the broker corrects and resubmits; if IM-side, the broker communicates the discrepancy and the IM must correct their records.
5. Counterparty Contact and Agreement
The operations team contacts the IM's operations desk to communicate the discrepancy finding. Every contact attempt is logged with a timestamp and the name of the person contacted — this log is the firm's primary documentation of good-faith resolution effort for FINRA examination purposes. For broker-side errors, the broker acknowledges the correct economics; for IM-side errors, the IM corrects their OMS or both parties agree on a correction. If the IM is unreachable, the DK cannot be resolved regardless of the broker's own readiness.
6. Amendment and Resubmission
The corrected trade data is applied to the OMS and submitted to the matching platform as an amended instruction with the agreed economics. For a step-out DK, the fund identifier or prime broker account is corrected before resubmission. The IM reviews the amended submission — the same review cycle as the original alleged trade.
7. Affirmation or Deadline Miss
If the IM affirms the amended submission before the DTCC 9:00 PM ET affirmation target, the trade enters the settlement instruction pipeline and proceeds to DTC settlement on T+1. If the target passes with the trade still in DK or alleged status, the affirmation window has been missed — the probability of a T+1 settlement fail is significantly elevated. A fail-to-deliver on the broker's delivery side may trigger Regulation SHO Rule 204 close-out obligations.
8. Audit Log and Supervisory Review
Every step — DK detection time, reason code, investigation findings, counterparty contact attempts with timestamps, amendment, resubmission, and final resolution — is logged with user IDs under the firm's written supervisory procedures. The log satisfies FINRA Rule 3110 and 4511 requirements and provides the examiner documentation for any failed-trade review. DK resolution time — from detection to re-affirmation — is tracked as a standing operational KPI.
DK resolution — break investigation to affirmation
Devancore Glossary · devancore.com
DK resolution — break investigation to affirmation
Devancore Glossary · devancore.com
In Devancore™
Devancore DK management — detection to resolution
Devancore Glossary · devancore.com
Devancore DK management — detection to resolution
Devancore Glossary · devancore.com
Devancore's exception management module treats a Don't Know notice as a critical inhibitor to straight-through processing and surfaces it for immediate action from the CTM feed — not in an end-of-day batch, but in real time throughout the trading session.
Real-Time DK Detection
Devancore monitors the DTCC CTM feed continuously during the trading session. When a counterparty issues a DK, Devancore flags it in the Trade Break Manager within seconds of the notification appearing in CTM — with the reason code, the time remaining before the DTCC 9:00 PM ET affirmation target, and the original FIX execution report fields for the trade displayed side by side for immediate comparison.
Automated Break Analysis
On detecting a DK, Devancore cross-references the CTM submission against the original FIX execution report, the instrument master (correct CUSIP and ISIN), and the allocation record (quantity per account and fund identifier). This comparison isolates the field at fault — price, quantity, CUSIP, account, or settlement date — and identifies whether the source is in the broker's OMS, the enrichment layer, or a step-out fund ID mismatch. The root cause and the specific field are surfaced in the break management interface before an analyst manually reviews the trade.
Counterparty Contact Logging
When resolution requires counterparty contact, Devancore's break management interface allows the operations analyst to log every outreach attempt — timestamp, contact name, outcome — directly against the DK record. A log showing "called IM ops desk at 5:15 PM, 6:00 PM, and 7:00 PM ET" is the firm's primary documented evidence of good-faith resolution effort during a FINRA examination of a failed trade. The contact log is attached to the DK record and preserved in the audit trail.
Amendment, Resubmission, and Audit Trail
Once correct economics are established, the analyst applies the correction in the break management interface and Devancore resubmits the amended instruction to CTM. The corrected values are written back to the trade record, and the resubmission is linked to the original alleged trade for audit continuity. Every DK event — detection, investigation, contact attempts, amendment, resubmission, and resolution — is logged with timestamps and user IDs, satisfying FINRA Rule 3110 and 4511 requirements and producing the supervisory audit trail an examiner would request when reviewing the firm's T+1 affirmation performance.