The growth in the electronic trading of stocks, futures and options and the accompanying increase in volume, lower commissions and speed of order execution have created market data networks that support high frequency trading by the retail customer, provided the trader has adequate computing and network bandwidth. In this regard, the latest generation of PCs and high-speed Internet broadband access complete the necessary technical infrastructure for high frequency retail trading. The individual trader is able to keep pace with the sophisticated institutional trading desks while maintaining the flexibility inherent in independent, small-scale trading decisions.
Desktop trading platforms now offer the individual trader an abundance of tools and historical data for developing, backtesting and executing automated strategies. Without the need to trade at volumes of large commercial funds, the individual has the opportunity to profit from the confluence of new trading technology and electronic markets at high trade frequencies.
High frequency automated trading comes with a set of hurdles that must be overcome. Managing data feeds at tick granularities and finding practical means of backtesting high frequency strategies are two of the most challenging obstacles.
TRADE AUTOMATION
Trade strategy algorithm development, backtest and execution are now wide-spread. Discretionary trading is increasingly being replaced with trade strategies that can be backtested to determine efficacy and executed automatically or semi-automatically with a goal of reducing human emotion from the trade equation. Swing-trade algorithms can be programmed, backtested and tuned by the individual trader and then executed against the market with little real-time oversight.
“Double your pleasure” shows an implementation of a well-known pairs strategy trading the Nasdaq 100 vs. the DIA exchange-traded fund. Backtesting with appropriately tuned inputs shows a 30% annualized rate of return trading one lots with an initial $5,000 margin. Swing-trade systems can be programmed, tested and executed relatively easily using the latest desktop technologies. Trades may be manually placed from program generated signals or, for the more sophisticated, entirely automated in trade strategy code.
Backtesting swing-trade automation has become relatively straightforward. The developer looks to minimize trade strategy input parameters, backtest convincing histories (1, 3, 5, 10+ year durations) and measure key outputs: win-loss percentages, maximum number of sequential losers, maximum drawdown, RINA scores, etc. Once the trader has become comfortable with back-test results, a trade strategy can be brought online.
Success with swing-trade automation typically leads the developer to investigate higher frequency intraday strategies to take advantage of the inherent benefits such as no overnight positions and low margin requirements. However, moving to high frequency automated trading, which may be based on tick level data, introduces new automation challenges.
HIGH FREQUENCY AUTOMATION
When considering high frequency trade automation, today’s trader has a wide variety of direct-access PC-based trading platforms to choose from, such as TradeStation, eSignal and Interactive Brokers. These trading desktops provide real-time data, down to the tick, sophisticated charting and indicator tools and typically a means of automating trade strategies, including the ability to run strategy automation against the market. Strategy development and execution may be accomplished from an entirely self-contained programming environment and/or by integrating more traditional programming into the platform; for example, integrating Microsoft.NET or similar programming into the user’s strategy development environment. “Road to automation” shows the TradeStation desktop architecture from the view of the strategy developer.
High frequency trade strategies are appealing specifically because they represent trades that only are feasible when automated by computer-based systems over high-speed electronic networks. They require additional support beyond what typically is provided for swing-trade automation. This includes the ability to generate signals and trades from tick data, manage a high frequency strategy backtest and an accurate synchronization between the high frequency strategy code and the trade network and exchange electronic order book.
EXECUTION AND BACKTESTING
Moving from minute charts to tick charts typically is not an issue for strategy logic development. What may have worked across longer time frame charts can be modified to work on tick charts. What can get in the way of high frequency strategy development is the sheer volume of tick data and the difficulty accessing long-term tick-based historical data. Data vendors may limit available tick data for back-testing to days or weeks, and the download requirements of longer-term tick-based histories can overwhelm the average developer.
One approach to managing the sheer volume of tick data is to develop strategies to the smallest time increment, like one-minute bar charts, and then port the strategy to tick data to improve key performance aspects of the strategy.
Using this technique, a strategy’s indicators and signal logic are first developed and backtested on one-minute charts. If backtesting shows good performance, then the strategy is ported to tick data. Porting to tick data allows strategy limit orders to be filled as strategy market orders when tick-based price limits are touched and stop-loss market orders are executed on the next tick, eliminating gaps that may exist in stop-loss order execution when time-based charts are used. For example, there is no time delay between when the market is entered and when a stop-loss order is activated, as the next tick becomes the next bar for strategy order execution. Working with tick data gives the high frequency developer complete control over strategy execution without relying on less transparent intra-bar order execution, which also may be offered by the desktop environment.
Assuming good one-minute backtest results, the tick-based strategy can be compared against recent one-minute results using recent tick data. For example, the last 30 days of the one-minute strategy results can be compared against the last 30 days of one-tick data strategy results. If the backtest results are comparable, then the one-tick based strategy can be relied on to replicate the long-term performance measured using one-minute charts, while achieving the tick-based fill performance described above. “Ticking profits,” shows a well-known mean reverting strategy developed and backtested on one-minute charts (top chart), which was then ported to one-tick charts (bottom chart) for execution.
TRADE SYNCHRONIZATION
Any automated trade strategy must remain synchronized with the trade network and exchange order book to function correctly. In short, what the strategy code “sees” as the current trade status (flat or open position, resting limit orders, number of shares/contracts open, etc.) must be consistent with the live account status. This requirement is even more pronounced with automated high frequency trading, where tens or hundreds of trades may be opened and closed throughout a single trading session.
The current generation of desktops that support automation offer self-contained programming and order execution environments that facilitate rapid implementation and automation of trade strategies. Also, as part of a desktop, and situated between the user’s strategy code and the broker’s trade network, resides sophisticated middleware to relieve the programmer from many of the complexities of a fully automated strategy. TradeStation middleware is referred to as the TradeManager and includes support for stop-loss, profit-target and trailing stop logic automation.
Importantly, the TradeManager includes logic to ensure that the trader’s strategy code and actual account position remain synchronized. For example, if an order is partially filled, the TradeManager attempts to ensure that the strategy code and the outstanding orders in the trade network remain synchronized until the position is closed, either through additional partial fills or because the strategy moved to a new order state where previously entered orders were cancelled.
The current generation of automated trade desktops implement strategy-account synchronization using what is known as “synchronous user interfaces.” This type of user interface is designed to ensure that a trade strategy program remains synchronized with the external environment by hiding inherent conflicts between the trade desktop and order execution network within the interface and the underlying middleware. In this way the trade strategy code may count on an operation being completed when the interface returns control to the strategy code. For example, the user is guaranteed that a call to an interface that buys the market at a limit price has, on return from the call, a limit order in the market bid queue.
But what happens when partial fills occur? Synchronization between the trade desktop and the order execution network becomes problematic when the trade desktop is testing the state of an order while simultaneously the order execution network may be filling orders. Swing trade systems, which place orders infrequently compared to a high frequency intraday system, typically do not see discrepancies between the strategy state and the order execution network; and if there are discrepancies, then they can be readily corrected by manual intervention. This is why the current generation of strategy trade desktop vendors state that trade automation is not meant to run stand-alone and all automation must be continuously monitored. If high frequency strategy automation is the goal, and trade decisions are so numerous as to be beyond the scope of manual intervention, then inherent difficulties between the synchronization of the trade desktop and the order execution network must be overcome.
One approach, at least in the case of the electronic futures market, is to use single contract orders, and then replicate the trade strategy up to the size of the desired positions. The current generation of PCs and high-speed Internet connections can support this kind of replicated single transaction approach. Of course, the downside for the trader is that single limit orders are placed in bid-ask queues. If account bunching occurs at the exchange order queues, or a relatively small number of contracts are being traded (10 or fewer) problems of replicated orders can be tolerated. Moving to tick data for strategy execution does provide the low-latency trade signals needed to support multiple order entry.
NULL HYPOTHESIS
When high frequency trade strategies are attempted, it is imperative that a null hypothesis test be performed. A null hypothesis test attempts to show that the positive performance of a strategy is not the result of the trade management techniques instead of the strategy itself.
The test is constructed by randomly entering the market at the frequency of the actual strategy and using the strategy’s trade management to exit trades. If the null hypothesis test gives a negative result, then the strategy trade entry logic has merit.
LIVE VS. BACKTEST RESULTS
One benefit of high frequency trading is the large number of trades generated during backtest. This is valuable in evaluating a strategy, because when the number of successful historical data points is large, a strategy may have merit beyond what might be a lucky coincidence from a small number of trades.
Assuming there is enough backtest data, both in- and out-of-sample, to demonstrate a viable strategy, the developer can generate an expected profit calculation based on target-profit and stop-loss levels; the win/loss percentages reported from backtesting, and commissions. With a positive calculation, one can proceed to live trading and begin to compare the expected result with actual trade results.
During the initial period of live trading, two sets of data are maintained: the strategy reported trades and actual strategy trades against the market.
The data are used to determine if actual trading is matching the expected results. When serious deviations are encountered, the developer must determine how the live trade environment is effecting automation and producing less than expected results.
Actual trading and backtest results can vary. This is particularly true with high frequency strategies that generate many more signals. It is the job of the developer to determine the reason for discrepancies between the strategy backtest and actual trade results. There may be a flaw in the underlying strategy, an erroneous assumption made by strategy backtest, or an out-right bug in strategy code that only appears when trading against the market. Many of the latest trading desktop environments now support a simulation mode where early testing can proceed without risking actual dollars.
One common example of overly optimistic strategy backtest is due to the inherent difficulty in computing trade results after the fact. Specifically, strategy backtest has, for any duration bar, only open, high, low, close (OHLC) values for the bar. Consider a long position. If the strategy assumes the high price was first reached during the bar’s duration, and a target profit level is equal to or less than the high price, then the strategy will close a profitable trade. But what if the low price was actually touched first and that low price was at or less than the stop-loss level for the strategy? Then in live trading, the strategy would have a loser. Platform vendors will often use a simplistic algorithm for disambiguating the OHLC sequence: If H-O < O-L then the high price is assumed to have first been reached; otherwise the low price is assumed first (see “What came first?” below). It is this type of backtest error that must be reconciled and dealt with when comparing backtest results to actual trade results. One advantage of high frequency strategies is that by moving to one-tick data, errors like the OHLC ambiguity can be minimized.
The trading world has changed dramatically from the days when a retail trader waited up to an hour or more to know the status of an order or when a filled order could sit endorsed on the pit floor with fast market conditions. The current generation of desktop trading platforms, high-speed Internet access and highly liquid electronic markets offers the retail trader an opportunity to participate in automated high frequency trade strategies. This is a new trading environment that is tremendously appealing and offers opportunities if the strategy developer is able to manage certain inherent complexities of high frequency automation. Managing data at the tick-level, dealing with strategy and market synchronization and bringing a strategy online with a discipline that closely measures live trade results against expectations are important.
Innovations in technology and ultra- competitive brokerage costs have created revolutionary opportunities in high frequency trading and those revolutionary opportunities have made their way down to the retail level. High frequency automation may be the next frontier for the retail trader wishing to test today’s evolving electronic markets.
Michael Gutmann was a software engineer at Intel for 20 years. He is co-author of 10 U.S. patents in areas of video conferencing, digital video and computer architecture. Currently he manages CTA VGX Capital LLC, and can be reached at mike@vgxcapital.com.