[This message was posted by Mahesh Kumaraguru of <[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/63764adc - PLEASE DO NOT REPLY BY MAIL.]
Hanno, I think there is a Gap. IOC is a Time descriptor and AON is a Execution Quantity descriptor and I see these as two different dimensions ( http://en.wikipedia.org/wiki/Dimensional_analysis ). For example I see Price and Quantity as two independent dimensions in FIX. Effectinely TimeInForce = IOC + ExecInstruction = AON becomes TimeInForce 59 = 4 FillOrKill (though this not written anywhere in the FIX Specs). Asking the sender may not be an option in high freqency Algorithmic trading systems where automated Algorithims have placed this trade (a voice Robot may answer the call :-( Different values in ExecInst 18 belong to different dimensions. Since this field can contain multiple instructions separated by space, values from different dimensions may coexist under the mutually exclusive rule within the same dimension, but I believe some should be seperated into new FIXTags or removed from 18 and merged into existing FIXTags. For example, values of 18 A (No cross) and B (OK to cross) describe whether a Cross is permitted D (Percent of volume), E (Do not increase), F (Do not reduce), G (All or none) describe behaviour of the Quantity dimension J (Reinstate on Trading Halt), K (Cancel on Trading Halt), m (Suspend on Trading Halt) describe what to do in the event of Trading halt. H (Reinstate on system failure), Q (Cancel on system failure) and l (Suspend on system failure) describe what to do in the event of System failure L (Last peg), M (Mid-price peg), O (Opening peg), P (Market peg), R (Primary peg), W (Peg to VWAP), d (Peg to Limit Price) decsribe the Price Peg type. g (External Routing Allowed) and h (External Routing Not Allowed) describe External Routing permission. S (Suspend) and q (Release from suspension) describe the Suspend / Unsuspend behavior. (The above values are not a complete list but indicative of the Gap I am analysing) Since ExecInst 18 is used different MessageTypes, we could do a Gap analysis to see how the different values can be refactored for new FIX.Version or Service pack. But for the sake of older versions, we should try to document a matrix of ExecInst values for different message types and the expected behaviour when some other field like TimeInForce contains a specific value. > I would opt for a rejection due to incompatibility as IOC orders cannot > rest on the book whereas AON orders can. This can only be resolved by > creating a mixed interpretation between the two. > > Instead of trying to interpret what IOC+AON could mean, I would go back > to the sender and ask him what he is trying to convey in business terms. > Either this can be mapped to existing FIX tags and valid values or we > have a gap for which an extension of the spec might be useful. > > > Is there a standard or recommended practice when an order has > > TimeInForce(tag 59)=3 Immediate or Cancel (IOC) and ExecInst(tag 18)=G > > All or none (AON) in an exchange/ECN/ATS environment. Immediate Or > > Cancel behavior is to fill what can be filled on the order and cancel > > any unfilled portion. ExecInst=AON means the order must be fill > > completely or cancelled (but the order can rest in the book - as > > opposed to a Fill Or Kill order where the order must be fully filled > > or canceled without resting in the book). > > 1. Should the order be rejected due to incompatible attributes? > > 2. Should the TimeInForce=IOC take precedence over the ExecInst=AON - > > effectively ignoring the ExecInst? > > 3. Should the TimeInForce=IOC behavior be modified to act as a > > TimeInForce=FOK behavior because the ExecInst=AON is specified? > > 4. Some other alternative I haven't thought of? > > > > It doesn't seem to me that the ExecInst=AON should override the > > TimeInForce instruction - meaning the order should not be allowed to > > sit in the book. [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 -~----------~----~----~----~------~----~------~--~---
