Imported from previous forum
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
Hi there,
I am wondering if the spec regulates if an OrdType such as Market with leftover as Limit/Stop Limit must change after a fill/triggering event? I know that some exchanges (e.g. CME) do change it, while others (e.g. BM&FBovespa) do not.
If there is no standard behaviour, is this something that is was addressed by any working groups? ECN/Exch WG maybe?
Regards,
Andrei Goldchleger
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
Anyone?
Andrei,
I do not think there is a standard behaviour although the verbiage of FIX 5.0 SP2 is quite clear on the case you mention:
40 OrdType K = Market With Left Over as Limit (market order with unexecuted quantity becoming limit order at last price)
However, FIX 5 also allows you to make the behaviour explicit for any order type change by using the following fields:
1101 TriggerAction = 2 = Modify
1100 TriggerType = 1 = Partial Execution
1111 TriggerOrderType = 2 = Limit (or whatever you need it to become)
The question becomes what value it is to always know the initial type of an order. Would it help to have a field like InitialOrdType that reflects the value during order entry? This could also cover the case of a triggered stop order becoming a regular (market/limit) order. ExecType = L = Triggered will only cover the event when it changed. Tag 636 WorkingIndicator is intended only for OrdStatus=New.
My view is that it is better to change the order type if the order also behaves differently. A market order is no longer a market order but a limit order if the price is taken into account for matching. A stop order is no longer a stop order but a regular order if it can participate in matching.
Regards,
Hanno.
Hi there,
I am wondering if the spec regulates if an OrdType such as Market with
leftover as Limit/Stop Limit must change after a fill/triggering event?
I know that some exchanges (e.g. CME) do change it, while others (e.g.
BM&FBovespa) do not.If there is no standard behaviour, is this something that is was
addressed by any working groups? ECN/Exch WG maybe?Regards,
Andrei Goldchleger
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
> Andrei,
I do not think there is a standard behaviour although the verbiage of
FIX 5.0 SP2 is quite clear on the case you mention:40 OrdType K = Market With Left Over as Limit (market order with
unexecuted quantity becoming limit order at last price)However, FIX 5 also allows you to make the behaviour explicit for any
order type change by using the following fields:1101 TriggerAction = 2 = Modify 1100 TriggerType = 1 = Partial Execution
1111 TriggerOrderType = 2 = Limit (or whatever you need it to become)The question becomes what value it is to always know the initial type of
an order. Would it help to have a field like InitialOrdType that
reflects the value during order entry? This could also cover the case of
a triggered stop order becoming a regular (market/limit) order. ExecType
= L = Triggered will only cover the event when it changed. Tag 636
WorkingIndicator is intended only for OrdStatus=New.My view is that it is better to change the order type if the order also
behaves differently. A market order is no longer a market order but a
limit order if the price is taken into account for matching. A stop
order is no longer a stop order but a regular order if it can
participate in matching.Regards, Hanno.
Ok then, I got your point.
Regarding Stop orders, which is the preferable way to do it? ExecType = L (Triggered) or WorkingIndicator = Y?
Andrei,
I do not think there is a standard behaviour although the verbiage of
FIX 5.0 SP2 is quite clear on the case you mention:40 OrdType K = Market With Left Over as Limit (market order with
unexecuted quantity becoming limit order at last price)However, FIX 5 also allows you to make the behaviour explicit for any
order type change by using the following fields:1101 TriggerAction = 2 = Modify 1100 TriggerType = 1 = Partial
Execution 1111 TriggerOrderType = 2 = Limit (or whatever you need it
to become)The question becomes what value it is to always know the initial type
of an order. Would it help to have a field like InitialOrdType that
reflects the value during order entry? This could also cover the case
of a triggered stop order becoming a regular (market/limit) order.
ExecType
= L = Triggered will only cover the event when it changed. Tag 636
WorkingIndicator is intended only for OrdStatus=New.My view is that it is better to change the order type if the order
also behaves differently. A market order is no longer a market order
but a limit order if the price is taken into account for matching. A
stop order is no longer a stop order but a regular order if it can
participate in matching.Regards, Hanno.
Ok then, I got your point.
Regarding Stop orders, which is the preferable way to do it? ExecType =
L (Triggered) or WorkingIndicator = Y?
ExecType describes an event that occurred as opposed to WorkingIndicator being an attribute of the order. One could argue that WorkingIndicator can be used to always communicate that this order was once “not working” and then became active. This would violate the current spec that tells you to only use it for OrdStatus=“New”. It is the older field of the two and currently has a somewhat limited scope.
ExecType “Triggered” was introduced together with the new component block and is intended to communicate that the triggering condition (which could be complex, not just a stop order) was met. I believe it is the better way to communicate a stream of events. It gets tricky if an order is triggered and immediately matched. If you want to send a singel message for this event, you can only put the last event “Trade” into ExecType and need to defer the fact that is must have been triggered prior to being matched. or you send out two messages, one with “Triggered” and the other with “Trade”.
Maybe it would make sense to add a TriggerIndicator into the trigger block to convey on subsequent ExecutionReports that this order has been triggered. WorkingIndicator was not really meant for this purpose.
Regards,
Hanno.