Don't Know (DK)

Trading creates records on both sides of a transaction, and those records must describe the same agreement for operations to confirm and settle it correctly. A DK arises when a party rejects the execution it received or cannot match it to its own information.

The discrepancy can be simple, such as a quantity entered incorrectly or a price that differs between systems, but small-looking errors can still create a material exposure when the transaction is large. The security identifier must also match, since similar names, multiple share classes or different settlement instruments can lead to a wrong match, and a familiar company name does not establish that both sides agreed to the same security.

Timing and account details can matter, because a transaction may belong to another allocation, trading date or client account. Operations should recover the original execution evidence instead of changing a record merely to make the systems agree.

FIX's standard DontKnowTrade message describes an electronically received execution rejection, telling systems how to communicate an exception, but it does not decide the parties' legal rights or the commercial solution to every dispute. A DK is not a trading recommendation: the response flags a matching or recognition problem, and it should not be used as a convenient way to avoid an agreed trade after the market has moved against one side.

Original evidence is important, since order records, execution reports, timestamps and permitted communication records can help establish what happened, whereas a later summary is less useful if it cannot be linked to those details. Investigation should distinguish clerical and substantive differences, because correcting a typo in a confirmed agreement differs from deciding that the counterparties never agreed to the same terms, and the proposed correction needs the relevant approval and audit trail.

The exposure can remain while the dispute is open, as market prices may move and expected receipts or deliveries may be uncertain, so risk management should not assume an unrecognised record means no economic position exists. Settlement deadlines create pressure, since a mismatch can delay delivery or payment and may contribute to a failed settlement, so escalation should be timely without using urgency as a reason to accept unverified terms.

Client allocation needs care, because an unresolved trade should not be assigned to a convenient account merely to clear an exception, and the account and quantities must be grounded in the actual authorised order and execution. System updates require consistency: if the parties agree a correction, all relevant books and downstream reports should reflect the corrected terms, because fixing one screen while leaving another record unchanged can reproduce the problem later.

The audit trail should preserve the history, recording the original mismatch, investigation, agreed treatment and completion evidence, since deleting the disputed record without a trace can conceal whether the underlying exposure was handled properly. For a non-finance manager, treat a DK as an open operational and risk issue.

Identify the precise disagreement, responsible parties and evidence needed for resolution. Do not report the transaction as settled or cancelled until the agreed outcome has been verified.