IB API getting fills before order confirmations

slickpick · Oct 14, 2013

I may be missing something here, so hopefully somewhere here could point me in the right direction. Currently, I'm working with the Java API for IB.

I've overrided orderStatus and pass status variable into a switch statement which then will call some particular method. Now as I understand it, 'Submitted' with a filled size of 0 means that the exchange has accepted the order.

The issue is, I'm receiving executions before orderStatus comes in. Is this typical behavior? If so are there any other ways to verify if an order has been received by the exchange or not other than orderStatus? The same issue comes up for with cancelled orders as well.

TIA

rwk · Oct 14, 2013

Quote from slickpick:
... I'm receiving executions before orderStatus comes in....

Do you mean that the exec message appears ahead of the status message in the socket, or is there a delay between the two? How long a delay?

The status, execution, and portfolio updates should all happen at about the same time. But time here is wall-clock time, not milliseconds. If you're doing HFT, you will have these kinds of problems with the TWSAPI.

slickpick · Oct 14, 2013

Quote from rwk:

Do you mean that the exec message appears ahead of the status message in the socket, or is there a delay between the two? How long a delay?

The status, execution, and portfolio updates should all happen at about the same time. But time here is wall-clock time, not milliseconds. If you're doing HFT, you will have these kinds of problems with the TWSAPI.

I've overrided execDetails to create a Fill object which is then passed into onFill and doOnFill methods. I'm tracking order states which doOnFill will update as well as orderStatus. For my doOnFill logic, it will either push out new orders or replace old ones.

Basically orderStatus isn't updating my order states quickly enough and I'm sending orders orders out of doOnFill logic even before previous orders have been confirmed. I haven't measured the time lag but I suspect it's within milliseconds.

Do you know if their FIX implementation has this issue?

rwk · Oct 14, 2013

I haven't used the FIX implementation.

Messages received through the API (and likely through FIX as well) are necessarily serial. Two or more events can happen very close together, and their reporting sequence is usually undefined (or should be). I think you're going to have to introduce a short delay when responding to a fill report before sending additional orders. I don't think FIX or a lower-latency feed will help.

trademeisters · Oct 14, 2013

actually IB has a known "feature" where you can get a fill ack either before or instead of an order acknowledgement. if the fill happens quickly enough they don't bother sending an order ack, although you can also see fill acks preceed order acks.

fyi....tradelink's ib connnector is good for this cause it normalizes this in IB so it performs more like other brokers in this respect.

slickpick · Oct 15, 2013

I finally narrowed down the issue and will post my findings for anyone who may run into this issue in the future.

In order to get a full view on execution, you have to look at orderStatus, execDetails, and errors.

Assuming you submit a limit order, you should get back an orderStatus with status 'Submitted' and filled = 0 acknowledging the order. However, if the limit order is filled within a certain time frame (I have no idea what that timeframe is? My safe guess is under 500mS) then you'll never get a 'Submitted' status, you'll only receive execDetails and status 'Filled'. So more or less what trademeisters said.

Why they implemented it like this is beyond me...

gmst · Oct 15, 2013

Quote from slickpick:

Why they implemented it like this is beyond me...

Folks at IB please respond. We are waiting to hear the logic behind this implementation. Thanks

trademeisters · Oct 15, 2013

as far as i have ever gathered it's simply that it's easier for them to do this way.

If this is a market order, then it is feasible that the server would send the "filled" status rather than "submitted" since the order was executed immediately.

Regards,
Raymund
IB API Support

slickpick · Oct 15, 2013

Quote from gmst:

Folks at IB please respond. We are waiting to hear the logic behind this implementation. Thanks

Here's my uneducated guess as to why they implemented a lot of the stuff the way they did in such an unintelligible fashion.

It seems like to me the API was put together for building out a GUI based trading platform rather than automated trading in mind. This explains some of the AWESOME decisions they made like separating tickPrice from tickSize (do they match up? nobody knows...). I mean if you're building a GUI who needs order acknowledgements for market orders or marketable limit orders right?

rwk · Oct 15, 2013

Quote from slickpick:
... AWESOME decisions they made like separating tickPrice from tickSize (do they match up? nobody knows...)...

Are you aware that there is a single transaction type that has both price and size? Check out RTVolume.