[This message was posted by Lalin Dias of Millennium Information Technologies <la...@millenniumit.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/eda36f23 - PLEASE DO NOT REPLY BY MAIL.]
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. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
