¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 ¿ªÔÆÌåÓý
  1. Twsapi
  2. Topics

Could this happen: stp and trail in oca group both getting triggered?

 

Hello all,

Just minutes ago, something strange happened in my algo trading. My algo always submits orders as an oca order. Parent being a limit order, connected are 3 child orders: stp, trail and mkt with time control. The trail is set much wider than the stp but I want to limit the max loss with the fixed stp.

In the call back after placing the MNQ order, size 1, I can clearly see all the order id's being used, all child orders in the same oca group. Everything perfect as expected and I am positioned +1 MNQ. The positions goes green, and the trail is going along.

At some point the stp and trail are at the same level. Then price drops and hits that level. You would expect that either of the two (stp or trail) to get executed and not the others. But afterwards I am left with -1 MNQ position. In the logging I see callbacks for executed orders for both the stp and trail causing a double closing sell. Again, all the order id's match with the initial orders as part of the same parent.

Is this behavior to be expected when using both a stp and trail in the same oca group and are at the same price level? If so, my algo should probably change stp level as soon as trail gets to the same level. Or remove it from the oca group (if that's possible).

Thanks in advance for sharing your insights and own experience, greetings,

Raoul
 

We just had a different post where OCA overfill protection was discussed, Raoul. When you create the OCA group, do you set the attribute for each order or do you let IBKR use a default?

Chances are, that your OCA was of type 3 (see table at the bottom of the chapter) which does not protect against overfill. So you might need to set ocaType 1 or type 2 for your orders explicitly.

´³¨¹°ù²µ±ð²Ô


On Mon, Aug 21, 2023 at 10:51 AM, Raoul Suurmeijer wrote:
Hello all,
?
Just minutes ago, something strange happened in my algo trading. My algo always submits orders as an oca order. Parent being a limit order, connected are 3 child orders: stp, trail and mkt with time control. The trail is set much wider than the stp but I want to limit the max loss with the fixed stp.
?
In the call back after placing the MNQ order, size 1, I can clearly see all the order id's being used, all child orders in the same oca group. Everything perfect as expected and I am positioned +1 MNQ. The positions goes green, and the trail is going along.
?
At some point the stp and trail are at the same level. Then price drops and hits that level. You would expect that either of the two (stp or trail) to get executed and not the others. But afterwards I am left with -1 MNQ position. In the logging I see callbacks for executed orders for both the stp and trail causing a double closing sell. Again, all the order id's match with the initial orders as part of the same parent.
?
Is this behavior to be expected when using both a stp and trail in the same oca group and are at the same price level? If so, my algo should probably change stp level as soon as trail gets to the same level. Or remove it from the oca group (if that's possible).
?
Thanks in advance for sharing your insights and own experience, greetings,
?
Raoul
?
?
?
 

I think it is not guaranteed even with the block option of the ocatype flag. It can execute two orders of the OCA at the exact same time. Check? ?

"Please note that because the OCA procedure is an automated process, there is no guarantee that requested cancellations and modifications will reach the specific exchange before an order has been executed."

El lun, 21 ago 2023 a las 18:11, ´³¨¹°ù²µ±ð²Ô Reinold via (<TwsApiOnGroupsIo=[email protected]>) escribi¨®:

We just had a different post where OCA overfill protection was discussed, Raoul. When you create the OCA group, do you set the attribute for each order or do you let IBKR use a default?

Chances are, that your OCA was of type 3 (see table at the bottom of the chapter) which does not protect against overfill. So you might need to set ocaType 1 or type 2 for your orders explicitly.

´³¨¹°ù²µ±ð²Ô

On Mon, Aug 21, 2023 at 10:51 AM, Raoul Suurmeijer wrote:
Hello all,
?
Just minutes ago, something strange happened in my algo trading. My algo always submits orders as an oca order. Parent being a limit order, connected are 3 child orders: stp, trail and mkt with time control. The trail is set much wider than the stp but I want to limit the max loss with the fixed stp.
?
In the call back after placing the MNQ order, size 1, I can clearly see all the order id's being used, all child orders in the same oca group. Everything perfect as expected and I am positioned +1 MNQ. The positions goes green, and the trail is going along.
?
At some point the stp and trail are at the same level. Then price drops and hits that level. You would expect that either of the two (stp or trail) to get executed and not the others. But afterwards I am left with -1 MNQ position. In the logging I see callbacks for executed orders for both the stp and trail causing a double closing sell. Again, all the order id's match with the initial orders as part of the same parent.
?
Is this behavior to be expected when using both a stp and trail in the same oca group and are at the same price level? If so, my algo should probably change stp level as soon as trail gets to the same level. Or remove it from the oca group (if that's possible).
?
Thanks in advance for sharing your insights and own experience, greetings,
?
Raoul
?
?
?
 

what i recall, the blocking causes that only one order from the oca group is really submitted to the target market to be sure the overfill protection will work. it can be verified by color coding of the orders in tws.
 

In this case it could work but then what's the point of using oca group if just one order of the group is sent?


El lun, 21 ago 2023 a las 18:58, fordfrog via (<fordfrog=[email protected]>) escribi¨®:
what i recall, the blocking causes that only one order from the oca group is really submitted to the target market to be sure the overfill protection will work. it can be verified by color coding of the orders in tws.

 

if i get it right, only one order is active at the target market, but ib monitors the other orders and activates the one when its rule is triggered and deactivates the one that was active so far.
 

Thats is great information again ´³¨¹°ù²µ±ð²Ô! I remember the post you are referring but I never really paid attention or understood the risc of overfilling, assuming the default behavior of oca would be sufficient.?

Thanks again, and will certainly add this OcaType to my oca orders. Probably setting it to 1.

Thanks again for your much appreciated help, greetings,
Raoul.

On Mon, Aug 21, 2023, 18:11 ´³¨¹°ù²µ±ð²Ô Reinold via <TwsApiOnGroupsIo=[email protected]> wrote:
We just had a different post where OCA overfill protection was discussed, Raoul. When you create the OCA group, do you set the attribute for each order or do you let IBKR use a default?

Chances are, that your OCA was of type 3 (see table at the bottom of the chapter) which does not protect against overfill. So you might need to set ocaType 1 or type 2 for your orders explicitly.

´³¨¹°ù²µ±ð²Ô

On Mon, Aug 21, 2023 at 10:51 AM, Raoul Suurmeijer wrote:
Hello all,
?
Just minutes ago, something strange happened in my algo trading. My algo always submits orders as an oca order. Parent being a limit order, connected are 3 child orders: stp, trail and mkt with time control. The trail is set much wider than the stp but I want to limit the max loss with the fixed stp.
?
In the call back after placing the MNQ order, size 1, I can clearly see all the order id's being used, all child orders in the same oca group. Everything perfect as expected and I am positioned +1 MNQ. The positions goes green, and the trail is going along.
?
At some point the stp and trail are at the same level. Then price drops and hits that level. You would expect that either of the two (stp or trail) to get executed and not the others. But afterwards I am left with -1 MNQ position. In the logging I see callbacks for executed orders for both the stp and trail causing a double closing sell. Again, all the order id's match with the initial orders as part of the same parent.
?
Is this behavior to be expected when using both a stp and trail in the same oca group and are at the same price level? If so, my algo should probably change stp level as soon as trail gets to the same level. Or remove it from the oca group (if that's possible).
?
Thanks in advance for sharing your insights and own experience, greetings,
?
Raoul
?
?
?

1 - 7 of 7