[This message was posted by Jeffrey Croft of Plus Markets Group 
<[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/13776530 - PLEASE DO NOT REPLY BY MAIL.]

We translate FIX into native API. We only use 2 fields in the native API 
message, one to convey duration e.g. Immediate and the other to indicate 
minQty. A combination of these 2 fields gives us either FOK or what we call 
FAK. FAK has been aligned to IOC on the FIX side but essentially the only 
difference is that native users set minfill equal to orderqty to achieve a FOK.
If the user submits us a IOC with minfil but sets tag 18 to 'G' then did they 
mean for a FOK or or an FAK/IOC? Given the setting in 2 out of the 3 fields 
indicates a IOC we could presume IOC but I think the safest thing to do would 
be to reject the order. I don't think this is necessarily putting Business 
logic in the FIX Gateway as this is invalid from a pure FIX layer perspective.

Jeff



> Asking the sender was obviously not meant for a message received in real-
> time during production, it is meant for the process of agreeing on rules
> of engagement during a design or testing process.
> 
> If IOC+AON were the same as FOK, why support two ways to express this?
> FOK is simpler as it only needs a single field. FIX is not free from
> ambiguities, why introduce new ones?
> 
> > 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.
> >


[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
-~----------~----~----~----~------~----~------~--~---

Reply via email to