The ideal would be to be profitable in every simulated session (=recorded market data) or at least be 'significantly' profitable overall. Also, there should be enough different kinds of market sessions in the DB to assume/proof that it will be successful in all those situations. I have several wild whipsaw-sessions from the 2011-2012 period, but the algo should also perform well during a flat session and not overtrade. For now I'm mostly working on my neural network for generating daily trading signals, which is working just fine for the last 2 year (actual trading). I may not even need the algo in the end, but it's just great fun building it ;-)
I did on a paper trading account, it all seems to work just fine. I may need to make it more fool-proof in case something goes wrong (lost connection, no accurate order execution reporting etc).
1) Totally been there... 2) & 3) When you say IB does not reply I don't quite understand, you know about the order state messages right? (submitted, filled etc).
Well, my system only place market orders at this point. And when the order is filled, the system does give confirmation, and displays the price the order was filled. If this is what you are talking about, you should check the function orderStatus in the wrapper. As far as running out of margin, I actually been there and done that. I made changes to my code one time, but had a typo in an if statement. By the time I realize that, it was 6 hours later. Instead of having one future contract, I had quite many more and my account was maxed out. But as amazing as it was, that typo actually made me money as the market went the right direction. Though it could have been one expensive typo. Luck!
My system also uses market orders because if the algo decides to act now, it really must be *now*. So with enough volume in the DOM, a buy will most often be executed at ask and sell at bid. But with bigger orders or some other weird coincidence, the average fill price may be different from what was expected so I really need to verify the execution. But when for some reason the wrapper call orderStatus does not happen, the algo keeps waiting and waiting assuming the order is not filled. A solution might be something like portfolio synchronization if no callback is given within, let's say 5sec or so.
Make sure you do your own error handling (nothing is outside a try/catch) in the orderstatus function. If any error is not caught and percolates up to the IB API, it just disappears into the ether - you see nothing. At least, that was my experience with the API a couple years ago.
It's not the API throwing an exception, but if your own code in the event handler throws an exception, it's on the API call stack and the API doesn't handle it in any reasonable way ... it just disappears.
Indeed same here, I've seen that happen and sometimes it would even disconnect from tws. So everything is catched ;-)
Undefined just so you know most people don't consider IB to be a reliable data provider, better to have a separate service for this.