Imported from previous forum
Is the following scenario valid
Buy side sends order
Sell Side sends Ack
Sell Side sends part fill
Sell Side sends DFD
Sell Side sends full fill
The issue is that the full fill message contains tag OrdStatus = 3 and tag ExecType = 2. Is this an invalid tag combination. I would expect OrdStatus = 2 and ExecType = 2 for the final fill. The 4.2 documentation seems to state that this should be the case.
[ original email was from Robert Benoit - Robert.Benoit@transacttools.net ]
> the done for day ordstatus is right. If you look at the FIX 4.2 spec, it lists the precedent of OrdStatus values, and done for day is higher than fill.
Is the following scenario valid
Buy side sends order Sell Side sends Ack Sell Side sends part fill Sell
Side sends DFD Sell Side sends full fillThe issue is that the full fill message contains tag OrdStatus = 3 and
tag ExecType = 2. Is this an invalid tag combination. I would expect
OrdStatus = 2 and ExecType = 2 for the final fill. The 4.2 documentation
seems to state that this should be the case.
[ original email was from John Prewett - jprewett@lavatrading.com ]
I would argue that the scenario you describe is completely invalid. How can you receive a fill after a done-for-day? Does that mean that done-for-day means “done for day unless I send you something else”? If this is the case, clearly done-for-day is completely meaningless and should be discarded.
The issue shouldn’t be concerning the precedence of the different OrdStatus values. The issue should be that the sell side is sending messages in an incorrect sequence. Done-for-day should be the last message from the sell side concerning this order today.
FIX - let’s try and keep it as an AON standard, lest we become DFD.
JohnP
[ original email was from Greg Wood - gregjwood@hotmail.com ]
Whilst I agree that the scenario described is invalid since you cannot say a client is done for day and then send fills afterwards, in defence of the sell-side we are often at the mercy of exchanges with regards the sequencing of messages.
Broadcast and multi-channel based exchange architecture (e.g. OMNet/LIFFEConnect) often return order status messages such as acknowledgements on cancels/replaces or done-for-day messages well before an execution. Translating this sort of asynchronous behaviour into synchronous FIX messages can make it difficult to trap the out-of-sequence message from the exchange before it is prematurely returned to the client.
Common causes of this scenario are IOC or FOK tifs where the order is noted as lapsed on the exchange on one channel whilst executions are returning on another channel, or a cancel/replace request to amend a quantity down crosses with a partial fill for that exact quantity.
- Greg
I would argue that the scenario you describe is completely invalid. How
can you receive a fill after a done-for-day? Does that mean that done-for-
day means “done for day unless I send you something else”? If this is
the case, clearly done-for-day is completely meaningless and should be
discarded.The issue shouldn’t be concerning the precedence of the different
OrdStatus values. The issue should be that the sell side is sending
messages in an incorrect sequence. Done-for-day should be the last
message from the sell side concerning this order today.FIX - let’s try and keep it as an AON standard, lest we become DFD.
JohnP
I would argue that the scenario you describe is completely invalid.
How can you receive a fill after a done-for-day? Does that mean that
done-for- day means “done for day unless I send you something else”?
If this is the case, clearly done-for-day is completely meaningless
and should be discarded.The issue shouldn’t be concerning the precedence of the different
OrdStatus values. The issue should be that the sell side is sending
messages in an incorrect sequence. Done-for-day should be the last
message from the sell side concerning this order today.Whilst I agree that the scenario described is invalid since
you cannot say a client is done for day and then send fills
afterwards, in defence of the sell-side we are often at the
mercy of exchanges with regards the sequencing of messages.Broadcast and multi-channel based exchange architecture (e.g.
OMNet/LIFFEConnect) often return order status messages such
as acknowledgements on cancels/replaces or done-for-day
messages well before an execution.
Frankly, I believe this is simply bad design. It’s certainly simple enough for the exchange to channel its outbound messages by message type; but, the cost on the back-end is the amounts of unnecessary message checking required to determine whether you’ve received the messages in the proper order, and what to do about it if you’ve not.
Years ago, at another company, I worked with some bright spark working for one of our customers, who thought it a wonderful idea to channel his inbound message traffic by message type. The result was that he would sometimes receive cancel or cancel/replace requests before he had received the order they referenced! He then proceeded to try to re-work his code, to hold onto unmatched requests, in the expectation that he would eventually receive the order, and to ‘timeout’ and really reject it, after some period of time, if he didn’t receive it.
Translating this sort of asynchronous behaviour into
synchronous FIX messages can make it difficult to trap the
out-of-sequence message from the exchange before it is
prematurely returned to the client.
Precisely. So, why bother? All the receiver wants to do is get the traffic into her system as quickly as possible. Once there, multiple order, execution, quote, whatever processors can handle the load; but, I’m not interested in spending unnecessary cycles deciphering inbound traffic, or making ‘intelligent’ decisions about what I should do with it. The only decision I want to make at that point is when I find a gap; if I don’t, then just keep feeding me messages.
I don’t deal with OMNet or LIFFE here; but, isn’t there an option to gratiously turn down their request for multi-channel input streams? Their offer seems more like a Trojan horse to me. The only time we use multi-channel input is for pass-throughs; but, even then, all of the traffic for any given customer flows on the same channel.
this is a Good Till Cancel Order
I would argue that the scenario you describe is completely invalid. How
can you receive a fill after a done-for-day? Does that mean that done-for-
day means “done for day unless I send you something else”? If this is
the case, clearly done-for-day is completely meaningless and should be
discarded.The issue shouldn’t be concerning the precedence of the different
OrdStatus values. The issue should be that the sell side is sending
messages in an incorrect sequence. Done-for-day should be the last
message from the sell side concerning this order today.FIX - let’s try and keep it as an AON standard, lest we become DFD.
JohnP