Hoping I can get some feedback here, as we seem to have an operational gap with a counterparty,and want to know what the FIX community thinks.
Scenario:
GTC order sent Day 1 - 1000 shares
Day 1 either get no fills or partial fills
Tag 11= 123420180404
Tag 1 is sent: 123456789
Day 2 -
Order Status Request (35=H) is sent, with Tag 11=123420180404 but Tag1 is MISSING in 35=H.
Tag 1 is not required by FIX, but is required by this counterparty.
Because of the counterparty requires Tag1, DK issued on the 35=H message for Tag 11= 123420180404.
After the DK for the 35=H is received, fills continue to come in for Tag 11= 123420180404.
In our firm’s view, if the order is DK’d no fills should come in after the DK on the 35=H message, and that the order should be checked against Tag 11 only. Not Tag 11+Tag1.
However, counterparty says that the DK on the 35=H is different than the live order, and that’s why their FIX engine continues to send fills. Because they didn’t know what order it was on the 35=H, since they require Tag1.
Please provide your take on the scenario above, as I don’t see any documentation spelled out anywhere in this instance.
You are correct in your assessment that this topic is missing in the documentation. Therefore, I can only give you my opinion.
My opinion is similar to that of your counterparty. The order status request issued by your application was “incorrect” (from the rules of engagement between you and your counterparty). The request appears to be suitably rejected by your counterparty. I don’t see this as having any impact on the existing state of the order, or on future actions for that order. To my mind, this is similar to having an order-modification request rejected.
@monica, can you please clarify what “order is DK’d” means? The FIX concept of DK is only applicable to trades, i.e. ExecutionReports identifying a trade can be DKed with the DontKnowTrade (MsgType=Q) message. I am assuming that your OrderStatusRequest (MsgType=H) was answered with an ExecutionReport (MsgType=8) having OrdRejReason(103) = 5 (unknown order). But maybe it was a session level Reject (MsgType=3) message with SessionRejectReason(373) = 3 (Required Tag Missing).
Let me rephrase this a bit because I have an additional question and different views after doing more research.
The FIX engine our company uses forces 35=H messages on Day 2 and onward on any open GTC orders. There is no documentation in the FIX protocol that I see that says this message is mandatory. So if anyone has documentation on this question (a yes or a no), that would be helpful.
I also now think that our FIX engine should not reject fills coming in on a live order, even if our FIX engine received a 35=3 Reject for the OrderStatusRequest message 35=H.
A 35=3 is a protocol error. You shouldn’t be doing anything with orders/fills or anything ‘business related’ in response to a 35=3 - you should be fixing your application so it conforms with the counterparty (and updating conformance documentation to ensure it doesn’t regress again). The only action you should take is based on assuming you never sent the 35=H.
For 35=j maybe the situation might be different. But for 35=3, the expectation is clear - the original message should be treated as if it were never sent.
35=3 are issued for Data Dictionary errors, invalid message format error and other stuff (e.g. bad checksum).
I would also suggest that philosophically speaking it’s a really bad idea to ignore a fill that’s been sent to you. Chances are far greater that you’ve got a difference of opinion about the status of an order than they are that the exchange is just sending you random fills for fun. Even if you choose to suppress sending that fill on to the traders, you should be logging a warning somewhere to cover your ass.
Agree with @philipwhiuk that a session level reject means you have to take action by looking at your software and whether they conform to the Rules of Engagement with your counterparty. Your order status request is semantically incorrect as it does not include enough information for your counterparty to provide a proper response. The response you get does not allow you to take any action on the order in your local book, i.e. you must be prepared for further fills or unsolicited changes coming from your counterparty.
Your design foresees the confirmation of all open (from your point of view) orders in the morning by sending a status request for each of them. I would say you are lucky that your counterparty offers such a function. However, you then must provide all fields defined as mandatory by your counterparty for the request. A different approach would be that your counterparty sends out restatements of open orders every morning. Orders that are not restated have reached a terminal state (e.g. expired) and can be removed from your local order book unless they should still be active from your perspective.
All , thanks for the feedback. Unfortunately, this is a vendor FIX gateway, and it’s very locked down in what we as the client can configure. I’m going to speak to them about this, but wanted to gather some community feedback before going in with only 1 opinion (mine).
