I'd have to agree that he will get his funds back if IB is willing to publicly admit it's a bug. $52K is small beans to a company like IB, and the bad PR from not giving back the money is much more costly than $52K....
Constant software problems, service interrupts, bugs which cost retail traders a substantial amount of money ... Interactive Brokers may be the most sophisticated, but that doesn't necessarily make them the best. JJ
I've been thinking a lot about this(don't laugh). At the end of day. 1) Is IB legally required to pay the OP back. I would think not, its not fraud or negligence on their (IB's) part. 2) Should they pay him back? If he had made money instead of lost would he pay it to them? Perhaps the best way here is to share the loss equally? Heres my next question say you, over time have built up a big conversion position. Calls and Puts versus futures. As far as you are concerned there is no risk left in the position, so you leave it to close out. Because the position is quite big its eating into your margin, but you are not worried because its a locked position. At close out IB close the options out at one price and futures at another, (don't laugh, they have done it before). As a result your "locked position loses a large amount of money, that triggers a margin call on your other positions. By the time you sort it out and reestablish your positions you have lost huge cash. Question is, should IB pay you back your losses? Also are they legally forced to, their mis marking of your position at close out is clearly negligent. To my mind they are morally obliged to pay you. Basically the only way to protect against this scenario is hold a large amount of margin at IB. Which of course opens you up to IB itself failing. Bugger I suppose life is inherently unstable. Just ask the dinosaurs.
OK, here it finally is: Zzzap gave me the OK to present the results of my investigation here since there seems to have been a lot of interest in the discussion. I have attached an annotated order trail with ID data overwritten. The audit trail has real world info such as time points for various news events as well as the market price for GBP at various interesting times. For those interested enough to follow this, there is a chart attached in MET to match the time descriptors in the audit trail. Here is what happened: 10:30:01 Client created a basket of GBP currency related orders in spot and futures contracts. Total value across 19 orders was roughly 31M GBP, all selling GBP. This was submitted at 10:30.01 and may have been tied to trading UK economic news. The client clicked submit for the basket twice in very rapid succession creating the following timing issue: The orders from basket set 1 were being credit managed and routed when the "second" basket comes in. The orders from the first submission are in transit through our system and out to the various liquidity providers and the downstream processes (closer to the exchange) had not acknowledged their state so when the second submission hit, the upstream order control process believed it still "owned" the orders and interpreted set 2 as a modification. When this happens, the order IDs are incremented and the old order IDs become stale/expired. Now it gets messy. We start to get the acks from the downstream processes confirming they have received the orders from set1 and are forwarding them on down the pipe. But as the order control process thinks these orders are stale and have been replaced with modifications, we are now managing a set of orders with undetermined state. As one sees in the attached audit trail in brown, there are a series of messages stating "NoSuchOrder" which is what we record when a downstream message comes back with an unexpected order ID we don't know how to handle. The client's GBP futures order was one of these (see 10:30:02.877). We are in a messy state with 6 of the submitted orders. The others escaped the timing snafu. I did not bother to trace the ultimate resolution of the other 5 since they either never executed, the order controller resolved the indeterminate state, or the client accepted them. But one of the GBP orders was left stuck in an existentialist desert, neither active nor cancelled. Times passes ... 17:46:46 for unknown reasons there is a TWS disconnect. Could have been an IB disconnect, an internet hiccup, or something on the client's side. It actually doesnt matter. This is just the next banana peel. 17:48:57 TWS automatically reconnects and the order control process gets the computer equivalent of a wake up nudge and all of a sudden rediscovers the stranded GBP futures order. As it is marketable, it is submitted and gets filled in a series of small executions at roughly 1.9929 18:08 to 19:12 various stories out of the UK runs sterling up a bit to ~1.9945. 19:38 there is another disconnect/reconnect but based on the speed, it is presumed that this was an automatic reconnect 19:55:57 Client submits multiple orders in various currencies. This is the first time we can know with certainty that the client is using and attending the TWS. Had he covered the GBP position at this time, the loss would have been roughly 12000 USD. 20:07:31 through 20:10 Client submits multiple orders for GBP futures on the buy (covering side) although the bids seem to be far away from the market. Had the position been covered here instead of just being bid, the loss would have been ~8700 USD. 20:19 As widely expected, and on the announced schedule, the Fed cuts interest rates; the 50 bps is the surprise and the futures rocket up from 1.9954 to 2.0050 in seconds, retreat back to 2.0000 and then proceed rapidly again up past 2.0080. 20:26:19.36 Client commences covering in earnest with initial fills at 2.0021. 20:35:51 Client finishes closing the 66 lot position with the futures trading at 2.0090 SUMMARY / ANALYSIS IB's client agreement says that the client is responsible for any order he/she submits and, strictly speaking, the client did submit these orders. But sorry to disappoint all the people with their hands on the speed dial to their attorneys, IB really tries to run its business based on business principles, not legal nuances. We live in a litigious world, so protective agreements are the universal way to define exposure limits around which we are always free to improve. The double click of the client was an error but so what. It is not reasonable to expect someone to recognize this extraordinarily arcane situation. The TWS was patched to prevent this about a week after the problem was reported to the developers. IB will indeed compensate the client for loss. We will need to decide how to interpret the activity from 19:55 onwards to determine the amount. It is a problem that the risk was not covered when first recognized. IB's standard position in all trading issues is "manage your risk" because the market will not sit around waiting while we research a problem. We absolutely dropped the ball in responding to the client. The problem occurred on 9/18. He contacted us a few hours later and then contacted one of our developers with whom he has previously communicated on October 5. It was escalated and it actually even got to me (as I just am discovering going through the contact history now) but I seem to have misunderstood the problem and passed it to the wrong person. It simply got buried as new issues piled in behind. Not good. I apologize to Zzzap that we did not resolve this more promptly. [/list=1]
If you fully reimbursed him for the loss, my absolute f#$&ing hats off to you. You did the right thing.