Advanced OCO/Bracket Orders

Read before posting.
orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Advanced OCO/Bracket Orders

Postby orion » 18 Jan 2015

I would like to understand the OCO concept better and how it pertains to Interactive Brokers in particular. I understand that MC 9.1 will allow for explicit OCOs in PL code but since there is no ETA for that and OCOs are currently implicit rather than explicit, I have a few questions on how this works currently:

1. What is an OCO?

The answer seems to be: "All orders from the same calculation belong to an OCO". I understand the obvious setStopLoss and setProfitTarget should belong as an OCO, but the prior answer seems a bit broader since it says "all orders from the same calculation". To clear my confusion, please take following four cases starting with the simplest case (a) where there is only one price order generated in a calculation. Is case (a) also considered an OCO group in MC? The last case (d) is obviously an OCO but for (a), (b), (c), can you indicate which ones are considered OCOs and how many OCOs are generated by MC? Assume 'Optimize Order Flow' (OOF) is off.

(a) // single limit entry order
buy 5 contracts next bar at limitPrice1 limit;

(b) // three scale out orders
sell 5 contracts next bar at limitPrice1 limit;
sell 5 contracts next bar at limitPrice2 limit;
sell 5 contracts next bar at limitPrice3 limit;

(c) // three scale in stop-limit orders
buy 5 contracts next bar at stopPrice1 stop limitPrice1 limit;
buy 5 contracts next bar at stopPrice2 stop limitPrice2 limit;
buy 5 contracts next bar at stopPrice3 stop limitPrice3 limit;

(d) // profit target and stoploss pair
sell 5 contracts at limitPrice1 limit;
sell 5 contracts at stopPrice1 stop;

2. Can you answer how MC packages OCOs for above 4 cases now assuming OOF is on? Does OOF change OCO packaging in any way?

3. IB has two different order types: Bracket order and OCA order. Which one of these does an MC OCO map to?

4. IB allows order modification in its placeOrder() API. Take the modifications corresponding to above 4 cases. Do these result in order modifications using placeOrder() messages or do they result in cancel and replace? Assume OOF is off.
(a) modify limitPrice1 before any fill
(b) modify limitPrice3 before any fill
(c) modify limitPrice3 before any fill
(d) modify stopPrice1 before any fill

5. Can you please answer (4) assuming OOF is on?

6. IB Bracket order would allow all 3 orders below generated in a single calculation to be packaged as children of the bracket. Is this what MC does or does it fire the market order first and then fire the stop and limit pair as OCO when the market order is filled? Please answer this both for OOF on and OOF off.
Buy next bar market;
SetStopLoss(50);
SetProfitTarget(100);

Thanks.

User avatar
Andrew MultiCharts
Posts: 1587
Joined: 11 Oct 2011
Has thanked: 931 times
Been thanked: 559 times

Re: OCO

Postby Andrew MultiCharts » 19 Jan 2015

Hello orion,
(a) // single limit entry order
buy 5 contracts next bar at limitPrice1 limit;
1 order doesn't require OCO group.
(b) // three scale out orders
sell 5 contracts next bar at limitPrice1 limit;
sell 5 contracts next bar at limitPrice2 limit;
sell 5 contracts next bar at limitPrice3 limit;
All 3 orders are places in 1 OCO.
(c) // three scale in stop-limit orders
buy 5 contracts next bar at stopPrice1 stop limitPrice1 limit;
buy 5 contracts next bar at stopPrice2 stop limitPrice2 limit;
buy 5 contracts next bar at stopPrice3 stop limitPrice3 limit;
All 3 orders are places in 1 OCO.
(d) // profit target and stoploss pair
sell 5 contracts at limitPrice1 limit;
sell 5 contracts at stopPrice1 stop;
Both orders are places in 1 OCO.
2. Can you answer how MC packages OCOs for above 4 cases now assuming OOF is on? Does OOF change OCO packaging in any way?
What do you mean by "OFF"?
3. IB has two different order types: Bracket order and OCA order. Which one of these does an MC OCO map to?
If "Bracket" accepts only 2 orders (PT and SL), then this is not what we use. We use OCA_cancel_all and OCA_reduce_size.
4. IB allows order modification in its placeOrder() API. Take the modifications corresponding to above 4 cases. Do these result in order modifications using placeOrder() messages or do they result in cancel and replace? Assume OOF is off.
(a) modify limitPrice1 before any fill
(b) modify limitPrice3 before any fill
(c) modify limitPrice3 before any fill
(d) modify stopPrice1 before any fill
For IB modification of orders is possible without cancelling and replacing the whole OCO group.
5. Can you please answer (4) assuming OOF is on?
Please see my comment for point 2.
6. IB Bracket order would allow all 3 orders below generated in a single calculation to be packaged as children of the bracket. Is this what MC does or does it fire the market order first and then fire the stop and limit pair as OCO when the market order is filled? Please answer this both for OOF on and OOF off.
Buy next bar market;
SetStopLoss(50);
SetProfitTarget(100);
Market orders goes first, then the PT and SL (OCA_reduce_size).

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: OCO

Postby orion » 19 Jan 2015

Andrew, thanks for clarifying. OOF was my shorthand for 'Optimize Order Flow'. So OOF on means 'Optimize Order Flow is checked and OOF off means 'Optimize Order Flow' is unchecked. I want to understand how OCO packaging changes with 'Optimize Order Flow'. Could you please address questions 2 and 5 from last post assuming OOF is on (meaning 'Optimize Order Flow' is checked) and contrast with case when OOF is off (meaning 'Optimize Order Flow' is unchecked)? What is different?

If "Bracket" accepts only 2 orders (PT and SL), then this is not what we use. We use OCA_cancel_all and OCA_reduce_size.
To make sure I am not misunderstanding, IB Bracket allows exactly 3 child orders (the entry and the PT/SL pair). In light of this, you are saying that MC does not use IB Bracket and instead uses IB OCA order for mapping MC OCOs since IB OCA allows unlimited number of children?

6. IB Bracket order would allow all 3 orders below generated in a single calculation to be packaged as children of the bracket. Is this what MC does or does it fire the market order first and then fire the stop and limit pair as OCO when the market order is filled? Please answer this both for OOF on and OOF off.
Buy next bar market;
SetStopLoss(50);
SetProfitTarget(100);
Market orders goes first, then the PT and SL (OCA_reduce_size).
Please allow me to ask this differently since there is possibility of confusion as to sent by whom to whom (sent by MC to IB or sent by IB to market). From my understanding: MC sends the market order to IB first and only after the fill is reported by IB, then the PT/SL pair is sent to IB?


7. You mentioned in response to #4 that IB modification of orders is possible without cancelling and replacing the whole OCO group. I assume that post #9 here no longer applies since that says that a cancel and replace is done on PT/SL pair if script modifies the price?

8. Going through the IB API after your response, I now see the OCA_cancel and OCA_reduce_size you refer to. The 3 limit orders for scale out in case (b) from previous post are part of 1 OCO. The term OCO literally means 'One Cancels Other'. I assume this literal interpretation is not the intended meaning since that would mean that as soon as one of the limit orders is filled, the others get cancelled?


Thanks.

User avatar
Andrew MultiCharts
Posts: 1587
Joined: 11 Oct 2011
Has thanked: 931 times
Been thanked: 559 times

Re: OCO

Postby Andrew MultiCharts » 20 Jan 2015

Andrew, thanks for clarifying. OOF was my shorthand for 'Optimize Order Flow'. So OOF on means 'Optimize Order Flow is checked and OOF off means 'Optimize Order Flow' is unchecked. I want to understand how OCO packaging changes with 'Optimize Order Flow'. Could you please address questions 2 and 5 from last post assuming OOF is on (meaning 'Optimize Order Flow' is checked) and contrast with case when OOF is off (meaning 'Optimize Order Flow' is unchecked)? What is different?
Ok. In my previous post i decribed how it works when OOF = off. Now when OOF = on, please see below:
(a) // single limit entry order
buy 5 contracts next bar at limitPrice1 limit;

(b) // three scale out orders
sell 5 contracts next bar at limitPrice1 limit;
sell 5 contracts next bar at limitPrice2 limit;
sell 5 contracts next bar at limitPrice3 limit;

(c) // three scale in stop-limit orders
buy 5 contracts next bar at stopPrice1 stop limitPrice1 limit;
buy 5 contracts next bar at stopPrice2 stop limitPrice2 limit;
buy 5 contracts next bar at stopPrice3 stop limitPrice3 limit;

(d) // profit target and stoploss pair
sell 5 contracts at limitPrice1 limit;
sell 5 contracts at stopPrice1 stop;
  1. 1 order, no OCO.
  2. 1 order (closest to market), no OCO.
  3. 1 order (closest to market), no OCO.
  4. Both orders are sent in OCO.
2. Can you answer how MC packages OCOs for above 4 cases now assuming OOF is on? Does OOF change OCO packaging in any way?
Optimize Order Flow doesn't affect the OCO groups directly, it affects the number of orders to send.
4. IB allows order modification in its placeOrder() API. Take the modifications corresponding to above 4 cases. Do these result in order modifications using placeOrder() messages or do they result in cancel and replace? Assume OOF is off.
(a) modify limitPrice1 before any fill
(b) modify limitPrice3 before any fill
(c) modify limitPrice3 before any fill
(d) modify stopPrice1 before any fill

5. Can you please answer (4) assuming OOF is on?
If OOF is off, you will have 1 OCO group of 1 stop and 1 limit order, modification for both is possible without OCO cancellation and repalcement.
To make sure I am not misunderstanding, IB Bracket allows exactly 3 child orders (the entry and the PT/SL pair). In light of this, you are saying that MC does not use IB Bracket and instead uses IB OCA order for mapping MC OCOs since IB OCA allows unlimited number of children?
Yes.
Please allow me to ask this differently since there is possibility of confusion as to sent by whom to whom (sent by MC to IB or sent by IB to market). From my understanding: MC sends the market order to IB first and only after the fill is reported by IB, then the PT/SL pair is sent to IB?
Market orders are processed with highest priority anyway, no matter if they are entries or not. If in your exmaple the market order is an entry, the answer is "yes" for sure.
7. You mentioned in response to #4 that IB modification of orders is possible without cancelling and replacing the whole OCO group. I assume that post #9 here no longer applies since that says that a cancel and replace is done on PT/SL pair if script modifies the price?
In that post the logic is general for all other brokers. Ib is the only exception.
8. Going through the IB API after your response, I now see the OCA_cancel and OCA_reduce_size you refer to. The 3 limit orders for scale out in case (b) from previous post are part of 1 OCO. The term OCO literally means 'One Cancels Other'. I assume this literal interpretation is not the intended meaning since that would mean that as soon as one of the limit orders is filled, the others get cancelled?
From my experience OCA = One Cancels Another; OCO = One Cancels Other; so OCO = OCA. It least this is the case for our developers. :-)

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: OCO

Postby orion » 20 Jan 2015

8. Going through the IB API after your response, I now see the OCA_cancel and OCA_reduce_size you refer to. The 3 limit orders for scale out in case (b) from previous post are part of 1 OCO. The term OCO literally means 'One Cancels Other'. I assume this literal interpretation is not the intended meaning since that would mean that as soon as one of the limit orders is filled, the others get cancelled?
From my experience OCA = One Cancels Another; OCO = One Cancels Other; so OCO = OCA. It least this is the case for our developers. :-)
Thank you Andrew. It makes sense. IB is a premier broker and you modeled MC OCO to map on to IB OCA. My appreciation for the MC team has only grown over time! I have two more questions. I apologize for asking too many questions but I need to understand this so that I can decide on the best path since I plan to push MC to its limits.

1. Consider case (b) again with 3 scale out limit orders shown below:
// three scale out orders
sell 5 contracts next bar at limitPrice1 limit;
sell 5 contracts next bar at limitPrice2 limit;
sell 5 contracts next bar at limitPrice3 limit;
You mentioned this is packaged as an OCO with OOF=off and only one order is sent if OOF=on.

1.a. With OOF=off, since this is sent as an IB OCA, I assume you send it as OCA_reduce_size instead of OCA_cancel so that one fill does not cancel the others?

1.b. I also assume MC does a little trickery and sends the OCA with child order sizes (5, 10, 15) instead of (5, 5, 5). So what happens is that on first fill IB automatically reduces the OCA child orders to be (0, 5, 10) since the ocaType field was set to "reduce" rather than "cancel", and on the second fill IB reduces the OCA child orders to be (0, 0, 5) and all of this is accomplished without MC communicating any of the OCA child order modifications thereby not introducing any latency in the process? Is this what is going on?

2. This question does not have to do OCOs but since we are on topic of orders, the comment here caught my eye where it says "there can be a desync between the market position of the strategy and the actual filled position from the broker. The desync is usually caused by orders that are submitted but not filled". I don't understand why there would be desync? Isn't the update sequence as follows:
order fill report from broker ->
marketPosition_at_broker updated ->
marketPosition_at_broker_for_the_strategy updated ->
marketPosition updated
If the order is submitted but not filled, then all 3 positions should be 0? So what is the possible desync we need to be wary of?

Thanks.

User avatar
Andrew MultiCharts
Posts: 1587
Joined: 11 Oct 2011
Has thanked: 931 times
Been thanked: 559 times

Re: OCO

Postby Andrew MultiCharts » 21 Jan 2015

1. Consider case (b) again with 3 scale out limit orders shown below:
// three scale out orders
sell 5 contracts next bar at limitPrice1 limit;
sell 5 contracts next bar at limitPrice2 limit;
sell 5 contracts next bar at limitPrice3 limit;
You mentioned this is packaged as an OCO with OOF=off and only one order is sent if OOF=on.
1.a. With OOF=off, since this is sent as an IB OCA, I assume you send it as OCA_reduce_size instead of OCA_cancel so that one fill does not cancel the others?
It depends. If MC detects the orders are exits, they are sent in OCA_reduce_size. If they are entry orders, OCA_cancel_all is used.
1.b. I also assume MC does a little trickery and sends the OCA with child order sizes (5, 10, 15) instead of (5, 5, 5). So what happens is that on first fill IB automatically reduces the OCA child orders to be (0, 5, 10) since the ocaType field was set to "reduce" rather than "cancel", and on the second fill IB reduces the OCA child orders to be (0, 0, 5) and all of this is accomplished without MC communicating any of the OCA child order modifications thereby not introducing any latency in the process? Is this what is going on?
Should be 5, 5, 5.
2. This question does not have to do OCOs but since we are on topic of orders, the comment here caught my eye where it says "there can be a desync between the market position of the strategy and the actual filled position from the broker. The desync is usually caused by orders that are submitted but not filled". I don't understand why there would be desync? Isn't the update sequence as follows:
order fill report from broker ->
marketPosition_at_broker updated ->
marketPosition_at_broker_for_the_strategy updated ->
marketPosition updated
If the order is submitted but not filled, then all 3 positions should be 0? So what is the possible desync we need to be wary of?
Your assumption is correct again, however there some cases when there is no order fill report from broker (order final status is lost or delayed), while MarketPosition_at_broker is updated and this is where the asynchronization starts.

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: OCO

Postby orion » 21 Jan 2015

Andrew, thank you for all the clarifications. This has been very helpful. I have one remaining question.
1.a. With OOF=off, since this is sent as an IB OCA, I assume you send it as OCA_reduce_size instead of OCA_cancel so that one fill does not cancel the others?
It depends. If MC detects the orders are exits, they are sent in OCA_reduce_size. If they are entry orders, OCA_cancel_all is used.
So exits get a latency benefit since they do not need to be resent but entries have to be resent. Couldn't entries have used OCA_reduce_size as well? Why the different treatment?
Your assumption is correct again, however there some cases when there is no order fill report from broker (order final status is lost or delayed), while MarketPosition_at_broker is updated and this is where the asynchronization starts.
Looking again at the IB API after you wrote this, I see why this can occur. Thank you again for clarifying. With so many moving parts, it is a miracle that auto trading works!

User avatar
Andrew MultiCharts
Posts: 1587
Joined: 11 Oct 2011
Has thanked: 931 times
Been thanked: 559 times

Re: OCO

Postby Andrew MultiCharts » 21 Jan 2015

So exits get a latency benefit since they do not need to be resent but entries have to be resent. Couldn't entries have used OCA_reduce_size as well? Why the different treatment?
Imagine an example:

Market position is flat. Your code generates buy limit 5 contracts @95 and sell limit 5 contracts @100. There would be a mess if it bought 1 contract @95, then moved up to sell 2 contracts @100 and then moved back down to buy another 2 contracts @95. Result: your entry strategy to enter either 5 long, or 5 short would end up +1 long.

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: OCO

Postby orion » 21 Jan 2015

Thanks Andrew. Makes sense. The fact that all this works with multiple datafeeds and multiple brokers while satisfying the needs of such a diversity of traders speaks volumes about the MC team!


Return to “MultiCharts FAQ”