Currency Secrets

If you’ve created a system before you would’ve no doubt arrived at a point where you would’ve needed to test certain variable(s) to see which figure(s) would be the most appropriate to use.

As an example, if we were testing a simple moving average crossover system on closing prices we would test which moving average periods would be the best to use – these moving average periods are what I term as variables.

Unfortunately most new forex traders test every number known to mankind and proceed to test all of these numbers over their entire historical data. Once the computer has churned out a database of results the trader looks at which variables produce the best Net Profit and then trades those “best” variables.

And the money just comes rolling in by the bucket loads, doesn’t it?

Hardly.

I wonder what the trader would’ve been using had they ran their optimization last month? Or maybe 3 months ago? Would the variables have been the same?

What then does the importance of NOW have over one month ago? Or three months ago?

The only real difference between now and back in the past is more historical data to test over, but what of the future? What if one week from today the best variable(s) to use are different? How often should one change their system’s variables? Every time? Even during a trade?

As you can see optimizing can be very detrimental to your forex system – just when you thought you were safe in finding the best variable a whole bunch of new ones enter!

So what do we do?

One solution is to conduct a walk-forward optimization (WFO).

A what?

In its simplest form WFO allows users to test their system by allowing the computer to automatically test the variables used and, according to the system’s results over the testing period, use the best variable(s) for a predetermined period before re-testing again.

As an example, if we have a WFO on our moving average crossover system, we would test a whole different bunch of numbers for the moving averages over a period of say 3 years (if we’re using end-of-day data) and we instruct the computer to use the best variables that returned the highest Net Profit over the sample period to use over the out-of-sample period being the next 3 months. In 3 month’s time we then repeat the process again: test the system over the last 3 years, locate the best variable(s) that produced the highest Net Profit, use those variables to trade over the next 3 months.

Okay so now the money should start rolling in, right?

Well, the great thing about WFO is that it tests your system’s foundation – as too many people place far too much emphasis on finding the right “magic” number rather than putting in that effort on the method used.

But WFO does have its problems and if you ever do use WFO on a system you’ll more than likely find your systems results rather dismal.

There are several reasons for this with the most obvious being that the system needs 1 in-sample period where no trades will be conducted. Depending upon how large your in-sample testing period is as compared to your overall historical sample you could find that 20-30% could be lost. As an example, if you have a large in-sample testing period, of say three years, and the entire historical sample of your data is 4 years in length then 75% of your data will not be traded, therefore your results will be reduced by 75% than an otherwise simple optimization over the ENTIRE period would make!

Another not-so-obvious reason is that WFO’s (such as those created in Wealth-Lab Developer) only allow one constraint. This means that if we tell the WFO to use the best variables for our trading period those that produce the highest Net Profit (or whatever constraint we use) during the testing period if there just so happens to be a variable that produces one trade yet luckily enough ends up producing the highest Net Profit the WFO will use those variable(s) for the trading period.

“But who cares?” you might say, “it produced the highest net profit.”

Well would you really want to trade a system that had ONLY 1 trade??

Of course not!

So why should your WFO tests be any different?

And this is where WFO testing falls down – it’s lack of additional constraints.

Unless you can tailor a WFO to contain constraints that you personally use when selecting whether a system is feasible or not I’d be very wary of using it.