Imported from previous forum
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Originally posted by Oliver Herrmann, RTS <o.herrmann@rtsgroup.net> in the General Q/A: discussion group:
Hello,
I think a Order Mass Status Request should return several Execution Report messages.
Is there any possibillity to indicate when the response to the request is completed ? (e.g. a flag in the last Execution Report or a separate message)
Thanks
Oliver
Reply from Jim Northey:
Oliver,
The Order Mass Status Request is intended to result in the communication of an Execution Report for each active order with a counterparty (such as an exchange or brokerage). The message was intended more for recovery situations where you need to find out after D-R, major market event, system failover the state of orders with a counterparty. We didn’t really intend for it to be a recommended part of business flow due to the volume of messages that may result from a request.
It was a complement to the Order Mass Cancel Request message - which was provided to permit bailing out of markets in the event of some major market or system event.
At the time of design - it was felt that counterparties may not have a way of knowing how many messages will be returned as part of the reply - and the messages may be returned from multiple sources within the counterparty - so definition of the number of messages being returned or indicating which message is the last one would be difficult to indicate.
We have not up to this point included a terminating flag on messages in the order space.
You do indicate a question that I will throw out to others - how do you decide when you have received all the status messages from a counterparty? I don’t have an answer - maybe someone else can offer some suggestions.
Reply from Oliver:
Jim,
the Order Mass Status Request is very important for a restart scenario of a FIX client. In the majority of cases a client is not connected 24 hours to an exchange. When it restarts it needs to know the status of all his orders (Good Till Cancel Orders, Timed Orders, …).
The Order Mass Status Request fits very well for this purpose, but one needs to know when the last Execution Report is received to complete the recovery handling.
The current FIX standard also lacks the possibility to request some(or all) order executions. After a restart one should be able to request all executions that occured while the client was not connected.
May be an own request can be introduced for this purpose to request all executions
- since a date
- since a ExecID
- since last Logout
I don’t think the resend request should be used for these scenarios, because it will return normally all type of messages. For a longer downtime more uninteresting messages will be returned. And if the sequence number is reseted there is even no way.
Response from JN recommending making this a proposed change for FIX 4.4:
Oliver,
I understand your concern and issues - your main focus is on missing fills between sessions in the event of a lost connection. During market session we queue these records at the CBOE for guaranteed delivery as should other markets. If it is across days/sessions - the trade match / clearing should give an accurate portrayal.
One last shot at sharing my opinion and then I will give a recommendation on how we should proceed to address your concerns and requirements. At the CBOE we built the electronic trading system to provide order status on start up - what results from that proces in a recovery scenario can be extremely onerous in terms of the amount of information transmitted at logon time and the time delay it causes to the recoverying firm. It would be better I think to build a firm system to query for the status of GTC orders by number as opposed to asking status on all active orders. The CBOE quickly (in version 2.0) added the capability to logon without republishing order status to get around the problem created by publishing order status on login. Okay enough of my two cents and opinions…
The recovery scenario you require is not fully supported by the message semantics right now in FIX 4.3. I will copy this email thread over to 4.4 Changes discussion. This will cause your concerns and issues to become a candidate change to the spec that will be presented to the Global Technical Committee when work on 4.4 starts. The Global Technical Committee is the appropriate venue for address your requirement to see if it should be supported by FIX messages and semantics.
FYI - 4.4 work is starting very soon, with publication soon to follow after that - so addressing your issue will happen sooner than later.
Hope this helps.