The dynamic programming approach that I am currently following is quite similar to Q-learning. The prices and quantities of a set of limit orders embody the action to be taken by the policy. The state in my execution algorithm is a vector of attributes that describe the current configuration of my system. Two of these attributes are (i) the time elapsed since the trading signal was generated by the decision engine -- its maximum value is the execution time horizon which is 5 minutes in my case, and (ii) the number of shares that are left to execute in the target quantity. Other important attributes are a set of market variables which are functions of the price and volume of the traded instrument. Among them are predictions of the price 1, 2, 3, 4 and 5 minutes into the future. I apply adaptive filter techniques in combination with discrete wavelet filtering (to reduce noise) for this. To reduce the computational load, I make it an absolute top priority to cast all my algorithms in recursive / online forms (i.e. I avoid rolling window type batch learning approaches). Other than Q-learning type dynamic programming approaches I am also looking into methods that are based on direct adaptive control techniques. One idea that I have been working on is to find analytic expressions for the average execution price at the end of the 5 min horizon, which are differentiable. For this I seek approximate expressions that are smooth, i.e. have no discontinuities. Having a policy function approximation at my disposal I can then use gradient descent techniques to adaptively tune its parameters by recursion. A problem is that the analytic expressions, which I derive with the help of the symbolic computation software package Mathematica, become very unwieldy and complex, i.e. their computational load during live trading can become a bottleneck.
I have launched automated trading system, using IB and its C# API, for a few months now. One problem I kept having is IB price feed. Sometimes the price data gets stuck, like in a broken record, and kept quoting me the exact same price to eternity. Perhaps I should take the advice of using an external data feed. But here are some question for you. How many trades did your system make this week? What is the percentage of winning trades? Also, do you have a stop loss and a stop gain? Somebody mentioned "execution engine". I thought of implementing something like that too. I thought of calling my "order optimizer", but now I think I will call it Wizard of Oz. The purpose for this optimizer is to wait for a more favorable price after the trading signals. Why? Because after a while, I realized that the more frequent you trade, the more of your profit will be eaten by the spread/slippage. This extra alpha should just offset the spread and the commission.
winnertakesall, congrats on launching your ATS! Can't say that I've encountered the problem you've described but how is your Internet connection (using wifi?), are you requesting the data feed more than once, and are you using the live feed or 5 second candles? My primary strategy trades 0.3 times per equity/day, win/loss is about 65% and I have defined targets and stop losses. It's incredibly simple and could definitely make use of an improved order execution algorithm. I don't need to worry about pennies with this strategy so right now I'm not really concerned about my fills. As I've only been live for 4 weeks, right now I'm in bug fix/feature complete mode.
Just discovered this thread and had to contribute. Iâve have been working on building an ATS for some while now working with Java+Oracle against the IB API. So far, I did not have the nerve to let it run on its own as Iâm still seeing possibilities for improvement. Iâm storing each and every market tick in Oracle that comes back from IB, so I can exactly replay a certain situation. (for speed Iâve put the Oracle datafiles on ssd). I am mainly focussed on trading ES futures doing 4 to 6 round trips per day maximum. Otherwise, the cost and slippage would be too much relatively. Also, what Iâve noticed is that you really have to take a good look at the tick data from IB to make sure it doesnât mess up the algo. For anyone interested, thereâs an IB API mailinglist where several of these issues are discussed among developers.
I've wanted to do an update for a couple of weeks now but life has been busy. I don't know how I had time to trade before the ATS So, there has been good news and bad news. Firstly, although the strategy was batting 0.8 for the first two weeks of last month, the last two weeks took back virtually all of my gains. Overall, the strategy has made money so I'm not too concerned at this point. It is, however, one of the worst returning periods of all my backtesting. My trading size is embarrassingly small at this point but that's kind of the idea when testing a new system. I did encounter a couple of bugs along the way with only one being pretty serious and I'm not quite sure how to deal with it. 1) Local system clock slippage - I was running the system on my development MacBook Pro and the clock would slip sometimes more than 10 seconds in a day. This was causing all sorts of issues because the strategy is time based. This was resolved by buying a dedicated server (hosted at home) and properly configuring the NTP client. Now that I run on dedicated hardware with a clock that is within a couple milliseconds of atomic time, the live trades have been 100% in line with backtesting results. 2) Ran out of margin - Last week things got pretty busy and the system put out so many simultaneous orders that I ran out of margin and found a new test case. It wasn't a big deal, in fact, it saved me from a losing trade but when IB didn't respond to the particular orderId, the system started to complain. An algo got stuck looking for the one orderId it couldn't find which resulted in that particular equity being done for the day. I run each equity with it's own settings, independent from one another, in order to prevent any interference between algos. Unfortunately, no, it is not multi-threaded at this point. 3) Order confirmations - This is the biggie. Normally in HTTP or SIP style protocols, you send a command, the server replies with "got it, thanks!" and you reply with "okay." This ensures that everybody is on the same page and data gets there in one piece. From my understanding, IB does not do this. When you send off an order, it is gone into the ether - no acknowledgement, no nothing. I could call the reqOpenOrders() method every time I send an order but this seems like too much. There is still more investigating to do and I'll post an update when I have one. TL;DR Making money, bought a server, found a couple of bugs.
Did you run it in real-time simulation mode ? That is, have the program receive market data and send orders to IB using a paper trading account (with real market data). If you get good results this way, the next step is to trade it with real money.