IB Suggestions & Improvements

Discussion in 'Interactive Brokers' started by Babak, Aug 26, 2005.

  1. I got delays -ocassionally- when submitting orders to CME, CBOT and Eurex (ES, ER, YM, ZB, DAX and Bund). I think it started around Aug05.

    It's not related to busy times, e.g. NFP news, but even during very quiet times say 4:00am EST. Since I'm "testing the waters" lately, I'll send a limit away from current price and cancel it a few seconds later, to see if it has any delay.

    In case of problems, orders (limits and cancels of such limits and stops) got executed eventually, but confirmation was too slow (over 5sec, sometimes over 15sec).

    -giving examples here from recent trading- on Thursday 13-Oct-05 11:57 EST, in YM: a stop order would be traded through by several ticks with no immediate action visible in my TWS for several (5+) seconds, then a bit later, the stop gets executed with 1-2ticks slippage (I think YM stop was 10200 and fill was 10198).

    Maybe the stop was executed immediately between IB and eCBOT and just the confirmation arrived late at my TWS.

    All I know is that I was watching YM quotes in TWS trade several ticks under my stop price, stay there for several seconds (in such situations every second seems to be an eternity) and as price came back up TWS showed my stop triggered.

    So, while price quotes were updating fine in TWS during that time, the transaction (triggering of stop and fill) itself (or just the reporting of it to my TWS?) seemed to have been delayed for several seconds.

    I should add that I've had no such frequent delay problems in the past over 3yr that I'm using IB (or maybe very few and far between, which could be attributed to momentary Internet bottlenecks, whereas recently it affects maybe 10% of the orders!). Although I've had issues with (IB simulated) stop orders not getting triggered in CBOT markets back in 2003 and 2004 (problem lasted a few days).

    Btw, I've got 2 TWS open on different PCs at any given moment and both of them showed same condition at those times (e.g. a cancel staying pink i.e. unconfirmed for over 10sec)

    Sofar I've only noticed one other person mention this particular behaviour and that was over a month ago and it really makes me wonder.
     
    #261     Oct 16, 2005
  2. Quote from mtzianos:

    mtzianos,

    First of all, if you are the only one complaining about an order execution flaw or bug, this should not by any means discourage you from investigating. I have found a very large number of extremely costly bugs, which must have cost most IB equity traders a great deal of money, and yet, I was often the only one complaining about them. The vast majority of traders don't fully appreciate how much they can increase profits, reduce risk, and improve their risk-reward ratios, simply by monitoring and optimizing order execution and routing. So you should go ahead and be a mover and a shaker, get out there and seek answers and get bugs fixed, even if it seems like you are the only one recognizing a problem.

    Second of all, IB CS reps and even developers will often claim that you are the only one complaining about a particular problem, when in fact, there are lots of other customers publicly posting complaints about the same problem, and the employees simply are not aware of what is going on, and they are not interested, and they will try to discourage you from expecting any response to complaints about obvious bugs. They will mindlessly chant the mantra, "The system performed as it was designed to perform", often when it should be absolutely obvious to them that there is a bug.

    Now let's get down to business. Do you know how to check your order audit trail? Did you do that? Can you tell us the precise times, from the audit trails, at which your stop orders were triggered? Have you examined time and sales? IB time and sales, last I checked, had some problems, so you might have to get it elsewhere, like E-signal or the CBOT. Time and sales should tell you exactly when your orders should have triggered. Be sure to take note of the exact triggering method which governed your particular stop orders, because this info is needed in order to make use of time and sales (last, bid-ask, double bid-ask, RTH, non-RTH, etc.). Now, did the orders trigger when they should have triggered, according to time and sales, or was there a delay? And then, did the orders execute immediately after they were triggered, or was there a delay between triggering and execution? How long were the delays, if any? What was the price action during these delays? Figure out what should have happened from time and sales, compare that to what actually did happen in the audit trail, and then ask yourself, WHY were they different?

    Please also check what happens to your limit orders. Is there a delay between the time you hit the transmit key, and the time that the audit trail shows your order working? Does the subsequent execution time and price of your order jibe with time and sales?

    Keep in mind, during this process, with respect to stops and market orders, that you must pay careful attention to whether a stop order is a stop or market order native to the exchange, or is simulated by IB. Lots of things can go wrong with simulated orders, if the simulation algorithm is off-kilter, so its up to you spot problems by comparing time and sales to your audit trails.

    Please indicate the results of your investigation, or please explain any obstacles you find in the process, and we'll try to take it from there.

    Or maybe somebody at IB will guide you through this process, but I doubt it. I think that you have to take the initiative and investigate as much as you can, before there is any chance IB will take an interest. No matter how obvious it should be that there is a bug, you will usually have to drag IB employees kicking and screaming to get the developers to pay any attention; and very few IB employees, other than the developers, are remotely capable of even evaluating whether an order executed correctly.

    I have been told, however that IB does have a particular concern about delayed triggering of stop orders, so who knows, maybe you will luck out and they will show more interest than I expect.

    This task is much easier than what I have to go thru when I track problems with equity trading. It is much easier because there are no routing or shorting issues as with equities, only execution issues, when you are trading YM.

    Second of all,
     
    #262     Oct 16, 2005
  3. A quick note (I'll try to address some of your other points in a later message) is that IB CS has indeed shown interest in this issue and PMed me for details right after my initial post here (a couple of weeks ago).

    So IB is definately proactive about tracking down potential problems (good job IB).

    The issue is that documenting problems with an individual order is time consuming (I need to immediately check TWS, do a traceroute and ping to gw2... to verify my Internet link condition to IB, bring up Audit Trail and take screenshot of said order and then check against my own API sw local timestamps which btw are adjusted every few hours via NIST atomic clock)

    To do this, I have to stop everything else I'm doing, which is hard when I might also be monitoring other positions/markets. And give up looking for the next trade opportunity while doing this.

    I've done this for a couple of orders sofar and sent to IB, but I'm posting here to see if what I describe rings a bell to others who might be experiencing similar symptoms.
     
    #263     Oct 16, 2005
  4. Quote from mtzianos:

    mtzianos,

    It is true that IB tends to show much greater interest in a bug report if you complain publicly on this website. It is also possible that they have, over the past several months, increased their general level of attention to bugs. I wouldn't say that they are generally "proactive" about tracking down bugs.

    Yes, you are right that documenting execution problems is time-consuming. But it is part of your job. You are a trader. If you don't do it, your execution costs will be higher, and therefore your risks will be higher, your rewards will be smaller, and since the market move further to cover larger execution costs, your number of trading opportunities will be fewer.

    Let's make it a little easier. Don't waste time with checking your internet connection for every single questionably handled order, unless there is some specific reason to doubt the connection. I have Verizon DSL and I never, ever received a bad execution because of an internet problem. Every single time I investigated a bad execution, any delays were occuring on the IB side, never along my internet connection. Forget the internet unless you have a specific reason to suspect it. Concentrate on the audit trail and the time and sales.
     
    #264     Oct 16, 2005
  5. The problem is they will discount your evidence if you don't include the internet data. It's classic "help-desk-itis". It won't matter if you've proven on the last five occurances that it wasn't your internet connection. It might have been this time since you didn't document it.... If there's a loophole available they seem to want to take it.

    I'm fighting a pair of IB bugs right now I'm about ready to take this board due to the slow/lack of response. I've finally convinced a CS rep that they are real (it took a MONTH) and that's where it seems to have ended.

    I wish there was a way to become recognized/certified within IB as competent user so at least I could talk directly to a programmer. Maybe by volume/commissions?

    No worries though. I'll be moving the bulk of my volume elsewhere shortly.
     
    #265     Oct 16, 2005
  6. Why are you moving, Shreddog?
     
    #266     Oct 16, 2005
  7. I'm going prop after years of resisting. Better rates, better BP. I've run out of reasons not to.
     
    #267     Oct 16, 2005
  8. alanm

    alanm

    I'll point out that the audit trails are kept for a week with names of the form Ddd.audit.xml. You don't have to stop what you're doing - you can look at them any time within the next week. Compare against T&S from the CBOT or CME website. If you have a working stop, your internet connection should have nothing to do with it - the stop is either at IB or at the exchange - your client doesn't even have to be connected for it to trigger.

    Having said all that, 1-2 ticks in YM doesn't seem like an unreasonable amount of slippage. Isn't the spread usually at least 2 ticks, even when it's not moving, let alone when it's making a big move?

    Can we move this to another thread and stay focused on suggestions here? It would be nice if people (at IB) reading for the purpose of new feature suggestions didn't have to wade through problems as well.
     
    #268     Oct 16, 2005
  9. alanm

    alanm

    Access to the NYSE 17:00 ET crossing session.
     
    #269     Oct 17, 2005
  10. Babak

    Babak

    While I empathize with those having problems with IB, I would like to once again remind everyone that this thread is a place where you give specific improvements or suggestions.

    Complaints re bugs, errors, etc. don't really have a place on this thread unless they lead to a specific suggestion on how things can be improved.

    Thanks. :)
     
    #270     Oct 20, 2005