Imported from previous forum
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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON - effectively ignoring the ExecInst?
- Should the TimeInForce=IOC behavior be modified to act as a TimeInForce=FOK behavior because the ExecInst=AON is specified?
- 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.
I see this combination TimeInForce 59=3 Immediate or Cancel and ExecInst 18 = G All or None as a perfectly valid combination to mean
Either Immediately Execute the Full Quantity
or Cancel it Fully Immediately
The buy side wants a Full Execution now or a Full Cancel now.
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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON -
effectively ignoring the ExecInst?- Should the TimeInForce=IOC behavior be modified to act as a
TimeInForce=FOK behavior because the ExecInst=AON is specified?- 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.
I do not see the difference between your description and the TimeInForce value 4 = Fill or Kill (FOK). I do not see IOC as a sub-qualifier of AON.
I see this combination TimeInForce 59=3 Immediate or Cancel and ExecInst
18 = G All or None as a perfectly valid combination to meanEither Immediately Execute the Full Quantity or Cancel it Fully
ImmediatelyThe buy side wants a Full Execution now or a Full Cancel now.
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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON -
effectively ignoring the ExecInst?- Should the TimeInForce=IOC behavior be modified to act as a
TimeInForce=FOK behavior because the ExecInst=AON is specified?- 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.
[ original email was from John Harris - john.harris@bondmart.com ]
The order you describe is self-contradictory. The most sensible practice would be to reject it.
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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON -
effectively ignoring the ExecInst?- Should the TimeInForce=IOC behavior be modified to act as a
TimeInForce=FOK behavior because the ExecInst=AON is specified?- 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.
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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON -
effectively ignoring the ExecInst?- Should the TimeInForce=IOC behavior be modified to act as a
TimeInForce=FOK behavior because the ExecInst=AON is specified?- 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.
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 ( Dimensional analysis - Wikipedia ). 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).
- Should the order be rejected due to incompatible attributes?
- Should the TimeInForce=IOC take precedence over the ExecInst=AON -
effectively ignoring the ExecInst?- Should the TimeInForce=IOC behavior be modified to act as a
TimeInForce=FOK behavior because the ExecInst=AON is specified?- 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.
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 (
Dimensional analysis - Wikipedia ). 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 callDifferent 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 18A (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 dimensionJ (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 failureL (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.
[ original email was from Jeffrey Croft - jeff.croft@plusmarketsgroup.com ]
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 (
Dimensional analysis - Wikipedia ). 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 callDifferent 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 18A (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 dimensionJ (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 failureL (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 agree FIX is not free from ambiguities, but we should try to disambiguate as many ambiguities as possible.
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 (
Dimensional analysis - Wikipedia ). 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 callDifferent 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 18A (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 dimensionJ (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 failureL (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.