Imported from previous forum
Hi,
Following the triggering of a Stop Limit Order if the order behaves as a limit order should the Order Type(40) of the order be changed to Limit, or should it remain as a Stop Limit Order.
The Order State Change Martices in FIX 5.0 refers to such a scenario in E.1.f but does not mention a change in the Order Type.
Is there a standard model for supporting Order Type Amendments in FIX for such orders.
OrdType should change to a limit (or market) order to show that it now no longer behaves like a stop but is simply an active order. If you need to maintain the information on the order (in the ExecutionReport) that it was once a stop order then I would use user-defined field 6489 TriggerIndicator. It is a good candidate for a standard field but nobody has submitted a formal proposal for it yet (we might…).
Hi,
Following the triggering of a Stop Limit Order if the order behaves as a
limit order should the Order Type(40) of the order be changed to Limit,
or should it remain as a Stop Limit Order.The Order State Change Martices in FIX 5.0 refers to such a scenario in
E.1.f but does not mention a change in the Order Type.Is there a standard model for supporting Order Type Amendments in FIX
for such orders.
[ original email was from Harish Kamaley - harish.kamaley@wipro.com ]
The OrderType(40) should not be changed from StopLimit to Limit in execution reports but the system has the capability to handle the StopLimit order as a Limit order. (It can be changed for order matching, but it will remain same while sending the execution reports for these orders)
If ordertype is changed in execution reports then buy side will send DK message saying initial attributes(40=4 StopLimit) of the order does not matches with 35=D message.
Please correct me if iam wrong.
Thanks
Harish
OrdType should change to a limit (or market) order to show that it now
no longer behaves like a stop but is simply an active order. If you need
to maintain the information on the order (in the ExecutionReport) that
it was once a stop order then I would use user-defined field 6489
TriggerIndicator. It is a good candidate for a standard field but nobody
has submitted a formal proposal for it yet (we might…).Hi,
Following the triggering of a Stop Limit Order if the order behaves as
a limit order should the Order Type(40) of the order be changed to
Limit, or should it remain as a Stop Limit Order.The Order State Change Martices in FIX 5.0 refers to such a
scenario in
E.1.f but does not mention a change in the Order Type.Is there a standard model for supporting Order Type Amendments in FIX
for such orders.
I would identify an order by its unique ID and not by some or all of its attributes, some of which can change for a number of reasons. I would also not recommend such checks in the interest of performance. It is more of a sanity check but I would limit it to the instrument, side and order quantity as is recommended for the OrderCancelRequest (it does not have OrdType).
The TriggeringInstruction component block is a more generic way to define stop orders (and much more complex triggers). You would use TriggerAction=2=Modify and set TriggerOrderType to market or limit. The field description defines that this is to cause a change in OrdType.
Regards,
Hanno.
The OrderType(40) should not be changed from StopLimit to Limit in
execution reports but the system has the capability to handle the
StopLimit order as a Limit order. (It can be changed for order
matching, but it will remain same while sending the execution reports
for these orders)If ordertype is changed in execution reports then buy side will send DK
message saying initial attributes(40=4 StopLimit) of the order does not
matches with 35=D message.Please correct me if iam wrong.
Thanks Harish
OrdType should change to a limit (or market) order to show that it now
no longer behaves like a stop but is simply an active order. If you
need to maintain the information on the order (in the ExecutionReport)
that it was once a stop order then I would use user-defined field 6489
TriggerIndicator. It is a good candidate for a standard field but
nobody has submitted a formal proposal for it yet (we might…).Hi,
Following the triggering of a Stop Limit Order if the order behaves
as a limit order should the Order Type(40) of the order be changed
to Limit, or should it remain as a Stop Limit Order.The Order State Change Martices in FIX 5.0 refers to such a
scenario in
E.1.f but does not mention a change in the Order Type.Is there a standard model for supporting Order Type Amendments in
FIX for such orders.
[ original email was from Greg Wood - gregjwood@hotmail.com ]
Hi Hanno, Harish, Suram,
General convention for handling stop and stop-limit orders is to keep the OrdType as 3 or 4 even when the order is triggered and becomes a market or limit order in the book. Typically the OrdType remains as the instruction to the counterparty through the life of the order.
Counterparties - whether an exchange or broker - would usually convey the state change via the WorkingIndicator (tag 636) in 4.4 or later by publishing a second New message with 636=Y. Of course in earlier versions of FIX we don’t have that additional granularity and there is usually nothing conveyed on the state change caused by the trigger of the stop.
With regards to validation of unsolicited amends on OrdType if it does change from 3 to 1 or 4 to 2, then the vendor community in particular are a mixed bag. Some care about consistency of tags like this and will DK a message if a value like tag 40 changes, most don’t care. That’s why we certify, identify issues like this, and then agree on rules of engagement in production.
Regards,
- Greg
I would identify an order by its unique ID and not by some or all of its
attributes, some of which can change for a number of reasons. I would
also not recommend such checks in the interest of performance. It is
more of a sanity check but I would limit it to the instrument, side and
order quantity as is recommended for the OrderCancelRequest (it does not
have OrdType).The TriggeringInstruction component block is a more generic way to
define stop orders (and much more complex triggers). You would use
TriggerAction=2=Modify and set TriggerOrderType to market or limit. The
field description defines that this is to cause a change in OrdType.Regards, Hanno.
The OrderType(40) should not be changed from StopLimit to Limit in
execution reports but the system has the capability to handle the
StopLimit order as a Limit order. (It can be changed for order
matching, but it will remain same while sending the execution reports
for these orders)If ordertype is changed in execution reports then buy side will send
DK message saying initial attributes(40=4 StopLimit) of the order does
not matches with 35=D message.Please correct me if iam wrong.
Thanks Harish
OrdType should change to a limit (or market) order to show that it
now no longer behaves like a stop but is simply an active order. If
you need to maintain the information on the order (in the
ExecutionReport) that it was once a stop order then I would use user-
defined field 6489 TriggerIndicator. It is a good candidate for a
standard field but nobody has submitted a formal proposal for it yet
(we might…).Hi,
Following the triggering of a Stop Limit Order if the order
behaves as a limit order should the Order Type(40) of the order be
changed to Limit, or should it remain as a Stop Limit Order.The Order State Change Martices in FIX 5.0 refers to such a
scenario in
E.1.f but does not mention a change in the Order Type.Is there a standard model for supporting Order Type Amendments in
FIX for such orders.
Does FPL/GTC have a view as to what the best practice is? Should the order type be changed when stop orders (and other such contingent orders) are triggered? Or, as there may not be a consensus, is this a matter that FPL/GTC feel should be left for the parties to agree on in the rules of engagement?
Hi Hanno, Harish, Suram,
General convention for handling stop and stop-limit orders is to keep
the OrdType as 3 or 4 even when the order is triggered and becomes a
market or limit order in the book. Typically the OrdType remains as the
instruction to the counterparty through the life of the order.Counterparties - whether an exchange or broker - would usually convey
the state change via the WorkingIndicator (tag 636) in 4.4 or later
by publishing a second New message with 636=Y. Of course in earlier
versions of FIX we don’t have that additional granularity and there
is usually nothing conveyed on the state change caused by the trigger
of the stop.With regards to validation of unsolicited amends on OrdType if it does
change from 3 to 1 or 4 to 2, then the vendor community in particular
are a mixed bag. Some care about consistency of tags like this and will
DK a message if a value like tag 40 changes, most don’t care. That’s why
we certify, identify issues like this, and then agree on rules of
engagement in production.Regards,
- Greg
I would identify an order by its unique ID and not by some or all of
its attributes, some of which can change for a number of reasons. I
would also not recommend such checks in the interest of performance.
It is more of a sanity check but I would limit it to the instrument,
side and order quantity as is recommended for the OrderCancelRequest
(it does not have OrdType).The TriggeringInstruction component block is a more generic way to
define stop orders (and much more complex triggers). You would use
TriggerAction=2=Modify and set TriggerOrderType to market or limit.
The field description defines that this is to cause a change in
OrdType.Regards, Hanno.
The OrderType(40) should not be changed from StopLimit to Limit in
execution reports but the system has the capability to handle the
StopLimit order as a Limit order. (It can be changed for order
matching, but it will remain same while sending the execution
reports for these orders)If ordertype is changed in execution reports then buy side will send
DK message saying initial attributes(40=4 StopLimit) of the order
does not matches with 35=D message.Please correct me if iam wrong.
Thanks Harish
OrdType should change to a limit (or market) order to show that it
now no longer behaves like a stop but is simply an active order.
If you need to maintain the information on the order (in the
ExecutionReport) that it was once a stop order then I would use
user- defined field 6489 TriggerIndicator. It is a good candidate
for a standard field but nobody has submitted a formal proposal
for it yet (we might…).Hi,
Following the triggering of a Stop Limit Order if the order
behaves as a limit order should the Order Type(40) of the order
be changed to Limit, or should it remain as a Stop Limit Order.The Order State Change Martices in FIX 5.0 refers to such a
scenario in
E.1.f but does not mention a change in the Order Type.Is there a standard model for supporting Order Type Amendments
in FIX for such orders.
It is unlikely that there will be a formal answer from the GTC on this matter here in the forum. In general it is best practice to echo back the input values of a new order to support drop copies. If drop copies are not needed then you might get back fewer fields. It is also best practice to restate an order back to the submitter in case of unsolicited changes. The restatement can affect price, quantity or other order attributes such as order type. However, this says nothing about whether the recipient must or must not change the order type in case of a stop order being triggered. This goes all the way to the core of the matching engine that does it one way or another.
The TriggerInstruction component block is an explicit request to change the order type and is thus more obvious. It is much less obvious for “legacy” FIX systems with FIX 4.2 or 4.4 and should there be left to bilateral agreement in my view.
Does FPL/GTC have a view as to what the best practice is? Should the
order type be changed when stop orders (and other such contingent
orders) are triggered? Or, as there may not be a consensus, is this a
matter that FPL/GTC feel should be left for the parties to agree on in
the rules of engagement?