Imported from previous forum
An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?
What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.
An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
[ original email was from John Harris - john.harris@bondmart.com ]
Hmmm…how did the implicit notion of a “multiple fill” FOK order sneak into the protocol? I regret not paying attention when the opportunity to kill this bad idea in the cradle first arose, but this notion really should be deprecated.
An FOK (“fill or kill”) order is by definition “all or none” (“AON”) It is a perfect synonym for an immediate or cancel (IOC) order with an AON flag. In simpler terms: FOK = IOC + AON.
If a matching engine (or human specialist) is capable of aggregating multiple contra orders in such a way that that an FOK order can be filled immediately and completely, in a single execution with respect to the FOK order (e.g., because a central counterparty novates the multiple contras), then the meaning of an FOK order has been honored. Otherwise…not.
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
John, I believe we are on the same page here. FOK is about eliminating execution risk for the order submitter. Either everything gets filled immediately or nothing at all. AON is a little less strict as it removes the need for immediacy. The matching engine might have multiple orders sitting on the book that allow to satisfy the incoming order but only if taken together. The match event will be a single transaction but it might have multiple match steps, possibly even at different prices. In case of a single price and a central counterparty, the order submitter would not even know that his order was filled against more than one other order.
We use the or the upcoming to send a siingle message representing the single match event to the order submitter to avoid sending any intermediate states that never existed from the viewpoint of the matching engine. This is one of the drawbacks of FIX 4.x where you have to send individual ExecutionReports and you might try to modify or cancel an order after receiving the first partial fill whereby the matching engine has completely filled the order in a single transaction against multiple orders but needs to send multiple FIX messages to convey this. Best case is that you get “too late to cancel” but exchanges might also respond with “order not found in book” if (for performance reasons) the core system does not keep track of orders that have reached a terminal state (filled, expired, cancelled).
With FIX 5 it is possible to align transaction models with the core system. OrdStatus, CumQty and LeavesQty tell you immediately what is left of the order and or give you something like an audit trail of what happened in between.
Regards,
Hanno.
Hmmm…how did the implicit notion of a “multiple fill” FOK order sneak into the protocol? I regret not paying attention when the opportunity to kill this bad idea in the cradle first arose, but this notion really should be deprecated.
An FOK (“fill or kill”) order is by definition “all or none” (“AON”) It is a perfect synonym for an immediate or cancel (IOC) order with an AON flag. In simpler terms: FOK = IOC + AON.
If a matching engine (or human specialist) is capable of aggregating multiple contra orders in such a way that that an FOK order can be filled immediately and completely, in a single execution with respect to the FOK order (e.g., because a central counterparty novates the multiple contras), then the meaning of an FOK order has been honored. Otherwise…not.
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Hanno. Yes, I believe we are in sync on the meaning of an FOK order and I would agree that multiple orders resting in an order book may be used to satisfy an FOK order, without compromising the meaning or purpose of an FOK order, though the devil is in the details of how those multiple contra orders are aggregated for FOK order-execution purposes.
But, I remain concerned about the use case implicit in the protocol implementation and whether the protocol in fact allows or encourages abrogation of an FOK instruction. To the extent is purely informational, e.g, “We aggregated these orders to satisfy your FOK order,” no problem arises as far as that goes. I do question whether a business case actually exists for sharing such information with the maker of an FOK order, but let’s leave that aside.
On the other hand, to the extent (i) any of the components of represent a unique risk to the maker of the FOK order or (ii) any of the components of are assembled in other than a single, atomic transaction, then such a fill is inconsistent with the terms of the FOK order on the other side of the trade (at least as far as the common understanding of “FOK” is concerned).
Do you concur?
John, I believe we are on the same page here. FOK is about eliminating execution risk for the order submitter. Either everything gets filled immediately or nothing at all. AON is a little less strict as it removes the need for immediacy. The matching engine might have multiple orders sitting on the book that allow to satisfy the incoming order but only if taken together. The match event will be a single transaction but it might have multiple match steps, possibly even at different prices. In case of a single price and a central counterparty, the order submitter would not even know that his order was filled against more than one other order.
We use the or the upcoming to send a siingle message representing the single match event to the order submitter to avoid sending any intermediate states that never existed from the viewpoint of the matching engine. This is one of the drawbacks of FIX 4.x where you have to send individual ExecutionReports and you might try to modify or cancel an order after receiving the first partial fill whereby the matching engine has completely filled the order in a single transaction against multiple orders but needs to send multiple FIX messages to convey this. Best case is that you get “too late to cancel” but exchanges might also respond with “order not found in book” if (for performance reasons) the core system does not keep track of orders that have reached a terminal state (filled, expired, cancelled).
With FIX 5 it is possible to align transaction models with the core system. OrdStatus, CumQty and LeavesQty tell you immediately what is left of the order and or give you something like an audit trail of what happened in between.Regards,
Hanno.Hmmm…how did the implicit notion of a “multiple fill” FOK order sneak into the protocol? I regret not paying attention when the opportunity to kill this bad idea in the cradle first arose, but this notion really should be deprecated.
An FOK (“fill or kill”) order is by definition “all or none” (“AON”) It is a perfect synonym for an immediate or cancel (IOC) order with an AON flag. In simpler terms: FOK = IOC + AON.
If a matching engine (or human specialist) is capable of aggregating multiple contra orders in such a way that that an FOK order can be filled immediately and completely, in a single execution with respect to the FOK order (e.g., because a central counterparty novates the multiple contras), then the meaning of an FOK order has been honored. Otherwise…not.
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
Thanks alot Hanno,
But I want to make sure that the incoming order with this new TIF should get fully exeuted against a single order sitting in the order book, but not against a single price level(which may have multiple orders)and the order will be expired if the above criteria are not met.The whole purpose is to generate a single execution report by the matching engine for the trader who sends the “single fill FOK order”.
Thank you, Hanno. Yes, I believe we are in sync on the meaning of an FOK order and I would agree that multiple orders resting in an order book may be used to satisfy an FOK order, without compromising the meaning or purpose of an FOK order, though the devil is in the details of how those multiple contra orders are aggregated for FOK order-execution purposes.
But, I remain concerned about the use case implicit in the protocol implementation and whether the protocol in fact allows or encourages abrogation of an FOK instruction. To the extent is purely informational, e.g, “We aggregated these orders to satisfy your FOK order,” no problem arises as far as that goes. I do question whether a business case actually exists for sharing such information with the maker of an FOK order, but let’s leave that aside.
On the other hand, to the extent (i) any of the components of represent a unique risk to the maker of the FOK order or (ii) any of the components of are assembled in other than a single, atomic transaction, then such a fill is inconsistent with the terms of the FOK order on the other side of the trade (at least as far as the common understanding of “FOK” is concerned).
Do you concur?
John, I believe we are on the same page here. FOK is about eliminating execution risk for the order submitter. Either everything gets filled immediately or nothing at all. AON is a little less strict as it removes the need for immediacy. The matching engine might have multiple orders sitting on the book that allow to satisfy the incoming order but only if taken together. The match event will be a single transaction but it might have multiple match steps, possibly even at different prices. In case of a single price and a central counterparty, the order submitter would not even know that his order was filled against more than one other order.
We use the or the upcoming to send a siingle message representing the single match event to the order submitter to avoid sending any intermediate states that never existed from the viewpoint of the matching engine. This is one of the drawbacks of FIX 4.x where you have to send individual ExecutionReports and you might try to modify or cancel an order after receiving the first partial fill whereby the matching engine has completely filled the order in a single transaction against multiple orders but needs to send multiple FIX messages to convey this. Best case is that you get “too late to cancel” but exchanges might also respond with “order not found in book” if (for performance reasons) the core system does not keep track of orders that have reached a terminal state (filled, expired, cancelled).
With FIX 5 it is possible to align transaction models with the core system. OrdStatus, CumQty and LeavesQty tell you immediately what is left of the order and or give you something like an audit trail of what happened in between.Regards,
Hanno.Hmmm…how did the implicit notion of a “multiple fill” FOK order sneak into the protocol? I regret not paying attention when the opportunity to kill this bad idea in the cradle first arose, but this notion really should be deprecated.
An FOK (“fill or kill”) order is by definition “all or none” (“AON”) It is a perfect synonym for an immediate or cancel (IOC) order with an AON flag. In simpler terms: FOK = IOC + AON.
If a matching engine (or human specialist) is capable of aggregating multiple contra orders in such a way that that an FOK order can be filled immediately and completely, in a single execution with respect to the FOK order (e.g., because a central counterparty novates the multiple contras), then the meaning of an FOK order has been honored. Otherwise…not.
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
One option is to use the approved new field structure for this purpose.
You’d need to:
- add a new enum eg “3=fully match against single order only” to MatchInst
OR - use MatchInst = 1 (Match), against MatchAttribTagID=73(NoOrders) & MatchAttribValue=1(one order)
cheers
Aaron.
Thanks alot Hanno,
But I want to make sure that the incoming order with this new TIF should get fully exeuted against a single order sitting in the order book, but not against a single price level(which may have multiple orders)and the order will be expired if the above criteria are not met.The whole purpose is to generate a single execution report by the matching engine for the trader who sends the “single fill FOK order”.Thank you, Hanno. Yes, I believe we are in sync on the meaning of an FOK order and I would agree that multiple orders resting in an order book may be used to satisfy an FOK order, without compromising the meaning or purpose of an FOK order, though the devil is in the details of how those multiple contra orders are aggregated for FOK order-execution purposes.
But, I remain concerned about the use case implicit in the protocol implementation and whether the protocol in fact allows or encourages abrogation of an FOK instruction. To the extent is purely informational, e.g, “We aggregated these orders to satisfy your FOK order,” no problem arises as far as that goes. I do question whether a business case actually exists for sharing such information with the maker of an FOK order, but let’s leave that aside.
On the other hand, to the extent (i) any of the components of represent a unique risk to the maker of the FOK order or (ii) any of the components of are assembled in other than a single, atomic transaction, then such a fill is inconsistent with the terms of the FOK order on the other side of the trade (at least as far as the common understanding of “FOK” is concerned).
Do you concur?
John, I believe we are on the same page here. FOK is about eliminating execution risk for the order submitter. Either everything gets filled immediately or nothing at all. AON is a little less strict as it removes the need for immediacy. The matching engine might have multiple orders sitting on the book that allow to satisfy the incoming order but only if taken together. The match event will be a single transaction but it might have multiple match steps, possibly even at different prices. In case of a single price and a central counterparty, the order submitter would not even know that his order was filled against more than one other order.
We use the or the upcoming to send a siingle message representing the single match event to the order submitter to avoid sending any intermediate states that never existed from the viewpoint of the matching engine. This is one of the drawbacks of FIX 4.x where you have to send individual ExecutionReports and you might try to modify or cancel an order after receiving the first partial fill whereby the matching engine has completely filled the order in a single transaction against multiple orders but needs to send multiple FIX messages to convey this. Best case is that you get “too late to cancel” but exchanges might also respond with “order not found in book” if (for performance reasons) the core system does not keep track of orders that have reached a terminal state (filled, expired, cancelled).
With FIX 5 it is possible to align transaction models with the core system. OrdStatus, CumQty and LeavesQty tell you immediately what is left of the order and or give you something like an audit trail of what happened in between.Regards,
Hanno.Hmmm…how did the implicit notion of a “multiple fill” FOK order sneak into the protocol? I regret not paying attention when the opportunity to kill this bad idea in the cradle first arose, but this notion really should be deprecated.
An FOK (“fill or kill”) order is by definition “all or none” (“AON”) It is a perfect synonym for an immediate or cancel (IOC) order with an AON flag. In simpler terms: FOK = IOC + AON.
If a matching engine (or human specialist) is capable of aggregating multiple contra orders in such a way that that an FOK order can be filled immediately and completely, in a single execution with respect to the FOK order (e.g., because a central counterparty novates the multiple contras), then the meaning of an FOK order has been honored. Otherwise…not.
This depends on your motivation to not get fully executed against multiple orders. If you want to avoid to get matched to multiple prices that get worse as you go down the book, then you can use 1090 MaxPriceLevels=1 to avoid further matches after the first one.
Do you provide counterparty information so that the submitter of the FOK would know whether he matches against multiple orders at the same price level? In general, he would only get a single ExecutionReport with a single price and quantity if MaxPriceLevels=1.
My view in general is that it would be an additional attribute (field) and not another TIF value to cover your case.An incoming order with this new TIF should get fully executed against a single order on the contra side.If the incoming order cannot be fully filled by a single order within the best price point, the order will get expired. its different from normal FOK, where orders can get fully executed against multiple orders on the contra side.
My question is how to implemet this new TIF in FIX.5.0SP2?
Has anybody implemented this before?What would be the best way of implementing the new TIF?
Is it?
1)To develop a custom TIF (with new enum added)?
2)To use existing FOK with a ExecInst ‘j(Single execution requested for block trade)’ ?
3)To use existing FOK with a custom ExecInst?
Aaron,
this takes the component beyond its original intention as “NoOrders” is not used by you to identify a valid value of a field in the order of the (potential) counterparty. In my view this is a slippery slope to use the name of the field to express the desired semantic. In this case it is even more difficult as tag 73 is purely a delimiter for the tag=value syntax and your solution would not work with FIXML as tag 73 does not exist there.
Matching Instructions should allow automated processing, i.e. the matcher simply checks the field(s) of an order he is about to match against an incoming order carrying the instructions and rejects the match or not. This can be programmed once and basically works for any tag of NewOrderSingle or NewOrderMultileg with the exception of the NoXXX fields.
So what is the solution? I still struggle with the benefit of the requirement unless trading is non-anonymous and I have to deal with the counterparties. For example in commodities, I might not want my million barrels of oil to be delivered by two or more ships. I fail to see the benefit in plain vanilla, high-speed trading with a central counterparty where I do not even know that my order was executed against multiple counterparties because the CCP always steps in the middle to novate and represents the one and only counterparty to me. Talking about multiple counterparties in this context seems artificial.
I would suggest to use ExecInst j = “Single execution requested” and ignore the fact that the standard value refers to block trades. It is close enough and can be easily explained in the Rules of Engagement, e.g. “order will be rejected if it cannot be immediately filled against a single order of equal or greater size”.
Regards,
Hanno.
One option is to use the approved new field structure for this purpose.
You’d need to:
- add a new enum eg “3=fully match against single order only” to MatchInst
OR- use MatchInst = 1 (Match), against MatchAttribTagID=73(NoOrders) & MatchAttribValue=1(one order)
cheers
Aaron.
Hanno,
I agree none of the above are the ideal solution, and, there does seem to be a gap in the area of conveying more complicated matching instruction semantics between parties (who may be party ↔ broker which implies a different dynamic to party ↔ exchange) where the matching instruction semantics fall short of algorithms yet are more sophisticated than the existing ordtype, TIF etc semantic combo’s available with vanilla FIX. And I hadn’t thought about the xml implications of my option b) strawman, good point!
cheers
Aaron.
Aaron,
this takes the component beyond its original intention as “NoOrders” is not used by you to identify a valid value of a field in the order of the (potential) counterparty. In my view this is a slippery slope to use the name of the field to express the desired semantic. In this case it is even more difficult as tag 73 is purely a delimiter for the tag=value syntax and your solution would not work with FIXML as tag 73 does not exist there.
Matching Instructions should allow automated processing, i.e. the matcher simply checks the field(s) of an order he is about to match against an incoming order carrying the instructions and rejects the match or not. This can be programmed once and basically works for any tag of NewOrderSingle or NewOrderMultileg with the exception of the NoXXX fields.
So what is the solution? I still struggle with the benefit of the requirement unless trading is non-anonymous and I have to deal with the counterparties. For example in commodities, I might not want my million barrels of oil to be delivered by two or more ships. I fail to see the benefit in plain vanilla, high-speed trading with a central counterparty where I do not even know that my order was executed against multiple counterparties because the CCP always steps in the middle to novate and represents the one and only counterparty to me. Talking about multiple counterparties in this context seems artificial.
I would suggest to use ExecInst j = “Single execution requested” and ignore the fact that the standard value refers to block trades. It is close enough and can be easily explained in the Rules of Engagement, e.g. “order will be rejected if it cannot be immediately filled against a single order of equal or greater size”.Regards,
Hanno.One option is to use the approved new field structure for this purpose.
You’d need to:
- add a new enum eg “3=fully match against single order only” to MatchInst
OR- use MatchInst = 1 (Match), against MatchAttribTagID=73(NoOrders) & MatchAttribValue=1(one order)
cheers
Aaron.
Yes, John, I concur. FillsGrp could be mis-used to bundle independent executions for the same instrument together. Regardless of FOK being present or not, all executions within FillsGrp must have occurred within a single match event.
However, FillsGrp does not convey information about other orders, it is about partial executions of one’s own order. The intention is to only use this to distinguish multiple executions at different price levels within a single match event. This is important information to the order submitter. Each fill might be the result of a match against more than one order but this information should not be implictly provided within FillsGrp by having multiple instances with the same price. It should simply split up my own match quantity across price levels.
Thank you, Hanno. Yes, I believe we are in sync on the meaning of an FOK order and I would agree that multiple orders resting in an order book may be used to satisfy an FOK order, without compromising the meaning or purpose of an FOK order, though the devil is in the details of how those multiple contra orders are aggregated for FOK order-execution purposes.
But, I remain concerned about the use case implicit in the protocol implementation and whether the protocol in fact allows or encourages abrogation of an FOK instruction. To the extent is purely informational, e.g, “We aggregated these orders to satisfy your FOK order,” no problem arises as far as that goes. I do question whether a business case actually exists for sharing such information with the maker of an FOK order, but let’s leave that aside.
On the other hand, to the extent (i) any of the components of represent a unique risk to the maker of the FOK order or (ii) any of the components of are assembled in other than a single, atomic transaction, then such a fill is inconsistent with the terms of the FOK order on the other side of the trade (at least as far as the common understanding of “FOK” is concerned).
Do you concur?