A robust trading strategy has to meet several criteria:

• It must exploit a real and significant market inefficiency. Random-walk markets cannot be algo traded.
• It must work in all market situations. A trend follower must survive a mean reverting regime.
• It must work under many different optimization settings and parameter ranges.
• It must be unaffected by random events and price fluctuations.

There are metrics and algorithms to test all this. The robustness under different market situations can be determined through the R2 coefficient or the deviations between the walk forward cycles. The parameter range robustness can be tested with a WFO profile (aka cluster analysis), the price fluctuation robustness with oversampling. A Montecarlo analysis finds out whether the strategy is based on a real market inefficiency.

Some platforms, such as Zorro, have functions for all this. But they require dedicated code in the strategy, often more than for the algorithm itself. In this article I’m going to describe an evaluation framework – a ‘shell’ – that skips the coding part. The evaluation shell is included in the latest Zorro version. It can be simply attached to any strategy script. It makes all strategy variables accessible in a panel and adds stuff that’s common to all strategies – optimization, money management, support for multiple assets and algos, cluster and montecarlo analysis. It evaluates all strategy variants in an automated process and builds the optimal portfolio of combinations from different algorithms, assets, and timeframes. 

The process involves these steps: 

The first step of strategy evaluation is generating sets of parameter settings, named jobs. Any job is a variant of the strategy that you want to test and possibly include in the final portfolio. Parameters can be switches that select between different indicators, or variables (such as timeframes) with optimization ranges. All parameters can be edited in the user interface of the shell, then saved with a mouse click as a job. 

The next step is an automated process that runs through all previously stored jobs, trains and tests any of them with different asset, algo, and time frame combinations, and stores their results in a summary. The summary is a CSV list with the performance metrics of all jobs. It is automatically sorted – the best performing job variants are at the top – and looks like this:

So you can see at a glance which parameter combinations work with which assets and time frames, and which are not worth to examine further. You can repeat this step with different global settings, such as bar period or optimization method, and generate multiple summaries in this way. 

The next step in the process is cluster analysis. Every job in a selected summary is optimized multiple times with different walk-forward settings. The result with any job variant is stored in WFO profiles or heatmaps:

After this process, you likely ended up with a couple survivors in the top of the summary. The surviving jobs have all a positive return, a steady rising equity curve, shallow drawdowns, and robust parameter ranges since they passed the cluster analysis. But any selection process generates selection bias. Your perfect portfolio will likely produce a great backtest, but will it perform equally well in live trading? To find out, you run a Montecarlo analysis, aka ‘Reality Check’.

This is the most important test of all, since it can determine whether your strategy exploits a real market inefficiency. If the Montecarlo analysis fails with the final portfolio, it will likely also fail with any other parameter combination, so you need to run it only close to the end. If your system passes Montecarlo with a p-value below 5%, you can be relatively confident that the system will return good and steady profit in live trading. Otherwise, back to the drawing board.

The use case

For a real life use case,  we generated algorithms for the Z12 system that comes with Zorro. Z12 is a portfolio from several trend and counter trend algorithms that all trade simultaneously. The trading signals are generated with spectral analysis filters. The system trades a subset of Forex pairs and index CFDs on a 4-hour timeframe. The timeframe was choosen for best performance, as were the traded Forex pairs and CFDs. 

We used the evaluation shell to create new algos, not from a selected subset, but from all major Forex pairs and major index CFDs, with 3 different time frames from 60, 120, and 240 minutes. 29 algorithms passed the cluster and montecarlo analysis, of which the least correlated were put into the final portfolio. This is the equity curve of the new Z12 system:

Other performance parameters, such as Profit Factor, Sharpe ratio, Calmar Ratio, and R2 also improved by more than 30%. The annual return almost doubled, compared with the average of the previous years. Nothing in the basic Z12 algorithms has changed. Only new combinations of algos, assets, and timeframes are now traded.

The evaluation shell is included in Zorro version 3.01 or above. Usage and details are described under https://zorro-project.com/manual/en/shell.htm.  Attaching the shell to a strategy is described under https://zorro-project.com/manual/en/shell2.htm.

In the TASC July 2026 issue, Markos Katsanos suggests a solution for a better stock rotation system. He applies two twists: Excluding the top performers, which often experience a reversal to the mean, and filtering out bear market situations. This improves stock rotation systems a lot.

The code of his system is unfortunately written in Amibroker languge, which means that for using it with any other platform, one must rewrite it from scratch. Amibroker does not use buy or sell orders. Instead it has a ‘portfolio rotation mode’ that is set up with many variables. Zorro’s C language has no special rotation mode, but uses buy and sell orders for rotating, just as for any other strategy. This requires rewriting the Amibroker code, but the positive side is that the script becomes much shorter and easier to comprehend.

var Score[1000],Weights[1000];

void run()
{
  StartDate = 2012;
  EndDate = 2025;
  BarPeriod = 1440;
  LookBack = 252; // 1 year

  Capital = slider(1,10000,0,20000,"Capital","");
  assetList("AssetsNASDAQ");
  assetAdd("QQQ","STOOQ:QQQ"); // for the bear market detection
  asset("QQQ");
// set up variables
  int MaxOpenPositions = 15;
  int ROCBars = 100;
  int ExitBars = 20;
  int MAPeriod = 300;
  int ExcludeTopN = 2;
// bear market filter
  var MAQQQ = ZMA(seriesC(),MAPeriod);
  bool Bear = MAQQQ < ref(MAQQQ,1);
  if(Day%ExitBars == 0) {
// assign a score to any asset
     for(listed_assets) {
       asset(Asset);
       if(Asset == "QQQ" || Bear)
         Score[Itor] = 0; // don't trade the index
       else
         Score[Itor] = ROC(seriesC(),ROCBars);
     }
// exclude the N top scores
     int i;
     for(i=0; i<ExcludeTopN; i++)
       Score[MaxIndex(Score,NumAssetsListed)] = 0;

// rotate the positions
    distribute(Weights,Score,NumAssetsListed,MaxOpenPositions,0.5);
     rotate(0); // decrease positions
     rotate(1); // increase positions
   }
}

We’re loading all NASDAQ stocks from an asset list (AssetsNASDAQ), and add the ‘QQQ’ index ETF because we’re needing that for the bear market filter. The MAQQQ variable holds the average index value, determined with a zero-lag moving average (ZMA). The ZMA has two advantages over a standard moving average: faster reaction (as the name says) and not needing a long data history. We assume a bear market when the average is falling.

Next, we check if we have reached the rotation date (Day%ExitBars is the number of days since start modulo the number of days for a rotation). If so, we loop over all assets and assign every one a score, depending on its N-day rate of return (ROC). The Itor variable is the number of the asset in the loop. The QQQ index gets no score, and in a bear market none of them gets a score.

Next, we remove the two top performers, since we assume they are overbought. The distribute function takes the scores and converts them to weights, while all weights sum up to 1. The function can be looked up in the Zorro manual (https://zorro-project.com/manual/en/renorm.htm). Finally we perform the actual rotation. This is a bit tricky, because we need two steps. The first step reduces all positions that ought to be reduced. The second step increases all positions that ought to be increased. This order is important, because if we increased a position first, the total volume could exceed our capital on the broker account.

The rotate function is not a Zorro function, but just assigns new position sizes to any asset of the portfolio:

void rotate(int Buy)
{
  for(listed_assets) {
    asset(Asset);
    int NewLots = Capital*Weights[Itor]/MarginCost;
    if(NewLots < LotsPool)
      exitLong(0,0,LotsPool-NewLots);
    else if(Buy && NewLots > LotsPool)
      enterLong(NewLots-LotsPool);
  }
}

Since I see from Markos Katsanos’ code that he optimized his variables, I have to do the same. For this, his variables now get optimization ranges:

set(PARAMETERS); // parameter optimization
setf(TrainMode,TRADES|GENETIC); // size matters
int MaxOpenPositions = optimize(15,5,30,5);
int ROCBars = optimize(100,50,250,50);
int ExitBars = optimize(20,10,50,5);
int MAPeriod = optimize(300,100,1000,100);
int ExcludeTopN = optimize(2,1,5,1);

We’re using genetic optimization with considering the trade volume (TRADES|GENETIC). The optimization takes about one minute. It’s in-sample, so take the result with a grain of salt. This is the equity curve resulting from a backtest:

In the backtest, we’re reinvesting profits; for this replace Capital with Equity in the rotate function. The blue bars are the account equity, the black line is the QQQ index. We can see that the account has far less drawdowns than the index. The black line in the small chart below is our trade volume, which is zero when a bear market is detected. The green line is the QQQ average, with bear market situations indicated in red. In 2022, the year when the Russian attack on Ukraine began, the system did not trade at all since the bear market filter was active almost the whole year.

The system produces 32% CAGR, with a 14% worst drawdown. This replicates Markos Katsanos’ results, but again, keep in mind that this is from an in-sample optimization. When applying walk-forward optimization (left as an exercise to the reader :), the CAGR goes down to 22%. Still a good performance, well beyond the NASDAQ index.

The code can be downloaded from the 2025 script repository.

Let’s first code the bands. They are simply a regression line moved up or down so that it crosses through the highest and lowest price peaks and valleys. Here’s the piece of code in C:

var Slope = LinearRegSlope(seriesC(),N);
var Intercept = LinearRegIntercept(seriesC(),N);
var LinVal, HighDev = 0, LowDev = 0;
for(i=N; i>0; i--) {
  LinVal = Intercept + Slope*(N-i);
  HighDev = max(HighDev,priceC(i)-LinVal);
  LowDev = min(LowDev,priceC(i)-LinVal);
}

N is the number of bars for which the regression line is calculated. The line has the formula y = b + m*x, where b is the intercept and m the slope. The code generates both for the previous N bars, then calculates in the loop the maximum and minimum deviations (HighDev, LowDev). The regression value (LinVal) is calculated from the intercept and slope with the above formula. Since the bar offset i runs backwards from the current bar, the bar number that’s multiplied with the slope runs from N down to 0. Here’s the code applied to a SPY chart from 2025:

The candles can exceed the upper and lower bands because only the close price is used for the bands. It would probably improve the system, at least in theory, when we used the high and low prices instead.

Kaufman suggests several methods of trading with these bands; we’re here using the ‘Inside Channel’ method since it is, according to Kaufman, the most profitable. We open a long position when the price comes within a zone around the lower band, and close the position (or open a short position) when the price comes within a zone around the upper band. Here’s the complete trading system in C for Zorro, using the above code to calculate the bands.

void run()
{
  BarPeriod = 1440;
  StartDate = 20100101;
  LookBack = 150;
  assetList("AssetsIB");
  asset("SPY");
  if(is(LOOKBACK)) return;

  int i, N = 40;
  var Factor = 0.2;
  var Slope = LinearRegSlope(seriesC(),N);
  var Intercept = LinearRegIntercept(seriesC(),N);
  var LinVal, HighDev = 0, LowDev = 0;
  for(i=N; i>0; i--) {
    LinVal = Intercept + Slope*(N-i);
    HighDev = max(HighDev,priceC(i)-LinVal);
    LowDev = min(LowDev,priceC(i)-LinVal);
  }
  var Zone = Factor*(HighDev+LowDev);
  if(!NumOpenLong && priceC(0) < LinVal+LowDev+Zone)
    enterLong();
  if(!NumOpenShort && priceC(0) > LinVal+HighDev-Zone)
    exitLong();
}

We’ve selected the AssetsIB asset list, which contains the margins, commissions and other parameters from an US broker (IBKR). So the backtest simulates trading with IBKR. The resulting equity curve with the default parameters, N = 40 and Zone Factor = 20%, already shows promise with a 2.8 profit factor:

However, Kaufman mentioned that he tested N values from 20 to 150, and zone factors from 5% to 50%. We’ll do the same by optimizing these parameters. Of course a backtest with the best optimization result would be meaningless due to bias (see https://zorro-project.com/backtest.php). Therefore we’re using walk forward optimization for an out-of-sample backtest. Since anything with Zorro is done in code, we’ll insert 4 lines of C code for the optimization:

set(PARAMETERS); // optimize parameters
NumWFOCycles = 5;
N = optimize(40,20,150,10);
Factor = optimize(0.2,0.05,0.5,0.05);

We also changed the trading from only long positions to long and short by replacing exitLong with enterShort By default, entering a short position automatically exits the long one, and vice versa. So the system is always in the market with 1 share, either long or short. The walk forward optimization takes about 3 seconds. This is the resulting equity curve:

The profit factor rose to 7, with a 76% win rate – not bad for such a simple system. The code can be downloaded from the 2025 script repository on https://financial-hacker.com. 

For his loop chart, Ehlers filtered the low and high frequencies out of the two data series with a roofing filter. Its code in C for Zorro:

var Roofing(var *Data,int HPeriod,int LPeriod)
{
  var f = 1.414*PI/HPeriod;
  var hpa1 = exp(-f);
  var hpc2 = 2*hpa1*cos(f/2);
  var hpc3 = -hpa1*hpa1;
  var hpc1 = (1 + hpc2 - hpc3) / 4;
  f = 1.414*PI/LPeriod;
  var ssa1 = exp(-f);
  var ssc2 = 2*ssa1*cos(f/2);
  var ssc3 = -ssa1*ssa1;
  var ssc1 = 1 - ssc2 - ssc3;

  vars HP = series(0,3);
  HP[0] = hpc1*(Data[0] - 2*Data[1] + Data[2]) + hpc2*HP[1] + hpc3*HP[2];
  vars SS = series(HP[0],3);
  SS[0] = ssc1*(HP[0] + HP[1])/2 + ssc2*SS[1] + ssc3*SS[2];
  var Scaled = EMA(SS[0]*SS[0],.0242);
  return SS[0]/sqrt(Scaled);
}

For demonstration purposes we apply that filter to the FDX price and volume series. The filtered data points serve as XY coordinates for our curve – the “Ehlers Loop”. The following script reads 3 months stock data from an online source and displays it in a scatter plot where the XY points are connected with splines:

function run()
{
  StartDate = ymd(wdate(NOW)-90); // 90 days before today
  BarPeriod = 1440;
  asset("FDX");
  var PriceRMS = Roofing(seriesC(),125,20);
  var VolRMS = Roofing(series(marketVol()),125,20);

  if(is(LOOKBACK)) return; // don't plot the lookback period
  plotGraph("Loop",VolRMS,PriceRMS,DOT|GRAPH,BLUE);
  plotGraph("Loops",VolRMS,PriceRMS,SPLINE|GRAPH,TRANSP|GREY);
  if(is(EXITRUN))
    plotGraph("Last",VolRMS,PriceRMS,SQUARE|GRAPH,RED);
}

The plotGraph function is used to display each coordinate with a blue dot. The last day is marked with a red square.

Ehlers intended his loops for discretionary trading, but it can of course also be automated. For instance, the last N coordinates could be used as inputs for Zorro’s neural net, which can then be trained to predict tomorrow’s price. Or even simpler, the slope of a polynomial regression through the last points could trigger a buy order when positive, or a sell order when negative. You can use Zorro’s polyfit function and filter with the regression error. I leave this trading system as an exercise to the reader.

The same method can be used to compare a stock with an index for a pairs rotation strategy. We’re using RTX and SPY:

function run()
{
  BarPeriod = 1440;
  LookBack = 300;
  StartDate = 20210801;
  EndDate = 20211130;

  assetAdd("RTX","YAHOO:*");
  asset("RTX");
  var Y = Roofing(seriesC(),125,20);
  assetAdd("SPY","YAHOO:*");
  asset("SPY");
  var X = Roofing(seriesC(),125,20);

  if(is(LOOKBACK)) return;
  plotGraph("Loop",X,Y,DOT|GRAPH,BLUE);
  plotGraph("Loops",X,Y,SPLINE|GRAPH,TRANSP|GREY);
  if(is(EXITRUN))
    plotGraph("Last",X,Y,SQUARE|GRAPH,RED);
}

The resulting chart for the period from August to November 2021:

I found that Ehlers’ roofing filter is sensitive to the lookback period. It needs some time to ‘swing in’. A too short lookback period, like Zorro’s default 80 bars, produces a visibly different loop. With 300 bars we’re on the safe side.

What can you now do with this loop chart? Ehlers proposed to switch between stock and index depending on the loop rotation and angle quadrant. Our example above, with the SPY index on the Y axis and the stock on the X axis, has a clockwise rotating loop. On clockwise rotations, buy the stock and sell the index from 5 to 10 on the clock face. Sell the stock and buy the index from 11 to 4. Be out of the market between 4 and 5, and have both positions between 10 and 11.

On a counter clockwise rotation, do just the opposite. This was intended for discretionary trading, but can of course be automated with a script. Which I also gracefully leave to the reader.

The Roofing indicator and the Ehlers Loop scripts can be downloaded from the 2022 script repository. The Zorro software can be downloaded from https://zorro-project.com.

Suppose you’re developing an algorithmic trading strategy, following all rules of proper system development. But you are not aware that your trading algorithm has no statistical edge. The strategy is worthless, the trading rules equivalent to random trading, the profit expectancy – aside from transaction costs – is zero. The problem: you will rarely get a zero result in a backtest. A random trading strategy will in 50% of cases produce a negative backtest result, in 50% a positive result. But if the result is negative, you’re normally tempted to tweak the code or select assets and time frames until you finally got a profitable backtest. Which will happen relatively soon even when applying random modifications to the system. That’s why there are so many unprofitable strategies around, with nevertheless great backtest performances.

Does this mean that backtests are worthless? Not at all. But it is essential to know whether you can trust the test, or not.

The test-the-backtest experiment

There are several methods for verifying a backtest. None of them is perfect, but all give insights from different viewpoints. We’ll use the Zorro algo trading software, and run our experiments with the following test system that is optimized and backtested with walk-forward analysis:

function run()
{
  set(PARAMETERS,TESTNOW,PLOTNOW,LOGFILE);
  BarPeriod = 1440;
  LookBack = 100;
  StartDate = 2012;
  NumWFOCycles = 10;

  assetList("AssetsIB");
  asset("SPY");

  vars Signals = series(LowPass(seriesC(),optimize(10,2,20,2)));
  vars MMIFast = series(MMI(seriesC(),optimize(50,40,60,5)));
  vars MMISlow = series(LowPass(MMIFast,100));

  MaxLong = 1;
  if(falling(MMISlow)) {
    if(valley(Signals))
      enterLong();
    else if(peak(Signals))
      exitLong();
  }
}

This is a classic trend following algorithm. It uses a lowpass filter for trading at the peaks and valleys of the smoothed price curve, and a MMI filter (Market Meanness Index) for distinguishing trending from non-trending market periods. It only trades when the market has switched to rend regime, which is essential for profitable trend following systems. It opens only long positions. Lowpass and MMI filter periods are optimized, and the backtest is a walk-forward analysis with 10 cycles.

The placebo trading system

It is standard for experiments to compare the real stuff with a placebo. For this we’re using a trading system that has obviously no edge, but was tweaked with the evil intention to appear profitable in a walk-forward analysis. This is our placebo system:

void run()
{
  set(PARAMETERS,TESTNOW,PLOTNOW,LOGFILE);
  BarPeriod = 1440;
  StartDate = 2012;
  setf(TrainMode,BRUTE);
  NumWFOCycles = 9;

  assetList("AssetsIB");
  asset("SPY");

  int Pause = optimize(5,1,15,1);
  LifeTime = optimize(5,1,15,1);

// trade after a pause...
  static int NextEntry;
  if(Init) NextEntry = 0;
  if(NextEntry-- <= 0) {
    NextEntry = LifeTime+Pause;
    enterLong();
  }
}

This system opens a position, keeps it a while, then closes it and pauses for a while. The trade and pause durations are walk-forward optimized between 1 day and 3 weeks. LifeTime is a predefined variable that closes the position after the given time. If you don’t believe in lucky trade patterns, you can rightfully assume that this system is equivalent to random trading. Let’s see how it fares in comparison to the trend trading system.

Trend trading vs. placebo trading

This is the equity curve with the trend trading system from a walk forward analysis from 2012 up to 3/2022:

The plot begins 2015 because the preceding 3 years are used for the training and lookback periods. SPY follows the S&P500 index and rises in the long term, so we could expect anyway some profit with a long-only system. But this system, with profit factor 3 and R2 coefficient 0.65 appears a lot better than random trading. Let’s compare it with the placebo system:

The placebo system produced profit factor 2 and R2 coefficient 0.77. Slightly less than the real system, but in the same performance range. And this result was also from a walk-forward analysis, although with 9 cycles – therefore the later start of the test period. Aside from that, it seems impossible to determine solely from the equity curve and performance data which system is for real, and which is a placebo.

Checking the reality

Methods to verify backtest results are named ‘reality check’. They are specific to the asset and algorithm; in a multi-asset, multi-algo portfolio, you need to enable only the component you want to test. Let’s first see how the WFO split affects the backtest. In this way we can find out whether our backtest result was just due to lucky trading in a particular WFO cycle. We’re going to plot a WFO profile that displays the effect of the number of walk-forward cycles on the result. For this we outcomment the NumWFOCycles = … line in the code, and run it in training mode with the WFOProfile.c script:

#define run strategy
#include "trend.c" // <= your script
#undef run
#define CYCLES 20 // max WFO cycles

function run()
{
  set(TESTNOW);
  NumTotalCycles = CYCLES-1;
  NumWFOCycles = TotalCycle+1;
  strategy();
}

function evaluate()
{
  var Perf = ifelse(LossTotal > 0,WinTotal/LossTotal,10);
  if(Perf > 1)
    plotBar("WFO+",NumWFOCycles,NumWFOCycles,Perf,BARS,BLACK);
  else
    plotBar("WFO-",NumWFOCycles,NumWFOCycles,Perf,BARS,RED);
}

We’re redefining the run function to a different name. This allows us to just include the tested script and train it with WFO cycles from 2 up to the number defined by CYCLES. A backtest is executed after training. If an evaluate function is present, Zorro runs it automatically after any backtest. It plots a histogram bar of the profit factor (y axis) from each number of WFO cycles. First, the WFO profile of the trend trading system:

We can see that the performance rises with the number of cycles. This is typical for a system that adapts to the market. All results are positive with a profit factor > 1. Our arbitrary choice of 10 cycles produced a less than average result. So we can at least be sure that this backtest result was not caused by a particularly lucky number of WFO cycles.

The WFO profile of the placebo system:

This time the number of WFO cycles had a strong random effect on the performance. And it is now obvious why I used 9 WFO cycles for that system. For the same reason I used brute force optimization, since it increases WFO variance and thus the chance to get lucky WFO cycle numbers. That’s the opposite of what we normally do when developing algorithmic trading strategies.

WFO profiles give insight into WFO cycle dependency, but not into randomness or overfitting by other means. For this, more in-depth tests are required. Zorro supports two methods, the Montecarlo Reality Check (MRC) with randomized price curves, and White’s Reality Check (WRC) with detrended and bootstrapped equity curves of strategy variants. Both methods have their advantages and disadvantages. But since strategy variants from optimizing can only be created without walk-forward analysis, we’re using the MRC here.

The Montecarlo Reality Check

First we test both systems with random price curves. Randomizing removes short-term price correlations and market inefficiencies, but keeps the long-term trend. Then we compare our original backtest result with the randomized results. This yields a p-value, a metric of the probability that our test result was caused by randomness. The lower the p-Value, the more confidence we can have in the backtest result. In statistics we normally consider a result significant when its p-Value is below 5%.

The basic algorithm of the Montecarlo Reality Check (MRC):

1. Train your system and run a backtest. Store the profit factor (or any other performance metric that you want to compare).
2. Randomize the price curve by randomly swapping price changes (shuffle without replacement).
3. Train your system again with the randomized data and run a backtest. Store the performance metric.
4. Repeat steps 2 and 3 1000 times.
5. Determine the number N of randomized tests that have a better result than the original test. The p-Value is N/1000.

If our backtest result was affected by an overall upwards trending price curve, which is certainly the case for this SPY system, the randomized tests will be likewise affected. The MRC code:

#define run strategy
#include "trend.c" // <= your script
#undef run
#define CYCLES 1000

function run()
{
  set(PRELOAD,TESTNOW);
  NumTotalCycles = CYCLES;
  if(TotalCycle == 1) // first cycle = original
    seed(12345); // always same random sequence
  else
    Detrend = SHUFFLE;
  strategy();
  set(LOGFILE|OFF); // don't export files
}

function evaluate()
{
  static var OriginalProfit, Probability;
  var PF = ifelse(LossTotal > 0,WinTotal/LossTotal,10);
  if(TotalCycle == 1) {
    OriginalProfit = PF;
    Probability = 0;
  } else {
    if(PF < 2*OriginalProfit) // clip image at double range
      plotHistogram("Random",PF,OriginalProfit/50,1,RED);
    if(PF > OriginalProfit)
      Probability += 100./NumTotalCycles;
  }
  if(TotalCycle == NumTotalCycles) { // last cycle
    plotHistogram("Original",
     OriginalProfit,OriginalProfit/50,sqrt(NumTotalCycles),BLACK);
    printf("\n-------------------------------------------");
    printf("\nP-Value %.1f%%",Probability);
    printf("\nResult is ");
    if(Probability <= 1)
      printf("highly significant") ;
    else if(Probability <= 5)
      printf("significant");
    else if(Probability <= 15)
      printf("maybe significant");
    else
      printf("statistically insignificant");
    printf("\n-------------------------------------------");
  }
}

This code sets up the Zorro platform to train and test the system 1000 times. The seed setting ensures that you get the same result on any MRC run. From the second cycle on, the historical data is shuffled without replacement. For calculating the p-value and plotting a histogram of the MRC, we use the evaluate function again. It calculates the p-value by counting the backtests resulting in higher profit factors than the original system. Depending on the system, training and testing the strategy a thousand times will take several minutes with Zorro. The resulting MRC histogram of the trend following system:

The height of a red bar represents the number of shuffled backtests that ended at the profit factor shown on the x axis. The black bar on the right (height is irrelevant, only the x axis position matters) is the profit factor with the original price curve. We can see that most shuffled tests came out positive, due to the long-term upwards trend of the SPY price. But our test system came out even more positive. The p-Value is below 1%, meaning a high significance of our backtest. This gives us some confidence that the simple trend follower can achieve a similar result in real trading.

This cannot be said from the MRC histogram of the placebo system:

The backtest profit factors now extend over a wider range, and many were more profitable than the original system. The backtest with the real price curve is indistinguishable from the randomized tests, with a p-value in the 40% area. The original backtest result of the placebo system, even though achieved with walk-forward analysis, is therefore meaningless.

It should be mentioned that the MRC cannot detect all invalid backtests. A system that was explicitly fitted to a particular price curve, for instance by knowing in advance its peaks and valleys, would get a low p-value by the MRC. No reality check could distinguish such a system from a system with a real edge. Therefore, neither MRC nor WRC can give absolute guarantee that a system works when it passes the check. But when it does not pass, you’re advised to better not trade it with real money.

I have uploaded the strategies to the 2022 script repository. The MRC and WFOProfile scripts are included in Zorro version 2.47.4 and above. You will need Zorro S for the brute force optimization of the placebo system.

Markos’ buy-and-sell system with stock index ETFs uses the VIX as a volatility indicator for predicting downtrends. The system is a veritable indicator soup, with no less than 15 separate buy and sell conditions. Fortunately his published Amibroker code can be easily converted to C:

function run()
{
 StartDate = 20101231;
 EndDate = 20201231;
 BarPeriod = 7*1440; // 1 week
 LookBack = 100;
 Capital = 100000;

 set(PARAMETERS,TESTNOW,PLOTNOW);
 setf(PlotMode,PL_ALL);
 PlotScale = 8;

 asset("VIX");
 var VIXdn = (price(0)/HH(15,1)-1)*100;
 var VIXup = (price(0)/LL(15,1)-1)*100;
 var VIXDnMin = -optimize(30,20,40,10);
 var VIXUpMin = optimize(100,80,120,10);
 plot("VIX",price(0),NEW,BLACK);

 asset("SPY"); // use unadjusted data!
 vars SPYs = series(priceClose());
 vars Vols = series(marketVol());
 vars ATRs = series(ATR(2));
 var ATRDn = (ATRs[0]/MaxVal(ATRs+1,15)-1)*100;
 var ATRUp = (ATRs[0]/MinVal(ATRs+1,15)-1)*100;
 var Up = (HH(2)/LL(4)-1)*100;
 var Dn = (LL(2)/HH(4)-1)*100;
 var Cch = (LL(10)/HH(100)-1)*100;
 vars StochK14s = series(StochK(14,3));
 vars StochK40s = series(StochK(40,3));
 int HHb = MaxIndex(SPYs,4);
 int LLb = MinIndex(SPYs,4);
 var VOLUp = (Vols[0]/SMA(Vols+HHb+1,50)-1)*100;
 plot("Volume",Vols,BARS|NEW,BLUE);
 plot("ATR(2)",ATRs,LINE|NEW,RED);

 int BuyInitial = once(
   SMA(SPYs,10) >= SMA(SPYs+1,10) && 
   StochK(3,3) < 40);
 int Buy = Up > 6 &&
   (VIXdn < VIXDnMin or ATRDn < 2*VIXDnMin) &&
   Cch < -15 &&
   MinVal(StochK40s,LLb) < 25 &&
   MinVal(StochK14s,LLb) < 25 &&
   StochK14s[0] >= StochK40s[0];
 int Sell = SPYs[0] < SMA(SPYs,20) &&
   Dn < -6 &&
   (VIXup > VIXUpMin or ATRUp > 2*VIXUpMin) &&
   VOLUp > 80 &&
   MaxVal(StochK40s,HHb) > 85 &&
   MaxVal(StochK14s,HHb) > 85 &&
   StochK14s[0] <= StochK40s[0];

 MaxLong = 1;
 Leverage = 1;
 Margin = Equity; // invest all money
 Fill = 3; // enter/exit at next open
 if(Sell)
   exitLong();
 else if(BuyInitial or Buy)
   enterLong();

//plot tiny triangles for the buy and sell signals
 if(Buy) 
   plot("Buy",0.9*priceLow(),MAIN|TRIANGLE,GREEN);
 if(Sell) 
   plot("Sell",1.1*priceHigh(),MAIN|TRIANGLE4,RED);

}

The initial buy condition is required, otherwise the system would stay out of the market for a long time. The once(..) function is used for such initializations; it returns true when its argument becomes nonzero the first time during a backtest or trading session, and false afterwards. On the chart we can see that the system is indeed only in the market when SPY rises. The blue line is the VIX, the tiny red and green triangles are the buy and sell signals. They appear well placed.

This is, of course, an in-sample result. With only 3 trades, WFO would be futile. For your experiments please be aware that the above setup, derived from the author’s Amibroker code, must be exactly reproduced for getting the same result. Tiny deviations, such as using adjusted instead of unadjusted SPY data, shifting the bars by a few hours, or using a slightly different Stoch variant, produced a quite different backtest. This hints that there’s still room for improvement with this strategy, to say the least. The above code is more an exercise in 1:1 conversion from another platform, than a real trading system. But the basic idea of buy-and-sell is certainly good, as is the idea to use the VIX for downtrend detection. Maybe someone can come up with a more simple and more serious variant of this system that would be suited for a WFO test.

The Buy-Sell system can be downloaded from the 2021 script repository. Since it is based on 1-week bars and uses market volume, you need Zorro S 2.38 or above to run it. Or even better, convert it to daily bars. Personally I see no reason for using 1-week bars in any trading system.

The simple example strategy is basically a short-term trend follower. The price curve is differentiated, then integrated again for removing the zero frequency part. The result is smoothed, and the system trades on zero crossings of its rate of change. Two parameters, the smoothing period and the rate-of-change period, are optimized. The code in C for Zorro:

void simple()
{
  int SigPeriod = optimize(8,6,14,1),
    ROCPeriod = optimize(1,1,6,1);
//Derivative of the price wave
  vars Deriv = series(priceClose(0)-priceClose(2));
//zeros at Nyquist and 2*Nyquist, i.e. Z3 = (1 + Z^-1)*(1 + Z^-2)
  vars Z3 = series(Sum(Deriv,4));
//Smooth Z3 for trading signal
  vars Signal = series(SMA(Z3,SigPeriod));
//Use Rate of Change to identify entry point
  vars Roc = series(Signal[0]-Signal[ROCPeriod]);
//If ROC Crosses Over 0 Then Buy Next Bar on Open;
//If Signal Crosses Under 0 Then Sell Next Bar on Open;
  if(crossOver(Roc,0))
    enterLong();
  else if(crossUnder(Signal,0))
    exitLong();
}

For replicating Ehlers’ results we use brute force in-sample optimization. This results in an impressive profit factor of almost 3 when applied to the S&P500 index (SPY) from 2009 to 2021. Still, the equity curve below shows that the main profit results from the last 2 years. So this is, as Ehlers admitted, not a very robust system.

Figure 1 – Simple system with no FM demodulator

Now we’re going to improve the system by inserting Ehler’s FM demodulator from the previous article. The code in C for Zorro:

void simpleFM()
{
  int i, SigPeriod = optimize(8,6,14,1),
  ROCPeriod = optimize(1,1,6,1);
//Derivative of the price wave
  vars Deriv = series(priceClose(0)-priceClose(2));
//FM filter: normalize Derive to half RMS and hard limit at +/- 1
  var RMS = 0;
  for(i=0; i<50; i++) RMS += Deriv[i]*Deriv[i];
  vars Clips = series(clamp(2*Deriv[0]/sqrt(RMS/50),-1,1));
//zeros at Nyquist and 2*Nyquist, i.e. Z3 = (1 + Z^-1)*(1 + Z^-2)
  vars Z3 = series(Sum(Clips,4));
//Smooth Z3 for trading signal
  vars Signal = series(SMA(Z3,SigPeriod));
//Use Rate of Change to identify entry point
  vars Roc = series(Signal[0]-Signal[ROCPeriod]);
//If ROC Crosses Over 0 Then Buy Next Bar on Open;
//If Signal Crosses Under 0 Then Sell Next Bar on Open;
  if(crossOver(Roc,0))
    enterLong();
  else if(crossUnder(Signal,0))
    exitLong();
}

The FM demodulator is basically the clamp() function, which removes the amplitude from the price curve derivative, in combination with the subsequent SMA, which acts as a lowpass filter. The result after brute force optimization:

Figure 2 – Simple system with FM demodulator

The profit factor is still about the same, slightly below 3, but the equity curve now looks a bit better and the total profit is higher. Ehlers attributed the increased robustness to the more linear parameter surface. For verifying that, we compare the 2D parameter charts from both versions:

Figure 3 – Parameter heatmap, no FM demodulator

Figure 4 – Parameter heatmap, with FM demodulator

The charts display the performance dependent on the parameter values on the y and x asis. We can see that the FM demodulator version has indeed the smoother heatmap with a top (green) in the center of the parameter ranges. The heatmap of the other system looks crumpled with a deep valley in the center and several tops apart from each other. Clearly the optimization of the FM demodulator system was more effective.

Further reading: John Ehlers, More Robust Strategies, Stocks & Commodities June 2021.

The script can be downloaded from the 2021 script repository. You will need Zorro S 2.37 or better for the brute force optimization and the 2D parameter charts.

Theoretically, many trend trading systems would fall in the Turk category since they are based on following the herd. But here we’re not looking into trader’s opinions of the current market situation, but into their expectations of the future. There are several methods. The most usual is evaluating the Commitment Of Traders report, for which many platforms, also Zorro, provide easy-to-use indicators. But some publications (1) found that using the COT report for predicting the markets produces mixed results at best.

There’s a more precise way to get the market’s expectations. It’s using options premiums. If an option expires in 6 weeks, its current premium reflects what option buyers or sellers think about the underlying price in 6 weeks.

The price probability distribution

For deriving the expected underlying price at expiration, we have to take all strike prices in consideration. Here’s the algorithm in short (I haven’t invented it, a longer description can be found in (2)). Assume SPY is currently trading at $200. For getting the probability that it will rise to between 210 and 220 in 6 weeks, we’re looking into the 210 call and the 220 call. Suppose they trade at $14 and $10. So we can buy the 210 call and sell the 220 call and pay $4 difference. If at expiration SPY is under 210, both contracts have no worth and we lose the 4 dollars. If it is above 220, our gain is the $10 strike difference minus $4 premium difference, so we win 6 dollars. If it is between 210 and 220, our win or loss is also inbetween, with an average of (-4+6)/2 = 1 dollar.

When options prices are “fair”, i.e. solely determined by probabilities where the price will end up at expiration, summing up over all possible outcomes yields zero profit or loss. So

-$4×L + $1×M + $6×H = $0

where L is the probability for SPY to end up below 210, M is the probability that it will be between 210 and 220, and H is the probability that it will be above 220. Since one of these three alternatives will always happen, the sum of all 3 probabilities must be 1:

L + M + H = 1

Now let’s assume that we know L already. Then we have two equations with two unknowns, which are easily solved:

5L – 5H = 1    =>  H = L – 0.2
10L + 5M = 6    =>  M = 1.2 -2L 

Assuming L = 50% yields H = 30% and M = 20%.

How do we now get the value L? We simply take the lowest strike offered at the market, and assume that the probability of SPY ending up even below that is zero. So our first L is 0.  We can now use the method above to calculate the M belonging to the interval between the lowest and the second-lowest strike. That M is then added to L since it’s the probability of SPY ending up at or below the second-lowest strike. We continue that process with the next interval, getting a specific L and M for any interval until we arrived at the highest strike. If the traders have been consistent with their assumptions, the final L – the sum over all Ms – should be now at or close to 1.

Here’s a small script that displays the 6-weeks L distribution of SPY:

void main() 
{
	StartDate = 20170601;
	LookBack = 0;

	assetList("AssetsIB");
	asset("SPY"); 

// load today's contract chain
	contractUpdate(0,0,CALL|PUT);
	printf("\n%i contracts",NumContracts);
	if(!NumContracts) return;

// get underlying price
	var Price,Current = priceClose(0);
	printf("\nCurrent price %.2f",Current);

// plot CPD histogram	
	contractCPD(45);	// 6 weeks
	int N = 0;
	for(Price = 0.75*Current; Price < 1.25*Current; N++, Price += 0.01*Current)
		plotBar("CPD",N,floor(Price),cpd(Price),BARS|LBL2,RED);
	printf("\nExpected price %.2f",cpdv(50));

// compare with real future price
	set(PEEK);
	N = timeOffset(UTC,-45,0,0);
	printf("\nFuture price %.2f",priceClose(N));
}

The result is a histogram of expected probabilities, in percent, that the SPY price will be at or below the price at the x-axis six weeks in the future. I’ve marked the current price with a black bar.

The contractCPD function generates the distribution with the above described algorithm, cpd returns the accumulated probability L (in percent) at a given price, and cpdv returns the price at a given L. Therefore, cpdv(50) is the median of market expectations. In our case, at June 1 2017, a modest price increase to $245 was expected for mid-July (in fact the price ended up at $245.51, but don’t get too excited – often trader’s expectations fall short by several dollars). We can also see an unusal step at the begin of the histogram: about 10% of traders expected a strong drop to below $200. Maybe Trump twittered something that morning.

The strategy

We will now exploit trader’s expectations for a strategy, and this way check if they have any merit. This is our mechanical Turk:

#define Sentiment AssetVar[0]

void run() 
{
	StartDate = 20120102;
	EndDate = 20171231;
	BarPeriod = 1440;

	assetList("AssetsIB");
	asset("SPY");
	MaxLong = MaxShort = 1;

// load today's contract chain
	contractUpdate(0,0,CALL|PUT);
	int N = contractCPD(45);

// increase/decrease market sentiment 
	if(N) {
		var Expect = cpdv(50) - priceClose();
		if(Expect < 0)
			Sentiment = min(Expect,Sentiment+Expect);
		else
			Sentiment = max(Expect,Sentiment+Expect);
	}
	if(Sentiment > 5)
		enterLong();
	else if(Sentiment < -5)
		enterShort();
	
	plot("Sentiment",Sentiment,NEW,RED);
}

We’re checking the market expectation every day and add it to a previously defined Sentiment asset variable. If the expectation changes sign, so does Sentiment. If its amount has accumulated above 5, we buy a long or short position dependent on its sign. This way we’re only considering the market expectation when it’s either relatively strong or had the same direction for several days.

The result:

The system produces about 20% annual return with profit factor 3. The red line in the lower chart is the Sentiment variable – we can see that it often steadily increases, but sometimes also decreases. Since SPY normally rises, shorting it with this strategy produces less profit than going long, but is still slightly profitable with an 1.16 profit factor.

Predicting the price in 6 weeks

What are traders currently thinking of the SPY price in 6 weeks? For this, the first script above needs just be slightly modified so that it does not use historical options data, but connects to IB and downloads the current options chain with all prices:

void main() 
{
	StartDate = NOW;
	LookBack = 0;

	assetList("AssetsIB");
	asset("SPY"); 

// load today's contract chain
	contractUpdate(0,0,CALL|PUT);
	printf("\n%i contracts",NumContracts);
	if(!NumContracts) return;

// get underlying price
	var Price,Current = priceClose(0);
	printf("\nCurrent price %.2f",Current);

// plot CPD histogram
	printf("\nWait time approx %i minutes",1+NumContracts/200);
	contractCPD(45);
	int N = 0;
	for(Price = 0.75*Current; Price < 1.25*Current; N++, Price += 0.01*Current)
		plotBar("CPD",N,floor(Price),cpd(Price),BARS|LBL2,RED);
	printf("\nExpected price %.2f",cpdv(50));
}

This script must be started in Zorro’s Trade mode with the IB plugin selected. Mind the displayed “wait time”. IB sometimes needs up to ten seconds for returning the price of an option contract, so downloading the prices of all 6-weeks contracts can take half an hour or more.

I ran that script today (Dec 11 2018) and the option traders expect the SPY price to rise to $269 in six weeks. So I’ll check the price by the end of January and post here if they have been right.

I’ve added the scripts to the 218 repository. You’ll need Zorro 1.99 or above, and SPY options EOD history for the first 2 scripts. You’ll really have to buy it this time, the free artificial options history won’t do for market sentiment.

Conclusions

• A Turk can beat a thinking machine.
• Option traders tend to underestimate future price changes.
• But they are often right in the price direction.

Literature

(1) Sanders, Irwin, Merrin: Smart Money? The Forecasting Ability of CFTC Large Traders (2007)

(2) Pat Neal, Option Prices Imply a Probability Distribution

Bitcoin – hodl??

A buy and hold strategy works extremely well when a price bubble grows, and extremely bad when it bursts. And indeed, apparently all finance and economy gurus (well, all but John McAfee) tell you that the cryptocurrency market, and especially bitcoin, is a bubble, even a “scam with no substantial worth”, and will soon experience a crash “worse than the 17th century tulip mania” or the “18th century South Sea Company fraud”.

By definition, a bubble is a price largely above the ‘real value’ or ‘fair value’ of an asset, and it bursts when people realize that. So what is the fair value of a bitcoin? Obviously not zero, since blockchain based currencies have (aside from their disadvantages) several advantages over traditional currencies, on the economy level as well as on the private level. Such as:

• They break the link of money and debt. Cryptocurrencies don’t require the bank credit mechanism for money creation.
• They can be used where normal money would be impractical, such as fee transfers between machines or trading in multiplayer games.
• They allow low-cost and anonymous money transactions. At least in theory.
• They replace banks for storing and mattresses for stashing money.

I’m ready to believe that blockchain is the future of money transfer and storage. But that does not mean an ever-rising bitcoin price. Hundreds of cryptocurrencies came out in the last two years, any single of them with a better blockchain technology than bitcoin, and any good programmer can add a new coin anytime. Few will survive. Countries or big companies might sooner or later issue their own crypto tokens, as Venezuela already is attempting. The release of an official blockchain Dollar, Yuan, or Euro would leave the old bitcoin with its energy hungry transaction algorithm in thin air. Thus, when investing in bitcoin, we should not hope for a rosy future, but look for its present ‘real value’.

Due to its extreme volatility, bitcoin can not replace bank tresors. But it is already used in some situations for reducing money transfer costs, since the miners get any transaction rewarded in bitcoin. And above all, anonymity can be a substantial motive to own it. When you need a hacker to delete your drunk driving record, pay her in bitcoin. But how big is the online market for illegal hacker jobs, kill contracts, money laundering, drugs, weapons, or pro-Trump facebook advertisements? No one knows, but when we compare it with cash, another form of anonymous payment, we get interesting results.

The current cash in circulation in the US is approximately $1.5 trillion dollars. And the current bitcoin supply, about 17 million bitcoins, represents a total value of about $250 billion. Which means that you can already replace 15% of all US cash with bitcoin! Not to mention all the other cryptos. I fear that this supply already exceeds the demand of anonymous online payment for today and also the next future.

For those reasons, a bitcoin “hodl” system, despite its extreme historical performance, is high risk. We don’t know when and how the bubble will burst – maybe bitcoin will go up to $100,000 before – but we have some reason to suspect that at some point sooner or later the bitcoin price might drop like a stone down to its ‘real value’. Which is unknown, but for practical purposes is probably not in the $15,000 area, but more like $15.

So we need some other method to tackle the cryptocurrency trading problem. The first question: Has the crypto market already developed price curve inefficiencies that can be exploited in a trading system? In (1) we see some tests with basic bitcoin strategies. Our own tests came to the same results. Momentum based strategies can work, and mean-variance optimizing portfolio systems can achieve even extreme returns with crytrocurrencies – up to 10 times higher than “hodl”. But that’s not really surprising due to the high momentums and volatilities of crypto coins. The problem is that all crypto portfolios are exposed to high risk. Other conventional model-based strategies don’t work well anyway with cryptos.

When we concentrate on bitcoin, our proposed system must be a fast trading, trend-agnostic strategy. That means it holds positions only a few minutes, and is not exposed to the bubble risk. I can already tell that short-term mean reversion – even with a more sophisticated system as in (1) – produces no good result with cryptos. So only a few possibilities remain. One of them is exploiting short-term price patterns. This is the strategy that we will develop. And I can already tell that it works. But for this we’ll need a deep machine learning system for detecting the patterns and determining their rules.

Selecting a machine learning library

The basic structure of such a machine learning system is described here. Due to the low signal-to-noise ratio and to ever-changing market conditions, analyzing price series is one of the most ambitious tasks for machine learning. Compared with other AI algorithms, deep learning systems have the highest success rate. Since we can connect any Zorro based trading script to the data analysis software R, we’ll use a R based deep learning package. There are meanwhile many available. Here’s the choice:

• Deepnet, a lightweight and straightforward neural net library with a stacked autoencoder and a Boltzmann machine. Produces good results when the feature set is not too complex. The basic train and predict functions for using a deepnet autoencoder in a Zorro strategy:

  library('deepnet') 
  
  neural.train = function(model,XY) 
  {
    XY <- as.matrix(XY)
    X <- XY[,-ncol(XY)]
    Y <- XY[,ncol(XY)]
    Y <- ifelse(Y > 0,1,0)
    Models[[model]] <<- sae.dnn.train(X,Y,
        hidden = c(30), 
        learningrate = 0.5, 
        momentum = 0.5, 
        learningrate_scale = 1.0, 
        output = "sigm", 
        sae_output = "linear", 
        numepochs = 100, 
        batchsize = 100)
  }
  
  neural.predict = function(model,X) 
  {
    if(is.vector(X)) X <- t(X)
    return(nn.predict(Models[[model]],X))
  }
  

• H2O, an open-source software package with the ability to run on distributed computer systems. Coded in Java, so the latest version of the JDK is required. Aside from deep autoencoders, many other machine learning algorithms are supported, such as random forests. Features can be preselected, and ensembles can be created. Disadvantage: While batch training is fast, predicting a single sample, as usually needed in a trading strategy, is relatively slow due to the server/client concept. The basic H2O train and predict functions for Zorro:

  library('h2o') 
  # also install the Java JDK
  
  neural.train = function(model,XY) 
  {
    XY <- as.h2o(XY)
    Models[[model]] <<- h2o.deeplearning(
      -ncol(XY),ncol(XY),XY,
      hidden = c(30),  seed = 365)
  }
  
  neural.predict = function(model,X) 
  {
    if(is.vector(X)) X <- as.h2o(as.data.frame(t(X)))
    else X <- as.h2o(X)
    Y <- h2o.predict(Models[[model]],X)
    return(as.vector(Y))
  }

• Tensorflow in its Keras incarnation, a neural network kit by Google. Supports CPU and GPU and comes with all needed modules for tensor arithmetics, activation and loss functions, covolution kernels, and backpropagation algorithms. So you can build your own neural net structure. Keras offers a simple interface for that.

  Keras is available as a R library, but installing it requires also a Python environment. First install Anaconda from www.anaconda.com. Open the Anaconda Navigator and install the RStudio application (installing Keras outside an Anaconda environment fails on some PCs with an error message). Then open Rstudio inside the Navigator, install the Keras package, then finally execute library(‘keras’) and install_keras(). These steps usually succeed.

  The Keras train and predict functions for Zorro:

  library('keras')
  #needs Python 3.6 and Anaconda
  #call install_keras() after installing the package
  
  neural.train = function(model,XY) 
  {
    X <- data.matrix(XY[,-ncol(XY)])
    Y <- XY[,ncol(XY)]
    Y <- ifelse(Y > 0,1,0)
    Model <- keras_model_sequential() 
    Model %>% 
      layer_dense(units=30,activation='relu',input_shape = c(ncol(X))) %>% 
      layer_dropout(rate = 0.2) %>% 
      layer_dense(units = 1, activation = 'sigmoid')
    
    Model %>% compile(
      loss = 'binary_crossentropy',
      optimizer = optimizer_rmsprop(),
      metrics = c('accuracy'))
    
    Model %>% fit(X, Y, 
      epochs = 20, batch_size = 20, 
      validation_split = 0, shuffle = FALSE)
    
    Models[[model]] <<- Model
  }
  
  neural.predict = function(model,X) 
  {
    if(is.vector(X)) X <- t(X)
    X <- as.matrix(X)
    Y <- Models[[model]] %>% predict_proba(X)
    return(ifelse(Y > 0.5,1,0))
  }
  

• MxNet, Amazon’s answer on Google’s Tensorflow. Offers also tensor arithmetics and neural net building blocks on CPU and GPU, as well as high level network functions similar to Keras (the next Keras version will also support MxNet). Just as with Tensorflow, CUDA is supported, but not (yet) OpenCL, so you’ll need a Nvidia graphics card to enjoy GPU support. In direct comparison (2), MxNet was reported to be less resource hungry and a bit faster than Tensorflow, but so far I could not confirm this. The standard train and predict functions:

  # how to install the CPU version:
  #cran <- getOption("repos")
  #cran["dmlc"] <- "https://s3-us-west-2.amazonaws.com/apache-mxnet/R/CRAN/"
  #options(repos = cran)
  #install.packages('mxnet')
  library('mxnet')
  
  neural.train = function(model,XY) 
  {
    X <- data.matrix(XY[,-ncol(XY)])
    Y <- XY[,ncol(XY)]
    Y <- ifelse(Y > 0,1,0)
    Models[[model]] <<- mx.mlp(X,Y,
         hidden_node = c(30), 
         out_node = 2, 
         activation = "sigmoid",
         out_activation = "softmax",
         num.round = 20,
         array.batch.size = 20,
         learning.rate = 0.05,
         momentum = 0.9,
         eval.metric = mx.metric.accuracy)
  }
  
  neural.predict = function(model,X) 
  {
    if(is.vector(X)) X <- t(X)
    X <- data.matrix(X)
    Y <- predict(Models[[model]],X)
    return(ifelse(Y[1,] > Y[2,],0,1))
  }
  

By replacing the neural.train and neural.predict functions, and other functions for saving and loading models that are not listed here, you can run the same strategy with different deep learning packages and compare. We’re currently using Keras for most machine learning strategies, and I’ll also use it for the short-term bitcoin trading system presented in the upcoming 2nd part of this article. There is no bitcoin futures data available yet, so tick based price data from several bitcoin exchanges will have to do for the backtest.

I’ve uploaded the interface scripts for Deepnet, H2O, Tensorflow/Keras, and MxNet to the 2018 script repository, so you can run your own deep learning experiments and compare the packages. Here’s a Zorro script for downloading bitcoin prices from Quandl – EOD only, though, since the exchanges demand dear payment for their tick data.

void main()
{
  assetHistory("BITFINEX/BTCUSD",FROM_QUANDL);
}

You can also get Bitcoin M1 data from Kaggle in CSV format. Here’s a Zorro script for converting it to a Zorro T6 dataset:

void main()
{
	string InName = "History\\bitstampUSD_1-min_data_2012-01-01_to_2019-03-13.csv";
	string Format = "+%t,f3,f1,f2,f4,f6";
	dataParse(1,Format,InName); 
	dataSave(1,"History\\BTCUSD.t6");
}

Further reading

(1) Nicolas Rabener, Quant Strategies in the Cryptocurrency Space

(2) Julien Simon, Tensorflow vs MxNet

(3) Zachary Lipton et al, MxNet – The Straight Dope
(Good introduction in deep learning with MxNet / Gluon examples)

(4) F.Chollet/J.J.Allaire, Deep Learning with R
(Excellent introduction in Keras)

To clarify: I’ve selected the system not because of high profit expectancy or clever algorithm, but because it is quite simple and does not need any of the additional data normally used for option systems, such as earnings reports, open interest, implied volatility, or greeks. Which means that you don’t need to call R functions for options math, and you don’t need to pay for iVolatility options data, Zacks earnings, or any other historical data for backtesting the system. The free Zorro version is sufficient.

The book cover praises the system inside:  To reduce your investment risk to nearly zero – Achieve consistent high annual returns in excess of 30% – It does not require you to learn fundamental and technical analyzes, deltas, thetas, gamas, vegas or other Greek goblethegooks of stocks or options  – It does not require the ability to predict market direction – It does not require stock picking skills – It does not require close monitoring.

All statements with which I, of course, highly sympathize. After all, why would we need Greek goblethegooks when we get annual 30% without them! And here are the (simplified) rules of our strategy:

1. Sell a 6 weeks call and a 6 weeks put of an index ETF. Choose strike prices so that the premiums are in the $1..$2 range.
2. If the underlying price touches one of our strike prices, thus threatening an in-the-money expiration, buy back that option and immediately sell a new option of the same type, but to a further expiration date, and a premium that covers the loss.
3. Wait until all options are expired, then go back to 1.

If you have a bit experience with options, you’ll notice that rule 1 describes a strangle combo. And you’ll next notice something strange with rule 2. Right, such a system can never lose, since any loss would apparently be compensated by the premium from the new trade. Have we finally found the Holy Grail, an ever-winning system? 

Strangle profit

For getting an impression of the profit and risk, let’s first check the gain/loss diagram of the 6-week $2 premium strangle. This is the definition of a strangle in the curve plotting script from the last article:

// Strangle
void combo()
{
	optionAdd(1,SELL|CALL,6);
	optionAdd(1,SELL|PUT,-6);
}

The $6 strike-spot distances have been chosen for $2 premium from a hypothetical index ETF with $250 price, multiplier 100, and 15% annual volatility. This is the profit/loss diagram:

Our potential gain is about $400 per combo trade, as expected (2 * 100 * $2 premium). But the price of our index ETF should better not move more than $10 in any direction until expiration. Otherwise the loss can quickly reach the thousand dollar zone. This does not really look like “reduce your investment risk to nearly zero”. But wait, we have rule 2, which will certainly save the day! Let’s put that to the backtest. 

The system

// Quite simple options trading system 
#include <contract.c>

#define PREMIUM	2.00
#define WEEKS	6    // expiration

int i;
var Price;

CONTRACT* findCall(int Expiry,var Premium)
{
	for(i=0; i<50; i++) {
		if(!contract(CALL,Expiry,Price+0.5*i)) return 0;
		if(between(ContractBid,0.1,Premium)) return ThisContract;
	}
	return 0;
}

CONTRACT* findPut(int Expiry,var Premium)
{
	for(i=0; i<50; i++) {
		if(!contract(PUT,Expiry,Price-0.5*i)) return 0;
		if(between(ContractBid,0.1,Premium)) return ThisContract;
	}
	return 0;
}

void run() 
{
	StartDate = 20110101;
	EndDate = 20161231;
	BarPeriod = 1440;
	BarZone = ET;
	BarOffset = 15*60+20; // trade at 15:20 ET
	LookBack = 1;

	assetList("AssetsIB");
	asset("SPY"); // unadjusted!
	Multiplier = 100;

// load today's contract chain
	contractUpdate("SPY",0,CALL|PUT);
	Price = priceClose(); 

// check for in-the-money and roll 	
	for(open_trades) {
		var Loss = -TradeProfit/Multiplier;
		if(TradeIsCall && Price >= TradeStrike) {
			exitTrade(ThisTrade);
			printf("#\nRoll %.1f at %.2f Loss %.2f",
				TradeStrike,Price,TradeProfit);
			CONTRACT* C = findCall(NWEEKS*7,Loss*1.1);
			if(C) {
				MarginCost = 0.15*Price - (C->fStrike-Price);
				enterShort();
			}
		} else if(TradeIsPut && Price <= TradeStrike) {
			exitTrade(ThisTrade);
			printf("#\nRoll %.1f at %.2f Loss %.2f",
				TradeStrike,Price,TradeProfit);
			CONTRACT* C = findPut(NWEEKS*7,Loss*1.1);
			if(C) { 
				MarginCost = 0.15*Price - (Price-C->fStrike);
				enterShort();
			}
		}
	}
	
// all expired? enter new options
	if(!NumOpenShort) { 
		CONTRACT *Call = findCall(NWEEKS*7,PREMIUM); 
		CONTRACT *Put = findPut(NWEEKS*7,PREMIUM); 		
		if(Call && Put) {
			MarginCost = 0.5*(0.15*Price-
				min(Call->fStrike-Price,Price-Put->fStrike));
			contract(Call); enterShort();
			contract(Put); enterShort();
		}
	}
}

A brief discussion of the code (a more detailed intro in system coding can be found in the Black Book). The findCall function gets an expiration time and a premium, and looks through the current option chain for a call contract that matches these two parameters. For this it increases the strike price in 50 steps. If then still no contract is found at or below the desired premium, it returns 0. Otherwise it returns a pointer to the found contract. The findPut function does the same for a put contract.

The run function sets up the backtest time and other parameters for the backtest as well as for live trading. It’s a daily script, and the function runs every day at 3:20 pm Eastern Time. It uses two historical data files for the backtest. The asset function loads a file with the unadjusted SPY prices (why unadjusted? Because determining the strikes-price distances would not work with dividend adjusted prices). The contractUpdate function loads the SPY options chain of that day, either from the broker, or from a file.  Those two files must be present, plus the asset list AssetsIB.csv that contains commission, margin, and other parameters for simulating the broker or exchange where we trade.

The next part of the code implements the miraculous rule 2. It calculates the current loss, closes any position that is at or in the money, and immediately opens a new position, with a premium slightly above our loss (Loss*1.1). This way we’re punishing the market for going against us. The printf function just stores that event in the log, so that we can go through it and better see the fate of those trades.

The last part of the code is the strangle. Note the MarginCost calculation. Margin affects the required capital and thus the backtest performance, so it should reflect your broker’s margin requirement. By default, the margin of a sold option is the premium plus some fixed percentage of the underlying that’s set up in the asset list. But brokers often apply a more complex margin formula for option combos. Here we assume that the margin of a sold strangle is the premium (which is automatically added) plus 15% of the underlying price minus the minimum of the two strike differences. We multiply that by half because we have 2 positions, but the margin formula is for the whole strangle.

The backtest from 2011-2016 needs only about 2 seconds. This is the result (assuming we always open 1 contract):

Monte Carlo Analysis... Median AR 12%
Win 3699$  MI 51.38$  DD 935$  Capital 5108$
Trades 93  Win 59.1%  Avg +39.8p  Bars 24
AR 12%  PF 1.84  SR 1.08  UI 5%  R2 0.89

We have won about 60% of all trades, and made 12% annual return based on Montecarlo analysis.  Not too exciting. What about the “consistent high annual returns in excess of 30%”? And how can we get a $935 drawdown when we always compensate our loss with a new trade?

Is rolling over irrational?

Let’s try the same strategy without the rule 2. This simplifies the script a bit:

// Even simpler options trading system 
#include <contract.c>

#define PREMIUM	2.00
#define WEEKS	6 // expiration

int i;
var Price;

CONTRACT* findCall(int Expiry,var Premium)
{
	for(i=0; i<50; i++) {
		if(!contract(CALL,Expiry,Price+0.5*i)) return 0;
		if(between(ContractBid,0.1,Premium)) return ThisContract;
	}
	return 0;
}

CONTRACT* findPut(int Expiry,var Premium)
{
	for(i=0; i<50; i++) {
		if(!contract(PUT,Expiry,Price-0.5*i)) return 0;
		if(between(ContractBid,0.1,Premium)) return ThisContract;
	}
	return 0;
}

void run() 
{
	StartDate = 20110101;
	EndDate = 20161231;
	BarPeriod = 1440;
	BarZone = ET;
	BarOffset = 15*60+20; // trade at 15:20 ET
	LookBack = 1;
	set(PLOTNOW);
	set(PRELOAD|LOGFILE);

	assetList("AssetsIB");
	asset("SPY"); // unadjusted!
	Multiplier = 100;

// load today's contract chain
	Price = priceClose();
	contractUpdate("SPY",0,CALL|PUT);

// all expired? enter new options
	if(!NumOpenShort) { 
		CONTRACT *Call = findCall(WEEKS*7,PREMIUM); 
		CONTRACT *Put = findPut(WEEKS*7,PREMIUM); 		
		if(Call && Put) {
			MarginCost = 0.5*(0.15*Price-min(Call->fStrike-Price,Price-Put->fStrike));
			contract(Call); enterShort();
			contract(Put); enterShort();
		}
	}
}

Simply removing the rolling over improved the system remarkably:

Monte Carlo Analysis... Median AR 25%
Win 5576$  MI 77.46$  DD 785$  Capital 3388$
Trades 78  Win 80.8%  Avg +71.5p  Bars 35
AR 27%  PF 2.00  SR 0.92  UI 5%  R2 0.92

The equity curve with no rolling:

Now the 25% annual return are somewhat closer to the promised profit. Of course at cost of higher risk, since no limiting mechanism is in place. We could now test other option combos instead of the strangle, for instance a condor for limiting the risk. We can run an optimization for finding out how the profit is affected by different premiums and expirations. I leave that to the reader. The interesting question is why rolling over options, not only with this, but with many option trading systems that we have coded so far, reduces the performance remarkably. Often to the client’s great surprise.

Rolling over with loss compensation establishes in fact a Martingale system. And such a system fares no better in option trading than in the casino. In fact, even worse. In the casino you have at least the same chance with every play. In trading, a losing option combo hints that the market starts trending – and the trend is likely to continue with the rolled over contract. Quite soon you cannot anymore compensate your losses with higher premiums, since you’ll find no contracts at that value. Ok, you could then start increasing the contract volume. If you really did that, you can calculate under the link above how long your account will survive. Rolling over a losing contract is typical irrational human behavior –  but the markets tend to punish irrationality.

Artificial options data

Since the system does not rely on goblethegooks, we can check whether the artificial options data that we created in the first part of this mini series can be used for testing this system. The backtest results above were with real options data. Here’s the result with the synthetic data:

Monte Carlo Analysis... Median AR 31%
Win 7162$  MI 99.49$  DD 1188$  Capital 3866$
Trades 88  Win 81.8%  Avg +81.4p  Bars 30
AR 31%  PF 2.36  SR 1.12  UI 4%  R2 0.88

It’s similar, but not quite identical to the real data. Artificial data represents a more efficient market situation, since its option premiums are identical to their theoretical values, and fundamentals such as earnings reports play no role. You can use it for confirming the real data backtest. Or for saving money, by backtesting a non-goblethegooks system (yes, I like this word) first with artifical data, and only if it looks good, purchasing real data for the final test.

I’ve added the full script to the 2017 repository. You’ll need Zorro version 1.73 or above. You can find the unadjusted SPY data in the History folder of the archive (alternatively, download it with the Zorro command assetHistory( “SPY.US”, FROM_STOOQ | UNADJUSTED)). If you don’t want to create the artificial 2011-2016 options history yourself, you can download it from the historical data archives here. 

Conclusions

• Mind the margin cost in backtests.
• Do not roll over losing contracts.
• If your system has no goblethegooks, try artificial data.

Literature

(1) is the book from which I pulled the system. The book is ok – not better or worse than most other options books, but at only $10, getting it is no mistake. 
(2) is a really good introduction into the options trading matter. Even though its author shamelessly plagiarized the title of my blog, and this even years before I started writing it!

(1) Daniel Mollat, $tock option$, BN Publishing 2011
(2) Philip Z Maymin, Financial Hacking, Wspc 2012