|
How to Build a Trading System
By PAUL M. KING
Article Contributed By Futures Magazine
Having a complete, robust and profitable trading system or suite of trading systems is the foundation of any successful trading business. Even if you are a discretionary trader, you still need rules that guide your trading decisions and help you to be disciplined and consistent. You also need a process to follow to introduce new trading methods into your repertoire.
We will outline the entire process of trading system development from your initial idea to implementation.
The stages of trading system development are: 1) the idea; 2) hypothesis; 3) research; 4) development; 5) testing; 6) optimization; 7) implementation; and 8) monitoring (see “From start to finish”).
AN IDEA
Every trading system starts with an idea. The idea is a concept that describes some aspect of the way a particular market, or all markets, work. Ideas come from doing research or just observing the markets on a daily basis. Some areas of research that have been beneficial to system development include market gaps, momentum and corporate actions (see “Ideas”).


Whatever inspires it, an idea should make sense and occur with a useful frequency that can be tested. A trading system should come from you. It does not have to be completely original to make money, but you must completely understand why it works to have the confidence to trade the system accurately.
THE HYPOTHESIS
The next step is defining a testable hypothesis based on your idea. It must be possible to find supporting data to test your hypothesis and you must be able to quantify the hypothesis so that it can be programmed and tested.
An example would be: “Because the close of the regular session is an arbitrary halt in trading, futures contracts that have exhibited a significant intra-day move should continue to move in the same direction on subsequent trading sessions.” (This is for illustration.)
To quantify this rule, we must have precise definitions for each of the variables in our hypothesis. This means we have to define which markets we are talking about, which instruments within each market and how big a move constitutes a “significant” one in a particular direction.
The quantification of your hypothesis is split into four parts: Market selection, instrument filter, setup conditions and entry signal.
What market can you apply your idea to? Ideas that are applicable to multiple markets are more valuable than ones that will only work for a single market or instrument.
The instrument filter determines which individual instruments within the selected market will be eligible to trade. This could be based on volatility, price, trading volume or a combination of all of these. It is important that you only include liquid instruments with reasonable volatility to give your system the best chance of overcoming the costs of trading.
The setup conditions are specific rules that must be true to identify a potential trade. In our sample hypothesis, we could say that the contract must have moved 5% from the opening price to signal an entry.
The entry signal is a set of rules that determines whether a trade should be placed. These may be combined with the setup conditions, but it is more usual to have a separate set of rules to signal a trade entry. For example, we might only enter at five minutes before the close if the price is within a certain threshold from the daily high.
For our example we might come up with the following rules: For all front-month futures contracts traded on Globex with an average daily volume of at least 1,000 contracts through the last five days that have more than an X% increase in price from the open to Y minutes before the close of the regular session, enter long at the close if they are within Z ticks of their high for the day (see “Building a trade”).
This represents a testable hypothesis that we can turn into a mechanical trading system to test whether it would have been historically profitable and also creates enough trades to be a useful trading system. At this point in the development of our trading system we have not specified exact values for the variables in our hypothesis (X, Y and Z), that comes later.
The main variables in the hypothesis are called degrees of freedom because each variable can take on multiple values which in essence define a different instance of our trading system. It is important not to include too many degrees of freedom in a system because this may give rise to “curve fitting” our variables to past data, and will result in a system that works very well on historical data, but does not work in real trading. In general, three or four degrees of freedom are usually adequate to describe a good trading system idea.
If you find that you need many variables to describe your system, that is an indication that your idea is too complicated and should be broken down into the simple core aspects.
Once you have simplified and quantified your hypothesis you can move onto gathering the required data and testing the hypothesis. If your idea cannot be quantified in this way, then it is not specific enough and must be adapted so that it can be represented by a set of variables and rules.
Having defined a testable hypothesis, and identified the variables that define the trading system, we can now research the viability of the system. A computer is an invaluable tool for this process. Researching a hypothesis manually is time consuming, tedious and prone to manual and psychological errors because our egos are involved. Research should be biased toward disproving the hypothesis; a lot of promising ideas result in trading systems that are no better than random and cannot overcome the costs of implementing them.
To research our example we would need data that gives us the open and closing price of all front-month Globex contracts, and the open, high, low and close of the following few days. To test through time, we would need continuous contracts. If you have data required by your hypothesis that is not readily available in historical form, you may have to gather and record it through the next few months to have enough to test with. If your variables are based simply on open, high, low, close and volume, you should not have a problem.
Data sources are prone to errors and inaccuracies. Each data vendor has different methods for constructing continuous futures contracts and you should check to make sure that you find their calculation methods acceptable for your particular trading system.
At this point we can calculate the percentage change each day, and choose a number that gives us a reasonable amount of trades. If we want one trade per day, choose the appropriate percentage move.
One possible testing environment is a combination of Microsoft Excel and a secondary product that easily merges historical data into Excel. Excel is a very flexible environment for testing trading ideas because you can use Visual Basic for Application (VBA) code if you cannot achieve what you need in Excel formulas alone. The disadvantages are that there is no built-in structure or formulas specifically designed for implementing and testing trading systems.
Various other trading system testing environments exist that do 80% of the work for you automatically, but it is the 20% that they can’t do that is important. Taking the time to learn how to test your own trading systems is a valuable skill and gives you the confidence not to abandon your systems when they go through an inevitable losing period.
Also, because you will want to change the values of variables at a later stage during optimization, we want an environment where we can change things and automatically see the effect of the changes on the performance of the system.
Now that we have the idea, hypothesis, variables and data that we need, we can develop the system in a testing environment to see if it has any value. The remaining parts of the system that must be defined before we can test it are the position sizing algorithm and the exit signal.
The position sizing rules tell us how much to trade. We will use a simple algorithm that sizes our position so that the difference between our entry price and stop loss is twice the size of the Average True Range (ATR) through the last 10 days and will be equal to 1% of the capital allocated to this system. This is a simple volatility-based position-sizing algorithm.
The exit signal tells us when to close out the trade. We will use a simple trailing stop that is based on twice the ATR. This stop will be moved up after each day’s close by subtracting twice the ATR from the high.
At this point, we will simply use sensible values for the other main variables in the system rather than trying to choose the values that yield the most profit. Our goal is to discover whether the trading system is viable, not to maximize the potential profits during a historical testing period.
TESTING YOUR SYSTEM
Testing a particular trading system is split into three main stages: historical testing, real-time paper testing and small size real money testing
During each phase of the testing we must be able to evaluate how the system is performing and compare different versions of the system at different stages of development. Expectancy is a good way to do this.
To compare different versions of the trading system being developed, we need a way of determining the system’s value and whether it will make money or not. A good way of doing this is called system expectancy. For each trade the system makes, calculate the ratio of profit or loss to the initial risk (as a positive number); this can be referred to as R. Then take the average R to calculate Expectancy (E). The equations for this are:
R = Profit or Loss / Initial Risk
E = Average (R)
Expectancy gives us a measure of how much this system should make on average per unit risk. If you are risking $1,000 on a trade and the expectancy of the system is 0.25, you should make $250 per trade, on average.
Expectancy can be used to compare different versions of a single system, or completely different systems because it is always in the same units (profit per unit risk). So, using expectancy in each case we can compare the results and know exactly how much of the profit or loss is attributable to which aspect of the system: entry, sizing, exit, commissions, slippage and spread.
Obviously, if the expectancy is negative, or goes down, for any of the tests except the one where implementation costs are included, we have a system that does not work or needs modification. Ideally the expectancy should increase after each test.
If the system has positive expectancy after trading costs are factored in, then it is worth moving on to the next stage, which is testing in real-time on paper. If the system has negative expectancy, we can abandon it, modify it, or attempt to optimize the variables to make it work. Optimization of a negative expectancy system should only be considered if it is only the trading costs that are causing the system to lose money.
At this stage, informal optimization can be used to change each of the variables in the system to see how they affect overall expectancy. The system should be positive expectancy within a large selection of values for the main variables. This is what makes it robust. If the system only works with a few specific values for the main variables then it is likely to be a short-term anomaly and will not work for longer periods.
Be wary of a high win percentage. If the system has winning trades more than about 60% of the time, it is likely to be a short-term anomaly and will eventually fail.
HISTORICAL PERFORMANCE
The first level of testing tells you how the system would have performed in the past. Just because a system worked well in the past does not mean it will work well in the future. However, given a choice between a system that has always lost money and one that has made money, which one has the best chance?
During historical testing, each component of the system should be tested independently before being combined. We have four types of tests.
1. Entry signal + fixed position size + fixed exit signal
2. Entry signal + fixed position size + variable exit signal
3. Entry signal + variable position size + variable exit signal
4. Entry signal + variable position size + variable exit signal + implementation costs
In the first test, we would only trade one contract and exit after a fixed time. In the second test we would introduce a profit-taking or trailing stop that would allow profits to run on longer for trades that are big winners. In the third test we would position-size as a percentage of capital allocated to the system based on previous trades so that as the system wins it can risk more. In the final test we would test the entire system by including a calculation for commissions and how much the entry and exit price should differ from the historical prices in our test data. A system has to be profitable enough to overcome trading costs and the inevitable slippage (the difference in price between your entry or exit and where you are filled).
Assuming the system has positive expectancy through a number of years, we can fix the main variables at a value that yields the desired number of trades and move on to real-time paper trading.
Assuming the historical testing of the system yields positive results, we test the system on paper in real-time. This proves that we have not backfitted the system to the data and demonstrates that the signals are generated at the desired frequency.
Monitor the market and instruments for setup and entry signals and record the trades that are entered on paper. Apply the relevant position sizing and exit signals and calculate the R multiple for each trade. Be sure to include implementation costs and a reasonable allowance for slippage.
At least 30 trades should be tested in real-time without changing any aspect of the system. If the system still is exhibiting positive expectancy similar to the historical testing, it is time to trade it for real with small positions. If you decide to change any value or rule of the system during this testing period, remember to go back and do the historical test and then start the real-time paper testing again.
The real-money testing is designed to make sure the system can be implemented as you have designed it. Minimal position sizing should be used. Because of that, the implementation costs will be a much higher proportion of the trade value than with full-size positions. We are not trying to make money here, just test that we can implement the trading system accurately with reasonable slippage.
OPTIMIZATION
We now have a positive expectancy system that we have tested historically on paper in real time and with small size positions. Before we implement it with full-size positions we need to decide whether we want to optimize any aspect of the system.
Optimization can be used in three ways: to find sets of values for the main variables that work to turn a negative expectancy system into a positive one, to find the best historical performing system and to find the possible range of variables that works best and choose ones that are in the middle of this range.
Optimization should only be used in the last case. It can be used to find sets of values that work for a system, but only if there are many closely related instances of positive expectancy. Again, isolated instances of high-expectancy is a strong indication that the system is an anomaly and will not work in real trading.
The easiest way to optimize a trading system is to step through each value of the main variables and run your historical testing after each step. You then can construct a table that shows for each main variable value the expectancy of the system. Then choose a version of the system that has the median expectancy rather than highest.
IMPLEMENTATION
Now that we have a profitable, optimized and efficient version of our trading system, we can incorporate it into our trading environment and give it a full allocation of trading capital. Implementation is in two parts: first, we must automate as much of the system as possible to minimize implementation mistakes and the time it takes to operate. Next we allocate the system capital.
Automation of a trading system is different for each system and trader. Longer-term systems that take signals using end-of-day data for the following open, have relatively wide stops and hold positions for weeks or months require very little automation and can be manually monitored in a few minutes after each close.
For systems that take multiple signals per day and hold positions for only a few minutes, maximum automation is needed. Most electronic brokers offer an Application Programming Interface (API) to your account that you can use to automate a trading system. Alternatively, some brokers specialize in automation of trading systems on your behalf.
A simple capital allocation rule for a new system would be to allocate available capital to all systems currently being traded in proportion to their expectancy. This would reward the better systems with more capital. If position sizing is based on the current allocation to each system, as we make money, it can take larger positions or smaller ones when it loses.
Knowing whether a system is losing money requires performance monitoring. This should consist of recalculating the expectancy after every closed trade and making sure it has not become negative throughout the last 50 trades. If the expectancy throughout the recent trades has become negative, suspend real-money trading and go back to paper trading until the expectancy returns to normal. And if the original hypothesis your system is based on becomes invalid, suspend trading immediately.
The bottom line is that developing a trading system should be a controlled and well-thought-out process. It should not be approached haphazardly and should not gloss over vital steps that are necessary for long-term trading success.
Paul King is a proprietary trader, trading coach and independent financial advisor in Vermont at his company PMKing Trading LLC. He can be reached at www.pmkingtrading.com. E-mail: futuresmag@pmkingtrading.com
See also
|