High Frequency Trading –Platform Decision

Platform Decision :

We had initially planned on going with a commercial event based platform called QuantStudio that would allow one to back test, then easily turn on for execution of live signals. After several weeks, we ultimately decided to use separate platforms for modeling and execution. For modeling, we’ll primarily use Matlab to backtest high frequency trading strategies. Like everything else it has benefits and drawbacks. Matlab is not event based and it’s really not build for live continuous computations, so that pretty much eliminates it’s usefulness for live trading. Out of the box, it is not the quickest, something required when dealing with large amounts of data. But it is good for rapid prototyping of strategies. And while out of the box it is not the quickest, you can call C# functions from Matlab for the heavy calculations. Likewise, you can call Matlab from C# applications to take advantage of Matlab’s large library of functions, such as for options trading when we roll own product later on. Matlab also has a parallel computing toolbox to exploit multiple cores Gradually, we’ll build our own platform over time using the C# based components we’re building for Matlab. Some of this has been done already. Plus, Brain has been working with it for about a decade so this will make it easy to get up and running.

It was a tough decision as we spent several weeks on one particular off the shelf platform, called Quant Studio, now named Opentick. It is an event based platform and built with high frequency trading in mind. I had purchased the source code a while back, but we decided it was too slow and it would take too much effort to make suit our needs. It required everything to be handled in memory, which limits it’s backtesting ability when you have 5 terabytes of data. My version was a little dated, so it had bugs, passed data back and forth unnecessarily, and had several lock ups. It wasn’t as fast as we thought it would be. Even though we did have the source, it was really difficult to figure out the logic and naming, as it always is reading someone else’s code. If the core were built in something like C, it may have been worth it to invest the time. We also looked at Tradelink, whose strength is that it is open source, had a lot of data connections, and is reasonably fast. But it didn’t have a lot of functionality and was more of an alpha stage product. We may revisit one of these solutions for execution when the time comes.

Next comes data. We have a lot of it, so even either importing it or using it with a platform is not trivial. The goal was to use Matlab’s financial series tool box to save time. Unfortunately, it was not designed with speed in mind. Over a couple days running tests, we isolated the major slow points. For example, the way it handles date conversions slowed things down by several magnitudes. We built a C# script to address the major bottlenecks. In addition to handling date conversions, the C# function will read compressed files of various formats directly by uncompressing and converting them into numerical arrays on a fly. In the end, the various tweaks speed up Matlab’s data reading process by 10-20 times, putting it almost on par with QuantDeveloper’s advertised data reading ability.

Further Reading

High Frequency Startup Introduction Post

Popularity: 12% [?]

Tagged as: High Frequency Startup Journal