From looking at many newspaper headlines you could be forgiven for thinking that all financial markets are being overwhelmed by a tidal wave of high frequency trading. However, as most market participants know, the reality is very different. Historically, only a handful of extremely well-funded organisations have been able to afford the necessary investment to achieve maximum functionality with minimum latency.
This cost of entry applies across multiple areas and in some cases goes hand in hand with logistical issues as well. For example, many high frequency firms use GPUs and FPGAs in order to minimise latency. Apart from the hardware costs, these technologies require specialist programming knowledge that isn't always readily available in conjunction with financial markets expertise.
Another potential technology problem is flexibility of strategy deployment. In many cases, available off the shelf HFT technology is not very accommodating if changes need to be made during market hours. For example, if a running strategy has a parameter that needs to be changed, the strategy typically needs to be taken offline (and any working orders cancelled) before the parameter can be changed and the strategy restarted - by which time it has lost queue position.
A common theme these days in the world of automated trading is time to market. As competition to capture available market inefficiencies continues to increase, the need to build and deploy more trading strategies faster becomes ever more pressing. That requires development, testing and deployment environments that are optimised for the particular type of strategy being developed. For those without limitless resources and/or bottomless pockets, this raises the question of how to assemble the requisite workflows quickly and economically.
Some elements will obviously require the firm's proprietary edge, but others will not. The snag is how to bolt this necessary but non-proprietary functionality together without having to pay for a pile of other redundant bells and whistles as well. The ideal is something that encapsulates all the core functionality needed by any development/trading application but that also has a straightforward API and a third party developer ecosystem. This approach enables a trading firm to pick and mix only the additional functionality it requires from third parties and run it in tandem with functionality built in house. If the firm later wishes to expand into new markets or strategies requiring additional functionality, it has the strategic flexibility to build/buy what it requires and quickly assimilate it with its existing infrastructure.
Addressing these various entry barriers to high performance automated trading was effectively the template for the development of OptionsCity's Freeway trading platform - together with its integration with the company's Algo Store for third-party developers and its Metro option trading platform.
Freeway is an easily-customised high-performance algorithmic trading engine that is Java based and also includes an extremely simple API in order to facilitate extensibility. Strategies can be remotely managed from a workstation via a dashboard interface (see Figure 1) that traders can reconfigure to suit their preferences.
Freeway also supports recording and multi tempo replay of market data for back testing purposes (see Figure 2). Replay/simulation can be performed locally using data from any historical data source, but can also be run on a co-located server using a simulation exchange and production market data in order to attain the most realistic results possible.
The platform includes a plug in for Eclipse (see Figure 3) and has a variety of wizards that interact with that to significantly streamline the development of add on functionality. For example, an auto spreader with basic functionality (i.e. just the business logic without exchange connectivity etc) requires about 2000 lines of code. The identical auto spreader functionality built within Freeway requires 200...
One click multi-market deployment
A similarly lean approach applies to strategy deployment; one click is all that is required to deploy a strategy to OptionsCity's co-located servers in major US and European markets. However, a crucial difference is that this doesn't instantiate the strategy as a separate process running on the co-lo server, but instead integrates it into the main Freeway process already running on the server. This avoids incurring the latency inherent in an API call and is one of the factors that allows Freeway to deliver 100 µs round-trip execution times.
A related benefit is that Freeway allows production strategies running on the co-lo server to be adjusted in real time without having to be stopped and restarted. As long as the strategy has been written with configurable parameters, such as a profit edge, a trader monitoring it can rely on being able to adjust any parameters without losing order book position.
Write one, trade many (interactively)
The ability to make on-the-fly changes also opens the door to deploying multiple instances of the same basic strategy each with slightly different parameters. Furthermore, because Freeway also allows running algorithms to signal each other, these multiple instances can be linked in a "command and control" paradigm (as can strategies based upon entirely different core business logic).
As a result, based upon this inter-algo communication, a multi-tiered hierarchy can be established where a master trading algorithm controls a group of child algorithms, which each in turn control their own children, and so on. The master algorithm can be signalled with particular information (such as real time performance) and based upon that can signal single or multiple generations of descendant strategies to perform a particular action. This could be anything from moving all limit orders by a certain percentage, to reallocating trading capital among strategies, to pulling all working orders and shutting down.
Apart from allowing extremely sophisticated real time strategy adjustment, this approach has major workflow benefits for any human trader responsible for monitoring the strategies. Instead of trading being limited by the number of strategies the trader is physically capable of manually (re)configuring, the trader can simply take advantage of a cascading strategy configuration to control all strategies with a handful of parent strategies - or perhaps even just one master strategy.
Integrated à la carte
Freeway is tightly integrated with OptionsCity's Algo Store, which is a market for third party Freeway plug ins. These can be purchased to immediately provide specific functionality that the trading firm does not wish to write in house. The range of plug ins is already extensive and (among numerous others) offers functionality to support:
• Gamma / Delta portfolio hedging
• Targeted edge finder
• Automatic order hedging
• Iceberg detection
Further extensibility that delivers access to highly-sophisticated option functionality is also available courtesy of Freeway's close interaction with OptionsCity's Metro product. As a result, complex financial products that incorporate extensive optionality can be easily and automatically traded/hedged/managed.
Like any other business, well-run trading firms look to capture the best opportunities. Over time this can often result in the business moving into completely new areas and types of trading strategy. The tactical and strategic agility to do that depends heavily upon the flexibility of tools and technology infrastructure the firm has at its disposal. Historically this has been limited, so trading firms have either had to make a massive up front capital investment in functionality they might never need, or had to accept that they would probably have to discard, replace and relearn their trading technology every time their businesses changed or expanded. The combination of Freeway, Algo Store and Metro provides an extremely cost-effective means of avoiding these unpalatable alternatives. The business can grow or morph without restriction using technology that can always be tailored to precisely what is actually required, rather than what is available.