I am not sure that would completely solve the problem in that IB could have an internal order log that is more complete than the one you see on your audit trail and that internal order log is probably never sent as internet traffic. I.e., sniffing might just give you what you already know - your audit trail. This is just conjecture though.
I suspect that the OP is innocent of "playing around with it" because he doesn't seem inclined to hold such big exposure going into the news event. I would have to say that I look at TWS's account page only just before I finish a trading session so I would have probably missed this problem because TWS is not a useful order entry/management tool for me. I would have checked before I walked away -- and all was OK. I would have checked again when I was going to finish the second session --- OH FUCK!!! If you see what I mean. So to me the OP has very limited responsibility for not noticing that there was this massive surprise position on which was not self initiated but TWS bug initiated.
This is the big question and determines the appropriate amount of compensation. I guess I am naturally more skeptical than most when it comes to these situations.
Why does Zzzzzap not notice this before the announcement, yet he evidently notices after the announcement and starts covering in earnest? Here's IBj's account of it once again: It seems to me that what you're proposing is that Zzzzap has next to no responsibility as long as he doesn't notice, no matter whether he COULD have noticed, or perhaps SHOULD have noticed. In fact, how does anyone know when he noticed? What if he simply closes out when he feels like it, and states that he hadn't noticed it up until that time? I suppose what it comes down to is what is reasonable for a trader. Again, when I sign on, I look at my account. I'm looking at the money, the interest, the positions, etc. I look during the trading session. I also check the execution page during the session. And then before the session closes, I look again, the thought being if anything is there that I don't want I want to close it. I don't have any idea whether this makes me unusual, but I would hope not. How else do we know how our account stands and whether it is accounted for properly? You know, I suppose I got this habit from the floor, where sometimes you would end up with "out trades" in the account. Errors in other words. A guy you traded with suddenly disavows the trade. Now your account has a position which was not intended. And funny enough, it always works against you. Most of us would call in an hour after the close to find out if there were any outtrades. I've just carried the habit over....checking my account periodically to make certain it is correct. The account by IBj to me sounds like he may have known. But even if he didn't, should he have? I guess that's what they'll decide. If I were IB I would find it hard to swallow that the standard is whenever someone gets around to noticing. OldTrader
Were the multiple orders on the covering side of GBP equal to the amount that zzzap was short? If so, wouldn't that give an indication that zzzap knew he had that position on? Or does he always trade in 66 lots of GBP?
"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." In my opinion the client at this time - 19:55:57 - should have noticed his account margin when he entered those orders. $12,000 less should have stuck out like a sore thumb.
If it is impossible to say when he noticed the error (that is, impossible to determine to a legal certainty), it would have to come down to the reason the mistaken position got initiated in the first place. I know it's not as important as the issue of culpability, but it still bugs me a lot that IB apparently tried to stiff this guy until he started making a fuss about it here. It was only then that IBJ came on and said that they were partially responsible. That's what bothers me about this. And there seems to be no objection to that allegation on the part of IBJ.
I have for a long time set up my TWS to show my account balance at the top of the TWS screen at all times. If my account balance makes a sudden drop then i want to know immediately not the next time i use the account window. The feature is in the Trader Dash Board (select TotalCashValue). I also have the Trader Dash Board show me my margin usage at all times, which should be 0 if i have no positions on. As well as this i have automated client software monitoring my open positions and open orders while TWS is running. If my software detects any positions that shouldnt be open or any orders that shouldnt be open then alerts are raised and alarms start going off. For example if my monitoring software sees an open position in ES but no corresponding live stop order in TWS then alarms go off. Had i been in this situation i would have been alerted by mobile phone SMS as soon as the rouge position was opened.
... and can cost even more if they do not backpedal the new 'safeguards' which have been silently introduced into TWS*... apparently on lawyers' commands. So far (after 1 day) I have noticed two undocumented changes directly related to this debacle: the blinking 'Trades' icon (which is fine) and... see for yourself upon the next 'automatic' reconnection (but make sure your security device is working, oh, and do not by any means try to run any trading software connecting to this newly 'patched' TWS!) @ IBj: automatic reconnections were a truly useful feature... essential really for 'hands-off' auto-trading. Security devices will be cumbersome to use in such time-sensitive and frequently occuring events as disconnections. They can be put to better use in accordance with their primary purpose, e.g. securing cash withdrawals, and not as a proxy for a digital signature, a hastily coded way of making sure that user is controlling the console This bug has been 'patched', but there are probably more confidence-building ways of preventing similar issues in the future. Overleveraging and max loss controls are already in place for margining purposes... why not make these risk reducing features customizable and accessible to the user? Call it what you want, but one thing is surely missing in TWS: order-flood prevention or consecutive marketable order submission... program traders here will be much more qualified than myself to chip in with the details... (thank you Businessman!) 0s *by TWS I mean the standalone version which was available prior to Friday's session, i.e. build 878 dated Nov 1 2007 (MD5 checksum of the jts.jar file: fff5ca51a6f7845e035f1a7545784ed0 )
I've been eyeing this thread for the past ~2 wks waiting for some sort of resolution before commenting. I'm glad that IB got to the bottom of the situation and hopefully some reasonable settlement. The double click does seem to be a user error, and protecting against it is good. However, two lingering concerns: 1. While there was some degree of user error and lack of mitigation, it seem like there is still an underlying potential of "zombie" orders coming back to life. The double-click safeguard is good, but it feels like other circumstances, not presently foreseeable, may still trigger a similar situation. The underlying problem of the incrementing of order ids, losing track of the old ones after they've been sent downstream, etc. still remains. i.e., you can look at your open orders and see nothing, leave.... come back hours later and get resurrected zombie fills! So it isn't clear to me that fixes are in place such that both a) no zombie will be created and b) the list of pending orders seen in TWS (or through the API) is authoritative as to that point in time. (Also, because of this, while zzap can take some blame for lack of mitigation, I would say the underlying problem was with this bug in IB's order handling...) 2. The escalation process appears like it could use some safeguards. Everyone makes mistakes -- but it feels like a 2nd review needs to be triggered to protect against mistaken routing of the escalation.