[This message was posted by Greg Wood of Credit Suisse <[email protected]> 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/f56cdacf - PLEASE DO NOT REPLY BY MAIL.]
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:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
