So their paperworks is there to scare the law ignorant off. Turning to the media might be more powerful. They fear a damage on their fame more than a lawsuit.
The paperwork gives them an advantage; however, it is not always the end of the matter. I've seen lawyers take what looks like the most ironclad protection and turn it into putty. It depends on the facts and law of the particular case.
1. I don't believe it's reasonable for an active trader to have to verify that he sees every order go red. I don't have to do that with any other platform. It should only disappear if cancelled. I thought TWS had become relatively stable as far as reloading it's idea of current order statuses after a disconnect/reconnect, meaning it should not be possible to "lose" a pending order. 2. I'm confused as to how a problem at DB could cause a delayed execution report. Isn't it IDEALPRO that matches the trades and issues reports? Are the MM orders resting on IDEALPRO somehow different than retail orders that are submitted to it? Is there some sort of handshake required from the MM even after the orders have been matched by IDEALPRO, and if so, why?
If I was filled 2 seconds after my limit order was placed, shouldn't that show up eventually in the audit trail? The filled execution report shows both the sending time and the transact time are the same; 37 minutes after the order was placed.
Now that to me is a problem. It may be your system though. If the send time and execution were 37min apart I would think that was very dodgy. It could be that your machine only transmitted the order 37min later. If so why? a) Were you running any other software? b) Could your service provider have delayed the transmtting of the data. One thing though why did they trade at the price from 37min in the past?
No the order was sent and received by IB at 10:01. If I was filled at 10:01 and for whatever reason they delayed sending it till 10:38, shouldn't it say that I was filled at 10:01? Because it doesn't. Nothing in the audit trail shows that the order was filled 2 seconds after it was placed as Def wrote. It shows the fill 37 minutes later.
I extracted the facts from TRADERguys's presentation about page 11 of this thread and added my comments in blue/red. The presentation is muddled because it commingles actions on 2 orders: a limit order to sell (this is the problem order), and a related buy stop order. The stop order really has nothing to do with the problem at hand. - at 10:01:31 I put in a limit order to sell the EUR/USD at 1.24785 agree -at 10:01:31 the order was acknowledged agree. The order is not marketable so it is sitting on IB servers since all liquidity providers operate on a fill-or-kill basis We only send the order to them once it is marketable since we dont know which bank will provide the marketable price first. -at 10:01:33 I dragged the order down to 1.24735 agree. The modification is accepted and acknowledged. It is marketable (bid in market is 1.2474) and is submitted immediately to a bank -at 10:01:33 My stop loss is modified to 1.24855 the stop order has nothing to do with the problem as far I can see, so there is no reason to address. It does appear that client is submitting stops tied to limit orders with a trigger price 0.0012 above the limit order. -at 10:01:52 there is an OrderCancelRequest for the stop loss agree -at 10:01:53 my stop loss was canceled agree, although as previously noted this is the STOP order and not the limit order. Since the STOP is wholly on IB servers, and was never triggered, we were able to confirm the out. -at 10:01:54 there is a OrderCancelRequest for my limit order to sell at 1.24735 agree there is a request to cancel. At the time the cancel was first sent, the bid on USD/EUR is higher than the limit price of 1.24735. According to the internal audit trail (i.e. the ones on IB servers as opposed to the ones at the TWS), the order is never confirmed out. We received the cancel request and relayed it to the bank where the order was sent every 30 secs starting at 10:01:54.891 and ending at 10:37:55.299. On the TWS, this showed a 'pink' status bar. -that is it till my order gets executed at 10:38:23 disagree. Order actually executed at 10:01:33 but was not reported back by liquidity provider to IB until 10:38:23.847 (per our internal audit trail). IB reported onward to client immediately (in a fraction of a second) The server side audit trail clearly confirms the above and this has been sent to the client by web ticket (account management). As there is confidential info in the server side audit trails, I cannot post them here. Client may should he wish. The English language version of the event is as follows: client submits order, changes the price to one that is marketable. Order is submitted to bank and executes immediately. Bank fails to report execution back to IB because they are having latency problems on their trade registration system which is tied to a back office booking system (they did not get into the fine details with me but this is my take on their explanation). The backlog clears -- unknown to me whether this was actively managed or just cleared the way a traffic jam does -- and the trade is delivered to IB at 10:38:23 and reported to client immediately. Loss on trade based on differential between execution price and market price at time of reporting is 107.50 USD, or as client reported, 43 pips. I don't drop a C-note on the street and not pick it up so I am not trying to say the client should not care (because I think he has every right to care), but this is not a big enough number for either IB or the bank to play games for, even if one is conspiracy minded. In my conversation with the bank, they acknowledged they have a system issue which they are addressing with maximum priority. The problem crops up irregularly, but is clearly linked to volume bursts (number of trades, not size of trades) which, as in this case, can concentrate around Fed announcements, economic news, etc. Their problem extends to all their clients, not just IB, and they clearly understand the urgency to correct it. Exchanges have reporting latency all the time, but often they have a monopolistic or oligopolistic position so it is difficult to not consider them. We try to allow clients to ignore those that are persistently neglectful, for example the AMEX. In the case of FX, there are many banks offering prices. We treat them like an exchange (IDEALPRO is essentially a SMART routing between multiple liquidity providers). However, if one bank consistently fails to fulfill its obligations, we can route away from them, or deprioritize them in the IDEALPRO book. What Went Wrong Client: did not properly interpret color status indicators. Documentation on these are available in the TWS Users Guides at: http://www.interactivebrokers.com/p...nce_Information/TWS_Color_Key.htm#OrderStatus did not call IB in a timely manner. Given the market pricing, the order was either cancelled or executed. COMMENT: Whenever their is uncertainty, a phone call (not email or other non-real time solution) is recommended. As some post-ers have pointed out, taking a conservative posture when it comes to trading uncertainties is the safest route. When is doubt ask. It at least registers the issue and mitigsates our concerns with people trying for a free option. I will apologize in advance that our response times have gotten much longer than I would like. At the end of 2005, we were well under a minute. Average response times jumped to upwards of 3 minutes in the last 2-3 months and we are expanding our staff as fast as possible but it will be another few months before we can get back to the 40 second target we had over most of 2005. misconstrued the issue as one of ethics (see thread title) instead of a technology problem. COMMENT: chalk it up to emotion. IB acts a broker not as a trader and our vested interest is always to get the best execution for the client. Were we acting as an FCM who takes the other side of the trade, the client might not have experienced this particular kind of delay. But as I have said in other places, it is hard to imagine that trading through someone who is on the other side of the trade is structurally optimize to the client's advantage. IDEALPRO is subject to the quality of our liquidity providers in the same way that the ISE is faster than the AMEX. Liquidity Provider: has technology issues. They are working on them. COMMENT: If they don't get it fixed quickly enough, we will route away from them. We are adding a big new provider in the next 1-2 days so the loss of one wont affect the quality of the IDEALPRO quote. is still considering how to handle such issues re: possible claims. They would be willing to cancel all trades reported late, but that will be ALL trades, not just the losers. COMMENT: This doesn't work when their client is an entity like IB who itself has clients, where the winning trades and losers are not likely in the same account. IB: has error trapping for IDEALPRO configured with a sensitivity appropriate for a real exchange but perhaps too high for a counterparty model. We were first aware of the trade reporting problem when the client informed us. Our system is set for exchanges where we alert to possible problems when for example 20 orders are experiencing ack problems. If we alert when 2 orders are delayed, we would have gotten a warning on this type of problem earlier. We are upgrading this. I am sure someone will come up with other things IB did wrong. It is not my intent to be disingenuous but the fact is that we did not cause or contribute to this problem as far as I can see. At worst, IB was too slow to detect that some orders were in an undetermined state and did not contact the "exchange" proactively, but this is a value added notion, not a specific obligation. Usually when I write one of these giant monologues, I try to cover everything anybody says in the thread. Frankly, there is so much partially informed commentary there isn't enough time. Aside from poor choice of thread titles, the affected party has actually stayed pretty fact oriented. Facts are a good thing.
So basically there were two problems. One, the counterparty reported the fill late. Two, the customer didn't properly appreciate that his limit was marketable and might not get cancelled. The TWS gave a pink rather than red indication. Question. Did the order entry line disappear on TWS? If it was pink, I am assuming it should not has disappeared. I think we can all thank IB for giving us an objective summary of what happened in this somewhat disturbing case. How they resolve it is between them and their customer, but I honestly think that a 30 minute delay in getting notification of a fill is very unreasonable for a retail customer. The customer perhaps should have done things differently, but he never saw a fill on his TWS so he had a reasonable belief that he was not at risk.
Two Notes: (2 cents each) 1. (This one was mentioned already) In TWS, under Configure>Orders, uncheck "Auto-remove orders." To manually removed filled(Black) or cancelled out (RED) orders, use "Remove filled orders" found under the ORDERS menu. This way any unfilled or not yet cancelled out orders (Pink/magneta) will remain clearing up any confusion. 2. Magneta (as is word in the TWS manual) is actually "PINK" and is worded so in TWS as "PINK." (or perhaps I modifed the color and wording.)
I wonder how the trader said order was gone on tws, and IB said order was pink on tws. Hope this is addressed.