Machines Behind Bars

Introduction

Over the past few years the number and variety of software vendors offering automated trading software to both professional and retail traders has grown significantly. Some of this software has been developed from existing charting packages by adding automation features. The use of bar charts is second nature to most traders and so this seems like an obvious extension of the trading process. However, using bars for automated trade generation introduces new issues that need to be understood in order to achieve reliable results. This bulletin provides some thoughts on some of the issues that arise when using automated order entry systems driven from real-time bar charts.

Automation Process

The current use of bars for automated trading has evolved from the concepts originally developed around mechanical systems based on daily data. Now that near instantaneous electronic trading is possible, the use of simple rule based systems has been extended to real-time automated trading. As an illustrative example, a day trading system using 5-minute interval bar data might have the following rules:

if the time is past 10AM and before 3.45PM then do the following
{
if close price of this bar is greater than the highest price of the previous 6 bars buy on the close of this bar.

if the close price of today is less than the lowest price of the previous 6 days then sell short on the close of this bar.
}

Exit the market at 4PM

An application would create bars using a real-time datafeed so that every five minutes a new bar is available. Once a bar is complete, the rules above can be evaluated and if the appropriate conditions are met then a market order is automatically sent to a broker using the broker's API.
In practice, the rules will probably be more complicated and stop or limit orders may be used, but automating with bars still follows this simple process. For anyone trading in this way, real money is at risk based solely on a set of rules and data that is formatted into bars.

What is a Bar?

Whilst most of effort is rightly spent determining the optimum trading rules, it is also important to consider the process by which the bar data is derived. A bar is an abstraction designed to make it easy for the human eye to discern price. However, the data represented in a bar is very different from the data that is presented on a real-time datafeed and the process of turning raw ticks into bars can vary considerably from one software vendor and feed to another. The trader has traditionally acted as a filter between the chart and the buy/sell button and so subtle differences in the way charts are constructed has not been a critical element in trading. With the trader removed from the trading process, the issue of how bars are derived needs much closer examination.

The Price

Intra-day bar prices are a compressed representation of the price ticks that are received from a real-time datafeed. The majority of charts are created from the price of reported trades, however the mid price or bid or ask price may also be used.

The high and low prices provide a summary of the range of tick prices that were received during the interval represented by the bar. The use of a high and low price makes it easy for the eye to discern the price range but because these prices are limit values, they have the disadvantage of being extremely susceptible to feed errors. A single tick reported with a bad price is all that is required spike the high or low and potentially initiate an unwanted trade.

Bad tick prices, can be cuased by a variety of problems. They may be prices entered in error, however in many cases they are simply the result incorect data handling. Many exchanges report trades that were carried out off-book at prices well away from the market at the time they were reported. The exchanges always report these trades with an indicator but the way this is handled by data revendors varies. These trades may be left out entirely or they may be included and the trade indicator simply discarded. Even when the feed handling is correct, there is a good chance that data is not handled properly in the charting software. The use of quote prices instead of trade prices solves this problem but is susceptible to price spikes if one or other side of the order book temporarily dries up.

To prevent this problem, the data can be filtered at tick level prior to compression into a bar. However, creating filters that work in all markets without removing wanted data is an extremely difficult problem to solve. Many charting packages do not even attempt to filter incoming data and common practice is to rely on the datafeed quality. Hence, there may be no filtering in the system between the incoming datafeed and the rules used to initiate trades.

Price Sampling

Bars were originally conceived to represent a well defined daily trading session with an open and a closing price. For intra-day interval bars, the open and close price is obtained by splitting incoming ticks into time buckets measured against some form of time reference. In the case of one-minute bars, a time reference event will be generated every minute and a new bar will be started on each event. Ticks falling before and after this time event will be incorporated in different bars. This process is similar to sampling and small shifts in the event order may produce bars with quite different OHLC values. For instance, a high value tick that arrives 1ms before the time event will create a bar with a higher high. However, if it falls 1ms after the time event the present high will be at a lower value and a new bar with a higher open is created. For the simple system outlined, these subtle shifts in the event order can mean the difference between a trade being initiated or not.

To understand this process better it is important to understand where the time events are obtained in relation to the price ticks. If the time reference is obtained from the datafeed then the exact pattern of bars is determined by the feed provider. Identical computers running identical software using the same feed provider should always produce the same sequence of bar values.

If the bar time reference is obtained from the local computer clock in any way, then the exact pattern of bars becomes subject to random sampling differences. Small shifts in the computer clock or in the datafeed latency can result in entirely different set of bars being created and a different set of trades. Internet feeds are particularly vulnerable as the internet does not currently specify any quality of service and internet prorogation delays can be very variable.
These timing issues are relative to the bar interval and will have much less impact on hourly bars than they will on minute bars.

Alternatives

Using tick charts where bars are constructed from a fixed number of ticks avoids timing problems entirely. However, tick charts still suffer from the problems of bad ticks and introduce a new problem of missing ticks. If ticks are lost from the feed due to a temporary fault then all subsequent bars will be influenced and the sequence of trades from that point on may be different. Consequently, automating from tick bars has poor robustness to feed failure.

Point and figure chart construction is robust to both tick loss and tick timing issues. However, there is currently very little software available that allows automation from P&F charts and the issues of data filtering also still remain.

Event Driven

Traditional ways of viewing the market were all designed to make it easy for people to view market prices but do not fit particularly well with the process of machine automation. Exchange feeds deliver information in a series of events and rather that compress this information to bars, it is far more logical to drive the trading decision logic directly from the events. This removes the time sampling problems already described and also removes the delay associated with waiting for a bar to be completed. Averaging and filtering may be implemented over a defined tick window and updated on every tick. Missing ticks will only influence the trading decision process for the period they would have been in the averaging window so the method is more robust to feed failure than using tick charts.

Conclusion

Using traditional real-time interval charts for automated trade generation suffers from a number of potential problems. Software and trading algorithms must be carefully designed to allow for these issues if reliable results are to be obtained. Software designed to work directly from unprocessed datafeed events can eliminate these problems and provide a more optimum solution to trading automation.