DK Trades (Don't Know Trade)

A Don't Know Trade (DK, MsgType Q) is how a FIX counterparty rejects an execution it doesn't recognize: wrong side, unknown symbol, quantity exceeding the order, or a fill it simply never asked for. DK handling is a classic certification item and a common source of production disputes, so FIXSIM supports testing it in both directions.

Simulating a counterparty that DKs your executions

When your system sends execution reports to FIXSIM, you can make FIXSIM push back. Create a rule in the Rule Builder that triggers on Execution Report (Target Msg Type 8), adding tag conditions if you only want to DK specific fills, and give it the Reject action. FIXSIM responds to each matching execution with a DontKnowTrade (35=Q), and your system's DK handling runs exactly as it would against a real counterparty.

Capturing DKs your system sends

The reverse direction: FIXSIM sends your application a fill, and your application DKs it. FIXSIM captures the inbound DontKnowTrade and attaches it to the execution it refers to, correlated by ExecID (tag 17) on the same session. The captured DK records the DKReason (tag 127), the free-form Text (tag 58), the arrival time, and the complete raw FIX message for audit or dispute-style scenarios.

Captured DKs are exposed through the REST API: any ExecutionsOut query returns a dontKnow object on each execution that was DK'd; the field is omitted entirely for executions that weren't, so existing integrations are unaffected.

curl -H "apiKey: YOUR_API_KEY" \
  "https://portal.fixsim.com/v1/ExecutionsOut/{instance}/{session}/ORD-001"

{
  "execId": "EXEC-4711",
  "clOrdId": "ORD-001",
  ...
  "dontKnow": {
    "reason": "B",
    "receivedTime": "2026-08-11T14:30:02Z",
    "text": "Wrong side",
    "fixMessage": "8=FIX.4.4|9=...|35=Q|17=EXEC-4711|127=B|58=Wrong side|...|10=042|"
  }
}

This makes DK scenarios assertable in CI/CD: drive a fill out of FIXSIM, have your system DK it, then query ExecutionsOut and assert the dontKnow.reason you expect.

DKReason codes

Tag 127 value	Meaning
A	Unknown symbol
B	Wrong side
C	Quantity exceeds order
D	No matching order
E	Price exceeds limit
F	Calculation difference
Z	Other

Notes

• Inbound DKs appear in the session's Overview message feed as Don't Know Trade rows; the captured DK detail (reason, text, raw message) is queried via the API.
• A DK must reference the ExecID of an execution FIXSIM actually sent on that session; a DK with an unknown ExecID is logged and ignored, which is itself a useful negative test.
• If an execution is DK'd more than once, the most recent DK is the one retained.

For the broader execution-testing workflow (fills, busts, and corrections), see Blotter In and the REST API guide.