State Machines For Trading

A state machine may be the mechanism that you need to organize your model of the market into a winning system. I will explain how a finite state machine (FSM) works and show you a model for a trading system. State machines can be easily created in most programming languages to automate your trading decisions. You can also operate the strategy manually if you wish.

State machines explained

A finite state machine, also referred to as a finite automaton, is a model of a system that shows the different possible states the system can attain and the transitions that occur as the system moves from one state to another. FSMs are used by engineers to model both hardware and software systems. They can also be used to advantage in modeling your trading system.

A simple stoplight will be used to illustrate the key elements of a finite state machine. Figure 1 illustrates the state machine diagram of the stoplight. There are three valid states for the light — red, yellow, and green. The light can be in only one of those states at any given time. The states are represented by the circles and the arrows show the transitions from one state to the next. The states can only move from red to green, from green to yellow, and from yellow to red.

Figure 1: Stoplight state diagram

An event initiates a move from the current state to a next valid state. For our stoplight, we define two types of events that can cause transitions to occur. The most common transition event occurs after the light has been on for a specified period. The red light and green light have on-time periods of 30 seconds each and the yellow light has an on-time of five seconds. A timer keeps track of how long a light has been on and will initiate a transition when the time period has elapsed.

A second event type is defined by the push of a crosswalk button. If a person presses the crosswalk button while the light is red and the light has been on for less than 25 seconds, the timer is advanced to 25 seconds of elapsed time. This causes the transition from red to green to occur sooner to allow the pedestrian to cross.

This is a very simple model that assumes the system has been running eternally, as there is no start state or stop state mentioned. The diagram shown in Figure 1 does not tell us anything about the events that cause transitions. The program that implements the finite state machine must include the rules that trigger events. The rules can be simple, as shown, or quite complex. The sidebar, "Programming a state machine," shows how the stoplight can be implemented using a BASIC-like language. Take a look at the code example to see how the rules are implemented to shift from one state to the next.

A state machine for trading

Figure 2 illustrates a diagram of a finite state machine for a possible trading system. A start state and a stop state have been included to represent entering a position and exiting from it. Let's walk through the state diagram to describe the different states and the events that might trigger a transition.

Figure 2: Trading system state diagram

This trading system assumes that a series of trades will start by triggering a buy order. Transitions between states are initiated by the rules being used to make investment decisions. We will assume that a set of technical indicators has been chosen to be evaluated in each state to decide what action to take. The rules would typically be evaluated each time we receive a new set of data. A daily system would be evaluated with end-of-day data. If the system is connected to a real-time data source, then the current state rules would be evaluated with each new data point.

A daily system would be evaluated with end-of-day data. The design of the state machine incorporates within its structure the dependencies between the rules for each state. The resulting actions depend not only on what the system indicators show but where the system is (that is, the current state). The system does not have to be designed to use the same rules or indicators in each state, so the rules and indicators can be optimized for each state. This combination of flexibility and trading discipline that can be programmed into the state machine can bring power to your trading.

Let's use a simple example based on moving averages. A signal to sell occurs when the closing price falls below the moving average. A signal to buy occurs when the closing price falls above the moving average. Further, we will add to the position if the price falls back by 5% and then rebounds without penetrating the moving average. If you sold and the price recovers by 5% without penetrating the moving average, you can use this as an opportunity to place a short.

Suppose you start with a decision to trade a given issue. In this model, the start rule triggers the event that moves the system to the buy state. The rule for the buy state is quite simple: Make a purchase and transition to the buy hold state. The buy is a transitory state and the system moves to the buy hold state as soon as the purchase is complete. The system can stay in the buy hold state as long as the rules do not indicate a move to a new state.

The rules for a new data point stipulate that no change in state is called for as long as the closing price remains above the moving average. This is illustrated by the transition arrow that loops back to the buy hold state.

As we watch the market and chart the moving average, we see the price drop back, but not enough to trigger a transition to the sell state. Our model rules indicate that this retreat exceeds 5% so the system triggers a transition to the buy add state. Like the buy, this is a transitory state and the system moves back to the buy hold state when the purchase is complete.

At some point, the closing price drops below the moving average, indicating that the move has topped out and a transition occurs to the sell event. This event moves the system to the transitory sell state. From the sell state, two decisions are possible. We may decide to stop trading in this issue completely, or we may decide to continue tracking this stock and move to the sell hold state when the sale is complete. From the sell hold state, the system waits for a penetration of the moving average for a buy signal. A short opportunity could also occur if the price moves up by 5% without penetrating the moving average.

Figure 3 shows a chart and the different states of this model during a selected time period, as might be indicated by rules as I have described. As you can see, most of the time is spent in the buy hold (B) or sell hold (E) states.

Figure 3: Stock closing price with moving average

This is a model representative of a simple stock trading system. Other systems, such as option trading, might be more complex because of the many possible kinds of positions that can be taken, resulting in more states and possible transitions. The state machine provides a logical control structure for organizing the rules of your trading system and an easily programmed method for automating those rules. It is then easy to backtest the system by applying the historical data to the state machine.

Summary

A state machine can be used to provide discipline to your trading system. You can incorporate any number of decision rules for each state. The structure you design can automatically incorporate dependency relationships that might not be obvious or easily modeled by other approaches. As I have shown in the sidebar, the programming of a state machine is not difficult once you have defined the rules you wish to use. However, the idea of the state machine can just as easily be applied to a discretionary trading method.

Glenn Barlis is a system design consultant. He has a master's degree in business administration and a master's degree in computer science.

Sidebar

Programming a State Machine

A state machine can be implemented in any language that provides the IF-THEN-ELSE control structure. The language must also provide for a variable that can hold the current machine state between events. Here is the traffic light example shown in a BASIC-like language. We are assuming that the state machine is run once per second and the machine is started in a known valid state.

Traffic Light State Machine

Static Current_State; holds the machine state
Static Timer; keeps track of how long the
light has been on
Constant green_time = 30; define on-time for lights
Constantyellow_time = 5
Constantred_time = 30

IF Current_State = Green THEN
IF Timer >= green_time THEN
Current_State = Yellow
Timer = 0
ELSE
Timer = Timer + 1
END IF

ELSE IF Current_State = Yellow THEN
IF Timer >= yellow_time THEN
Current_State = Red
Timer = 0
ELSE
Timer = Timer + 1
END IF

ELSE IF Current_State = Red THEN
IF Timer < (red_time - 5) AND Cross_Button_Pushed THEN
Timer = red_time - 5
END IF
IF Timer >= red_time THEN
Current_State = Green
Timer = 0
ELSE
Timer = Timer + 1
END IF

ELSE
{process an error since we should never get here. Current_State can only have one of the three states given above.}

END IF

State Machine Using CASE Statement

Keeping track of all the IF-THEN-ELSE statements can get confusing and makes the program more prone to bugs. Many programming languages offer a form of Case statement to simplify writing this kind of code. Here is the same example using a CASE statement with the Visual BASIC syntax.

Select Case Current_State

Case Green
IF Timer >= green_time THEN
Current_State = Yellow
Timer = 0
ELSE
Timer = Timer + 1
END IF

Case Yellow
IF Timer >= yellow_time THEN
Current_State = Red
Timer = 0
ELSE
Timer = Timer + 1
END IF

Case Red
IF Timer < (red_time - 5) AND
Cross_Button_Pushed THEN
Timer = red_time - 5
END IF
IF Timer >= red_time THEN
Current_State = Green
Timer = 0
ELSE
Timer = Timer + 1
END IF

Case Else
{process an error since we should never get here. Current_State can only have one of the three states given above.}

End Select

The Select Case structure will only select one of the cases based on the value of Current_State. As you can see, this program segment is much easier to understand than the IF-THEN-ELSE example and less likely to have bugs.

A third option for implementing a finite state machine is to use a table-driven state machine engine. This is a more sophisticated method that would be used for complex machines or for commercial software that needs to provide an easy method for user-defined state rules.

— GB