Trades Code: code contractid filled_datetime filledtrade filledprice 2884 AEX 201503 2015-03-06 08:02:31 -1 488.15000 2878 ASX 201503 2015-03-06 01:00:49 -2 5870.00000 2881 AUS10 201503 2015-03-06 01:14:04 -1 97.40500 2880 AUS3 201503 2015-03-06 01:15:24 -1 98.08000 2879 AUSSTIR 201606 2015-03-06 02:12:19 3 97.90000 2882 AUSSTIR 201606 2015-03-06 02:23:32 -3 97.89000 2883 BUND 201506 2015-03-06 07:36:48 1 156.99000 2887 BUND 201506 2015-03-06 14:46:53 -1 156.57000 2886 CORN 201512 2015-03-06 14:30:00 -1 410.75000 2885 NASDAQ 201503 2015-03-06 14:05:22 -1 4447.00000 2888 US10 201506 2015-03-06 15:16:13 -1 126.03125 Slippage in GBP, for entire trade code gbpt_slippage_process gbpt_slippage_bidask gbpt_slippage_execution gbpt_slippage_all_trading gbpt_slippage_total 2879 AUSSTIR -37.06 37.06 -74.12 -37.06 -74.12 2887 BUND -21.91 3.65 -7.30 -3.65 -25.56 2883 BUND 7.30 3.65 -7.30 -3.65 3.65 2886 CORN -4.09 -0.00 8.18 8.18 4.09 2880 AUS3 -7.70 7.70 15.41 23.11 15.41 2888 US10 30.69 5.11 10.23 15.34 46.03 2881 AUS10 34.78 11.59 23.19 34.78 69.56 2882 AUSSTIR 37.06 37.06 -0.00 37.06 74.12 2884 AEX 94.93 7.30 -0.00 7.30 102.23 2885 NASDAQ 83.47 1.64 36.00 37.64 121.11 2878 ASX 371.01 12.79 -51.17 -38.38 332.63 Total slippage: process 588.480000; bidask 127.550000; execution -46.880000; all trading 80.670000; grand total 669.150000 Most of these trades make sense; post NFP sell off reducing positions in both bonds and stocks, including selling the Bund I'd bought in the morning. The AUSSTIR is a little more perplexing. The system shouldn't just buy and then sell 3 lots, only one tick apart on price. I've dug into it a bit and I can't find any obvious bug or explanation. This is one of the reasons why I use trade limits - caps on the numbers of trades done in each day. I will watch carefully to see if this happens again. P&L: -£1153. I was actually up until the NFP came out when I dropped £4k quite quickly. Still could have been a lot worse. Here is another issue which was easier to diagnose and fix. On friday morning one of my regular 'health checks' highlighted an issue (actually it was Thursday night, but I had better things to do than sort it out then). Heres an extract: Code: code contractid ib_position locked my_position problem 7 LIVECOW 201510 1 False 0 True Basically IB thinks I am long one october contract live cattle, whereas I think I am flat. It's vital that this issue is resolved. If I think my optimal position is 1 lot, which if IB is actually at I already have, then I'll buy an extra lot to bring me into line. For this reason whenever one of these health checks fails in this way it will lock that instrument so it won't trade until I manually unlock it. Heres an extra from the same regular report: Code: Instruments with trade control: LIVECOW NOOPEN AUS10 NOINCREASE AUS3 NOINCREASE KR10 NOINCREASE .... You can see that LIVECOW is in a state NOOPEN, which means no new trades will be placed until the state is changed. In the other contracts I am not allowing myself to increase my position, though will do reducing trades. Other valid states are OK, NOREDUCTION, STOP (cancel any existing orders and do not issue new ones), CLOSE (issue trades to immediately close the position). The first order of business is to have a look at Thursdays trades. Code: Code contract_id orderid submit fill fill_date LIVECOW LIVECOW 201510 2874 1 0 np.nan LIVECOW LIVECOW 201510 2875 1 1 2015-03-05 16:45:21 There is a shortfall in the first trade. Comparing this with IB account management I can see that both orders were actually filled. So the fill data didn't come back from the API, or was lost somehow. I run a function that inserts the fill into my database at the correct price, then run a report to make sure that the positions in my database now match, and then change the status of the LIVECOW instrument so that normal trading can begin again. The important thing here is that knowing what your position is, and what orders have been filled or not, is crucial. We have two sources for this information and by comparing them we can avoid problems. Relying on just one source would be dangerous, unless you can be 100% confident in it. That hasn't been my experience with IB. Sometimes the status of positions that comes back is wrong (which means my database is correct), and sometimes its fills that are missed (which means IB positions are right and my database is wrong). (Such problems are not uncommon in large funds eithier, where fortunately there are middle office staff to track down and solve the problems). The small downtime and work this creates is manageable with relatively slow trading. With quicker trading you'd need to think differently. That's what I would have expected. I'd be curious as to what kind of characteristics / correlations do work. Is your timing basically 'momentum' (systems that work continue to do so) or 'reversion' (bet against systems that have worked). I can think of examples where 'momentum' might work. For example if there is a secular trend then trend followers who are faster than that slow trend will pick up on it and outperformance will be repeated. I wouldn't bother as its simpler to capture the effect with another, slower, trend following model.