IB Handling of Cancel Order, Does it make sense??

X

xbaha

Hi
I am trying to see what logic IB has for their OCA orders, and please let me know if this logic is correct or not ..

when i create an OCA order (parent + child), then after a while i want to cancel the OCA order, this is what happens in the below order:

1. IB cancel all attached (child) orders in the OCA group.
2. IB send a cancellation order the the exchange for the parent order.

wait a minute, does this mean that there is a possibility that IB can not cancel the parent order (if it has been filled already), while it has already canceled all the OCA child orders?

unfortunately, it's true, which makes it impossible to use OCA for HFT..

let me know if such logic is right? shouldn't it seek the cancel in the exchange first, then cancel the OCA attached orders whom are still in the IB server (guaranteed to be canceled) ???

Thanks for any reply.
 
Where parts of your bracket order reside depends on what exchange you are trading on. With some exchanges your stop order has to reside with the broker. That may complicate your analysis a little. Also, things are asynchronous, if IB cancels your broker resident order at the moment your exchange resident order gets filled they did their best. If you are automated you have to have error handling routines and if you are trading manually you have to watch the order status. Having said that, the chatter is that lots of people have problems with IB and their OCO/OCA orders via the API. I don't have any direct negative experience with that but some claim to. Personally I think that it may be related to the idea that IB has two sets of symbols for everything and people get crossed up by using symbols from the wrong set.
 
Quote from Eight:

Where parts of your bracket order reside depends on what exchange you are trading on. With some exchanges your stop order has to reside with the broker. That may complicate your analysis a little. Also, things are asynchronous, if IB cancels your broker resident order at the moment your exchange resident order gets filled they did their best. If you are automated you have to have error handling routines and if you are trading manually you have to watch the order status. Having said that, the chatter is that lots of people have problems with IB and their OCO/OCA orders via the API. I don't have any direct negative experience with that but some claim to. Personally I think that it may be related to the idea that IB has two sets of symbols for everything and people get crossed up by using symbols from the wrong set.
More...

but if the stop order resides with my broker, isn't it more logical. and error free, that the broker should FIRST cancel the order in the exchange before canceling my stop order?
why should i use OCA if i still have to have error handling for bracket orders?? otherwise i could use single orders where nothing resides with my broker???!!!
API has no problems, it's just the logic for the OCA orders is what i feel is wrong...
 
I haven't had any problem with OCA orders as well. Where the orders reside is beside the point. If one is executed, the others are cancelled. There's the remote possibility that multiple orders will be executed simultaneously but that's the risk you taken with this type of order.
 
Quote from xbaha:

but if the stop order resides with my broker, isn't it more logical. and error free, that the broker should FIRST cancel the order in the exchange before canceling my stop order?
More...

and what will you do if they cancel the order with the exchange and a moment later your stop gets filled? You will have a position the opposite direction from what you wanted and no stop in place.
 
Quote from Eight:

and what will you do if they cancel the order with the exchange and a moment later your stop gets filled? You will have a position the opposite direction from what you wanted and no stop in place.
More...

dude, CHILD orders reside on the IB servers, they are ONLY sent after you get a fill !
if they cancel the order on the exchange, your stop is guaranteed to be canceled !
 
Quote from Hurricane:

I haven't had any problem with OCA orders as well. Where the orders reside is beside the point. If one is executed, the others are cancelled. There's the remote possibility that multiple orders will be executed simultaneously but that's the risk you taken with this type of order.
More...

if you use large time frames (3min or more) chances you will never see what i am talking about.

if you send orders and cancel them within 15 seconds, you will see what is the problem..
 
Quote from xbaha:

dude, CHILD orders reside on the IB servers, they are ONLY sent after you get a fill !
if they cancel the order on the exchange, your stop is guaranteed to be canceled !
More...

soooo... did you answer your own question or something? I've not understood what your concern was in the first place... there just is an inescapable asynchronous nature to the market events and your broker's events and your automated events. Try flowcharting everything using different colors for each possible source of an event.
 
Quote from xbaha:

Hi
I am trying to see what logic IB has for their OCA orders...
unfortunately, it's true, which makes it impossible to use OCA for HFT..
More...

You're trying to use IB for HFT?

Seriously?
 
Most likely they under-promise in the informal descriptions and in reality are fine-tuning the actual code and arrangements to ensure that unwanted fills do not take place.

They are unlikely to describe exactly how the code works because they need to fine-tune it on an ongoing basis.

Even though they say for formal purposes that there is a remote chance that you might get an unwanted fill, they may actually have covered this case internally; for example, by just offsetting the extra fill if it does occur and "eating the loss" (which should normally be small) themselves. This should work unless the market closes unexpectedly or some such.

In other words, has anyone ever actually gotten an extra fill from an OCA order that should have been cancelled after the first fill occurred?
 
You must log in or register to reply here.
Back
Top