Imported from previous forum
Have doubt regarding FoK order type. In my view if order is not filled a reject message should be sent by an exchange instead of cancel. Can someone confirm this?
Anirudha
No, rejections are to convey that the requested action was not carried out. A FoK order not being filled does not fall in this category, it is rather “works as designed”. It is not an error to not be filled. The order status goes from New to Cancelled or from New to Filled but not from New to Rejected.
Have doubt regarding FoK order type. In my view if order is not filled a
reject message should be sent by an exchange instead of cancel. Can
someone confirm this?Anirudha
Hanno (or others),
How would you represent a FoK and an IoC order?
No, rejections are to convey that the requested action was not carried out. A FoK order not being filled does not fall in this category, it is rather “works as designed”. It is not an error to not be filled. The order status goes from New to Cancelled or from New to Filled but not from New to Rejected.
Have doubt regarding FoK order type. In my view if order is not filled a
reject message should be sent by an exchange instead of cancel. Can
someone confirm this?Anirudha
Not sure where your question is going. Aaron’s response covers the semantic representation for order entry.
Prior to FIX 5.0 SP1, FOK and IOC always required to send multiple Exeution Reports back, at least 3 in case of a fill(OrdStatus New, (Partially) Filled, Cancelled). Volume 7 “User Group Exchange and Markets” (SP1: page 186 onwards; SP2: 191) then describes an optimized state change diagram and message flows to minimize the number of ERs.
Hanno (or others),
How would you represent a FoK and an IoC order?
No, rejections are to convey that the requested action was not carried out. A FoK order not being filled does not fall in this category, it is rather “works as designed”. It is not an error to not be filled. The order status goes from New to Cancelled or from New to Filled but not from New to Rejected.
Have doubt regarding FoK order type. In my view if order is not filled a
reject message should be sent by an exchange instead of cancel. Can
someone confirm this?Anirudha
Take a look at “Conflict between TimeInForce=IOC and ExecInst=AON” at http://fixprotocol.org/discuss/read/50f25e20
Not sure where your question is going. Aaron’s response covers the semantic representation for order entry.
Prior to FIX 5.0 SP1, FOK and IOC always required to send multiple Exeution Reports back, at least 3 in case of a fill(OrdStatus New, (Partially) Filled, Cancelled). Volume 7 “User Group Exchange and Markets” (SP1: page 186 onwards; SP2: 191) then describes an optimized state change diagram and message flows to minimize the number of ERs.
Hanno (or others),
How would you represent a FoK and an IoC order?
No, rejections are to convey that the requested action was not carried out. A FoK order not being filled does not fall in this category, it is rather “works as designed”. It is not an error to not be filled. The order status goes from New to Cancelled or from New to Filled but not from New to Rejected.
Have doubt regarding FoK order type. In my view if order is not filled a
reject message should be sent by an exchange instead of cancel. Can
someone confirm this?Anirudha