Not a day goes by when some esteemed journal doesn’t give an informed opinion on the importance of reducing Latency in trading systems. Indeed it’s rapidly becoming an arms race between major trading venues offering faster and faster access to more and more data. With increasing data volumes, reducing order sizes and trading margins and increased volatility some folks are predicting an impending data storm.

And now the clever, high velocity traders in the hedge funds have got in on the act. No longer is statistical arbitrage as popular as it once was - with increasing levels of volatility seen in the markets mean reversion based models are struggling to make the money they used to. Never ones to miss a trick, these folks are now looking to arbitrage the millisecond latency differences between the existing trading venues and the new trading venues that are coming to the market here in MiFID land.

If the traditional trading venues don’t evolve rapidly they will be in danger of finding their liquidity rapidly moving to these new venues where there is lower latency risk and inherently better execution.

 To folks using these new venues it will be an opportunity to optimise their trading strategies and maybe even participate in the latency arbitrage game. However, for the folks that stick with the more traditional (and supposedly more liquid) venues, slower liquidity will by it’s very nature become a curse.

 But like all great opportunities, once traders start to make money from an anomoly in the market then everyone piles in and the anomoly disappears very quickly. My guess is, if you’re not already in the game it may already be too late. Then again, maybe not.

I spoke at an event this morning in Chicago. The event was hosted by Wall Street and Technology and the theme was “The Intelligent Low Latency Trading Imperative”. It was interesting listening to Ambreesh Khanna of Sun and Jarod Jenson of Forsythe talk about the challenges that software developers face in building applications that perform with extremely low latency. Ambreesh made the point that in the past, the ever-increasing speed of hardware kept the pressure off the programmers when it comes to performance, but that now we’ve hit the limits of single-CPU performance. Now that hardware performance gains are coming via more CPUs/cores rather than faster CPUs, software has to be written to take advantage of the architecture. And the fact is that most software isn’t, and many programmers aren’t ready for the challenge. And it goes beyond writing multi-threaded code. Jarod ran through a check list of the low level things that can contribute latency, and the tools that can be used to pinpoint where latency is being introduced.

All this makes me realized that while we talk about CEP as a platform for rapid application development, we probably don’t make enough of the fact that it’s a way to build scalable, low latency apps without having to develop the deep technical skills that normally requires. For example: you don’t have to know anything about threads to implement your app on Aleri CEP. But it’s automatically multi-threaded, allowing it to run different operations in parallel across multiple cores. Bottom line: writing highly scalable, highly efficient, low latency code isn’t easy. It requires specialized skills. But when you implement your business logic on Aleri, our team, that has those skills, has done the low level work for you. You focus on the business logic; we’ll take care of performance.