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.

Just like the performance of a stock, the performance of a company is measured by numerical indicators. They are named key figures. Key figures play a major role in quality management, such as the ISO 9000 standards. An ISO 9000 key figure is a detail indicator, such as the number of faults in a production line, the number of bugs found in a beta test, the number of new clients acquired per day, the total of positive minus negative online reviews, an so on. Aside from being essential for an ISO 9000 certification, these key figures have two purposes:

• They give detailed insight and expose strengths and weaknesses.
• And they give a strong motivation for reaching a certain goal.

The script below opens a user interface for entering various sorts of key figures. It calculates an overall score that reflects the current performance of a company – or of a person – and displays it in a chart. If you use it not for a company, but for yourself, it helps improving your personal life. And from the short script you can see how to create a relatively complex software with relatively few lines of code.

Hackers like the concept of key figures. They are plain numbers that you can work with. Anyone can define key figures for herself. If you’re a writer, an important key figure is the number of words you’ve written today; if you’re an alcolohic, it’s the number of drinks you had today. Many self-improvement books tell you precisely what you need to do for living a healthier, wealthier, happier life – but they all suffer from the same problem: long-term motivation. If you lack the iron will to keep your daily exercises, reduce smoking, stay away from fast food, and so on – all good resolutions will eventually fall into oblivion. If you had resolutions for 2025, you’ll soon know what I mean.

Failure is less likely when you can observe your progress any day and see its immediately effect on your overall performance score. This score is a direct measure of your success in live. Whether you’re a company or a person, you want to keep this core rising. This feedback produces a strong motivation, every day again.

The above performance chart is plotted by the key figure management script in C for the Zorro platform. The red line is the overall score, derived from all key figures in a way explained below. The blue line is the key figure for which you just entered a new value (in the example it’s the number of large or small features implemented in the last 6 months in the Zorro platform). The X axis is the date in YYMMDD format.

Of course, key figures can be very different. Some may have a daily goal, some not, some shall sum up over time, others (like your bank account value) are just taken as they are. The idea is that your overall score rises when you exceed the daily goals, and goes down otherwise. All key figures and their parameters can be freely defined in a CSV file, which can be edited with a text editor or with Excel. It looks like this:

In the first column you can assign a name. The second column is the number of decimals in the display, the third is their unit in the overall score, the fourth is an offset in the score, the fifth is the daily goal, and the last tells if the figures shall sum up over time (1) or not (0).

Example. Suppose you’re a president of a large country and want to pimp up your personal performance. What’s your key figures? First, of course, approval rate. Any tenth percent adds one point to your score. So the first entry is simple:

Name, Decimals, Unit, Offset, Growth, Sum
Appr, 1, 0.1, 0, 0, 0

Next, fame. Key figure is the daily number of praises on Fox News, OneAmerica, and Newsmax. You’ve ordered a White House department to count the praises; of course you’re personally counting them too, just in case. Less than 30 praises per day would be bad and reduce your score, more will improve it. So 30 praises are daily subtracted from your score. Any 10 further praises add one point. This is an accumulative key figure:

Praise, 0, 10, 0, -30, 1

Next, health. Key figure is weight. Your enemies spread rumors that you’re unfit and obese. Your doctors urge you to shed weight. So you want to lose one pound every month, which (you have your mathematicians for calculating difficult things) is about 0.033 per day. Any lost 0.1 pound adds one point to your score. The numbers are negative since you want your weight to go down, not up. The offset is your current weight.

Weight, 1, -0.1, -250, 0.033, 0

Next, literacy. Your enemies spread rumors you’re illiterate. To prove them wrong, you’ve decided to read at least half a page per day in a real book (you’ve chosen Duck for President to begin with). Any further half page adds one point to your score. This is also an accumulative figure.

Duck, 1, 0.5, 0, -0.5, 1

Finally, net worth. You’ve meanwhile learned to better avoid business attempts. Let your net worth grow due to the value increase of your inherited real estate, which is currently at 6 billion. Any million further growth adds one point to your score (numbers given in millions):

Worth, 0, 1, -6000, 0, 0

For improving your personal performance, download the script from the 2025 repository. Copy the files KeyFigures.csv and KeyFigures.c in your Strategy folder. Edit KeyFigures.csv for entering your personal key figures, as in the above example (you can later add or remove key figures and use Excel to add or remove the new columns to the data file). This is the script:

// Pimp Your Performance with Key Figures //////////////////////

string Rules = "Strategy\\KeyFigures.csv";
string Data = "Data\\KeyData.csv"; // key figures history
string Format = "0%d.%m.%Y,f1,f,f,f,f,f,f,f,f,f,f,f,f,f,f";
int Records,Fields;

var value(int Record,int Field,int Raw)
{
	var Units = dataVar(1,Field,2);
	var Offset = dataVar(1,Field,3);
	var Growth = dataVar(1,Field,4);
	var Value = 0;
	int i;
	for(i=0; i<=Record; i++) {
		if(dataVar(2,i,Field+1) < 0.) continue; // ignore negative entries
		Value += Growth;
		if(i == Record || (dataInt(1,Field,5)&1)) // Sum up? 
			Value += dataVar(2,i,Field+1)+Offset;
	}
	if(Raw) return Value-Offset;
	else return Value/Units;
}

var score(int Record)
{
	int i,Score = 0;
	for(i=0; i<Fields; i++) 
		Score += value(Record,i,0);
	panelSet(Record+1,Fields+1,sftoa(Score,0),YELLOW,16,4);
	return Score;
}


void click(int Row,int Col)
{
	dataSet(2,Row-1,Col,atof(panelGet(Row,Col)));
	score(Row-1);
	if(dataSaveCSV(2,Format,Data)) sound("Click.wav");
	int i;
	for(i=0; i<Records; i++) {
		var X = ymd(dataVar(2,i,0)) - 20000000;
		plotBar("Score",i,X,score(i),LINE,RED);
		plotBar(dataStr(1,Col-1,0),i,NIL,value(i,Col-1,1),AXIS2,BLUE);
	}
	if(Records >= 2) plotChart("");
}

void main()
{
	int i = 0, j = 0;
	printf("Today is %s",strdate("%A, %d.%m.%Y",NOW));
	ignore(62);
	PlotLabels = 5;
// File 1: Rules
	Fields = dataParse(1,"ssss,f1,f,f,f,i",Rules);
// File 2: Content
	Records = dataParse(2,Format,Data);
	int LastDate = dataVar(2,Records-1,0);
	int Today = wdate(NOW);
	if(LastDate < Today) { // no file or add new line
		dataAppendRow(2,16);
		for(i=1; i<=Fields; i++)
			if(!(dataInt(1,i-1,5)&1))
				dataSet(2,Records,i,dataVar(2,Records-1,i));
		Records++;
	}
	dataSet(2,Records-1,0,(var)Today);

// display in panel
	panel(Records+1,Fields+2,GREY,-58);
	panelFix(1,0);
	print(TO_PANEL,"Key Figures");
	for(i=0; i<Fields; i++)
		panelSet(0,i+1,dataStr(1,i,0),ColorPanel[0],16,1);
	panelSet(0,i+1,"Score",ColorPanel[0],16,1);
	panelSet(0,0,"Date",ColorPanel[0],16,1);
	for(j=0; j<Records; j++) {
		panelSet(j+1,0,strdate("%d.%m.%y",dataVar(2,j,0)),ColorPanel[0],0,1);
		score(j);
		for(i=0; i<Fields; i++) 
			panelSet(j+1,i+1,sftoa(dataVar(2,j,i+1),-dataVar(1,i,1)),ColorPanel[2],0,2);
	}
	panelSet(-1,0,"Rules",0,0,0);
}

The file locations and the CSV format of the key figures history are defined at the begin. The value function calculates the contribution of a particular key figure to the overall score. The score function updates the overall score. The click function, which is called when you enter a new value, calculates the score of that day, updates the spreadsheet, and prints the chart. The main function imports the data and key figures from their CSV files into datasets, prints the current day and displays a spreadsheet of your key figures and score history, like this:

 

 
You will need Zorro S because the spreadsheet function is not available in the free version. Start the script any morning. It will open the spreadsheet, where you can click in any of the white fields and enter a new key figure value for today. You can anytime enter new figures for today or for past days. At any entry, the score is calculated and – if the history spans more than 2 days – a chart is plotted as in the above example.

Normally, personal performance depends on about 5-10 key figures (maximum is 15). For instance, miles you’ve jogged today, steps walked, exercises done, pages read, words written, words learned in a new language, value of your bank account, value of your stock portfolio, burgers eaten, cigarettes smoked, enemies killed, or number of old ladies you helped crossing the street. If you’re a president, consider the script a free present (we hope for generous tax exceptions in exchange). If you’re an ISO 9000 certified company and want to use the script for your quality management, please contact oP group to pay your fee. For personal use, the script is free. Pimp your performance and make the world a better place!

They told that they will now charge hefty fees for using their store, for asking support questions, and for paying out. Mentioning the payout, they also told that they will from now on hold back payments for 2 months. Aside from the fact that they cannot legally change conditions in this way without their client’s consent, emails like that are normally business suicide. Since all competitors offer much better conditions, Digital  River would clearly sooner or later lose all their clients in this way. This email was a mystery. It made only sense under the assumption that Digital River intended to go out of business, but keep as much as their currernt client’s money as possible by offsetting them with insane fees.  

But Digital River did not hold back payments for 2 months. In November they stopped paying altogether. They did not give explanations. Reminders were answered with meaningless text blocks like this:

Please know that we are fully aware of the situation and are working diligently to resolve these issues as quickly as possible. Our team is investigating the cause of these delays to ensure they address them effectively and prevent such occurrences. We understand how important these payments are for you and your business. We are committed to ensuring that all outstanding payments are processed and that our communication with you is clear and timely moving forward. We appreciate your long-standing partnership and your trust in us over the years. Rest assured we are taking your concerns very seriously and trying to rectify this situation.“

There is a lot of speculation about what is behind it. Some believe that Digital River ran in liquidity problems, and originally intended to still pay, although later and fewer. The legality of this is disputable, but it does not yet constitute obvious fraud. However, most clients now assume that they prepared an exit fraud with the intention to keep all their client’s sales. In that case the mysterious email had just the purpose to delay legal action.

On their website, Digital River gives no hint of any trouble, and continues to run the stores and charge the customer’s credit cards as if nothing happened. The only thing certain is that clients are now hurrying to switch to other eCommerce providers, such as PayPro Global or Paddle, and that their last three months earnings are possibly gone. Unless some part of if can be recovered by lawsuits or criminal proceedings.

Since most Zorro S license subscribers run their subscriptions through Digital River, oP group has activated a fallback server for verifying subscription tokens. So all subscriptions will remain valid until renewed with the new online store provider, PayPro Global. If you have recently purchased a product from Digital River, better cancel the charge on your credit card or request a refund. At least in some cases, it was reported that refunds were indeed paid.  

More details: Digital_river_runs_dry | Missing payments and evasive communication

 For connecting the Zorro platform to a particular broker API, a DLL must be dropped in its Plugin folder. The DLL is then automatically recognized and appears in Zorro’s Broker selection box. For trading with the broker, the DLL exports functions for getting prices and sending orders. These functions are standardized and described in the Zorro manual. They are the same for all brokers. The following 4 functions are the most important:

BrokerOpen – identify the DLL.
BrokerLogin – initialize and store login credentials.
BrokerAsset – retrieve price and other parameters of an asset.
BrokerBuy2 – send a buy or sell order.

These four are sufficient for running most trading strategies. The DLL can export additional functions that are useful, but not mandatory, since Zorro works around them when they are not implemented:

BrokerAccount -get the account state.
BrokerTrade – get the trade or order state.
BrokerHistory2 -get price history.
BrokerCommand – set special modes, get order book, etc.

Zorro users have written DLLs for several broker APIs, but the code is often redundant and invents the wheel many times again. I’ll give here an example of a relatively lean broker DLL that can be used as template for individual REST API implementations. Bittrex is a US based digital currency exchange that supports several hundred crypto currencies and provides free API access. We’re first going to implement the 4 mandatory functions, following the API description on the Bittrex website:

https://bittrex.github.io/api/v3

We will use the free Visual C++ Community Edition from Microsoft. Aside from the exported functions, we need some internal functions to print messages, send HTTP requests, parse a JSON response, and generate a digital signature. For all this there’s ready code available on the Internet, but there are also ready functions in Zorro’s library. To make life easier, we simply import the Zorro function library to the DLL. The VC++ setup for generating such a DLL is described here:

https://zorro-project.com/manual/en/dlls.htm

The setup is for a C++ trading strategy, but works as well for a broker API DLL. First we’re going to implement the adminstrative stuff, the BrokerOpen and BrokerLogin functions:

#define PLUGIN_TYPE 2
#define PLUGIN_NAME "Bittrex V3"
#define DLLFUNC extern "C" __declspec(dllexport)

int (__cdecl *BrokerMessage)(const char *Text);
int (__cdecl *BrokerProgress)(const int Progress);
...

DLLFUNC int BrokerOpen(char* Name,FARPROC fpMessage,FARPROC fpProgress)
{
  strcpy_s(Name,32,PLUGIN_NAME);
  (FARPROC&)BrokerMessage = fpMessage;
  (FARPROC&)BrokerProgress = fpProgress;
  return PLUGIN_TYPE;
}

The BrokerOpen function is Zorro specific. It sets up two function pointers for printing message and sending heartbeats to Zorro. It’s needed for recognizing the DLL in the Plugin folder and letting the plugin name, “Bittrex V3”, appear in the broker scrollbox. 

Next we need the login function that’s called at the begin and the end of any algo trading session

struct GLOBAL {
  int PriceType,VolType,OrderType;
  double Unit; // smallest trade unit
  char Path[256]; // send path buffer
  char Key[256],Secret[256]; // credentials
  char Symbol[64],Uuid[256]; // last trade symbol and UUID
  char AccountId[16]; // account currency
} G; // parameter singleton
...

DLLFUNC int BrokerLogin(char* User,char* Pwd,char* Type,char* Accounts)
{
  if(User) { // login
    memset(&G,0,sizeof(G));
    strcpy_s(G.Key,User);
    strcpy_s(G.Secret,Pwd);
    return 1;
  } else  // logout
    return 0;
}

This function only sets up the G struct, a singleton that holds all global variables of the DLL. The User and Pwd arguments contain the Bittrex key and secret. They are taken from the Zorro login fields or from the account list. Type is the account type, ignored here because Bittrex has no demo accounts.  Account is the account identifier and also ignored since we’re not using sub-accounts.

Next comes the function to retrieve prices and other parameters of a particular cryptocurrency. It’s a bit more complex and requires a HTTP request to the API. Some requests require authentication, some not. For all this we first implement a send() function in the DLL that uses Zorro’s functions for sending http requests and generating a HMAC signature. The authentication method by the Bittrex REST API V3 is a bit complex:

To properly sign an authenticated request for the Bittrex v3 API, the following headers must be included: Api-Key, Api-Timestamp, Api-Content-Hash, Api-Signature. Api-Timestamp is the current time as a UNIX timestamp in epoch-millisecond format. Api-Content-Hash is a SHA512 hash of the request body, Hex-encoded (with no request body, a SHA512 hash of an empty string). For creating the Api-Signature, first generate a string by concatenating the following items: Contents of the Api-Timestamp header; the full URI used to make the request, including query string; the HTTP method of the request, in all caps (GET, POST, DELETE, etc.); Contents of the Api-Content-Hash header. Sign this string via HmacSHA512, using the API secret as the signing secret. Hex-encode the result and populate the Api-Signature header with it.

This is the implementation:

#define RHEADER "https://api.bittrex.com/v3/"
...

int sleep(int ms)
{
  Sleep(ms); 
  return BrokerProgress(0);
}

char* send(const char* Url,
  int Mode = 0,
  const char* Method = NULL,
  const char* Body = NULL)
{
  static char Url[1024], Header[2048], Signature[1024],
    Buffer1[1024*1024], Buffer2[2048];
  *Signature = *Header = 0;
  sprintf_s(Url,"%s%s",RHEADER,Url);
  if (Mode & 1) { // Authentication required
    strcpy_s(Header, "Content-Type:application/json");
    strcat_s(Header, "\nAccept:application/json");
    strcat_s(Header, "\nApi-Key: ");
    strcat_s(Header,G.Key);
    strcat_s(Header, "\nApi-Timestamp: ");
    __time64_t Time; _time64(&Time);
    static __time64_t Offset = 0;
    char* TimeStamp = i64toa(Time*1000 + Offset++); 
    strcat_s(Header, TimeStamp);
    strcat_s(Header, "\nApi-Content-Hash: ");
    char* Hash = hmac(Body, 0, 0, 512);
    strcat_s(Header,Hash);
    strcpy_s(Signature, TimeStamp);
    strcat_s(Signature, Url);
    if(Method && *Method)
      strcat_s(Signature, Method);
    else if(!Body)
      strcat_s(Signature,"GET");
    else
      strcat_s(Signature,"POST");
    strcat_s(Signature, Hash);
    strcat_s(Header, "\nApi-Signature: ");
    strcat_s(Header, hmac(Signature, 0, G.Secret, 512));
  }

  char* Response = Mode & 2? Buffer2 : Buffer1;
  int MaxSize = Mode & 2? sizeof(Buffer2) : sizeof(Buffer1);
  int Id = http_request(Url,Body,Header,Method);
  if(!Id) goto send_error;
// wait 30 seconds for the server to reply
  int Size = 0, Wait = 3000;  
  while (!(Size = http_status(Id)) && --Wait > 0)
    if(!sleep(10)) goto send_error;
  if (!Size) goto send_error;
  if(!http_result(Id,Response,MaxSize)) goto send_error;
  Response[MaxSize-1] = 0; // prevent buffer overrun
  http_free(Id);
  return Response;

// transfer unsuccessful?
send_error:
  if(Id) http_free(Id);
  return NULL;
}

The above code adds an authentication header with signature when Mode == 1. Mode == 2 selects a second, smaller response buffer and thus allows to evaluate two API responses at the same time. The sleep function generates a delay with a heartbeat to keep the Zorro window responsive during long requests. If it returns 0, someone has hit Zorro’s [Stop] key and all operations should be aborted. The Windows _time64 function has only 1-second resolution, so we add an incremented Offset for generating unique timestamps.

We’re now prepared to implement the BrokerAsset function:

double fixAmount(double Value)
{
  int Exp = log10(Value);
  if (Exp >= 0) Exp++;
  return pow(10,Exp);
}

DLLFUNC int BrokerAsset(char* Symbol,double* pPrice,double* pSpread,
double *pVolume, double *pPip, double *pPipCost, double *pMinAmount,
double *pMargin, double *pRollLong, double *pRollShort, double *pCommission)
{
  sprintf_s(G.Url,"markets/%s/ticker",fixSymbol(Symbol));
  char* Response = send(G.Url,2);
  if(!Response) return 0;
  double Bid = strvar(Response, "bidRate", 0.),
    Ask = strvar(Response,"askRate",0.);
  if (Ask > 0. Bid > 0. && pSpread) 
    *pSpread = Ask - Bid;
  double Last = strvar(Response, "lastTradeRate", 0.);
  if(Ask == 0. || G.PriceType == 2) 
    Ask = Last;
  if (Ask == 0.) return 0; // symbol does not exist
  if(pPrice) *pPrice = Ask;
  if(pVolume) {
    sprintf_s(G.Url,"markets/%s/summary",fixSymbol(Symbol));
    Response = send(G.Url,2);
    if (Response) {
      if (G.VolType == 4)
        *pVolume = strvar(Response, "volume", 0);
    else
        *pVolume = strvar(Response, "quoteVolume", 0);
    }
  }
  if (pMinAmount) { // get lot amount
    sprintf_s(G.Url,"markets/%s",fixSymbol(Symbol));
    Response = send(G.Url,2);
    if (Response) {
      *pMinAmount = fixAmount(strvar(Response,"minTradeSize",0.000001));
      if (pPip) {
        int Exp = strvar(Response,"precision",8);
        *pPip = pow(10,-Exp); 
        while (*pPip * *pMinAmount < 0.000000001)
         *pPip *= 10; // avoid too small pip cost
        if (pPipCost)
          *pPipCost = *pPip * *pMinAmount;
      }
    }
  }
  if (pMargin) 
    *pMargin = -100; // no leverage
  return 1;
} 

This function is supposed to return current price, current ask-bid spread, and current volume. It can also optionally request other asset specific parameters when available from the API. Otherwise Zorro will replace them with parameter values from the asset list. Broker APIs rarely provide all requested parameters. Make sure to only calculate and fill a parameter when its pointer passed to the function is nonzero. Most of the pointers are NULL most of the time.

The send function uses the second buffer because we’ll need price requests internally for calculating the account state. For getting lot amount, pip size, and pip cost, two more API requests are needed. The values from the response string are parsed with Zorro’s strvar function. The fixAmount function converts a value to its next-higher power of 10 – for instance, 7 is converted to 10 and 0.07 to 0.1. We’re doing this because we don’t want a strange number for the lot amount. The pip size is calculated from the precision, but we prevent it from going too small. Bittrex has no leverage, so the margin cost is always 100%.    

The next and final function sends an order to the API:

DLLFUNC int BrokerBuy2(char* Symbol,int Volume,double StopDist,double Limit,double *pPrice,int *pFill)
{
  if(!isConnected() || !Volume) return 0;

// compose the body
  char Body[256] = "{\n";
  strcat_s(Body,"\"marketsymbol\": \"");
  strcat_s(Body,fixSymbol(Symbol));
  strcat_s(Body,"\",\n\"direction\": \"");
  strcat_s(Body,Volume > 0? "BUY" : "SELL");
  strcat_s(Body,"\",\n\"type\": \"");
  strcat_s(Body,Limit > 0. ? "LIMIT" : "MARKET");
  strcat_s(Body,"\",\n\"quantity\": \"");
  double Size = labs(Volume);
  if(G.Amount < 1.) Size *= G.Amount;
  strcat_s(Body,ftoa(Size));
  if (Limit > 0.) {
    strcat_s(Body,"\",\n\"limit\": \"");
    strcat_s(Body,ftoa(Limit));
  }
  strcat_s(Body,"\",\n\"timeInForce\": \"");
  if ((G.OrderType&2) && Limit > 0.) 
    strcat_s(Body,"GOOD_TIL_CANCELLED"); // limit orders only
  else if (G.OrderType&1) 
    strcat_s(Body,"FILL_OR_KILL"); // fill all or nothing
  else 
    strcat_s(Body,"IMMEDIATE_OR_CANCEL");
  strcat_s(Body,"\"\n}");

  char* Response = send("orders",1,0,Body);
  if(!Response) return 0;

  char* Uuid = strtext(Response,"id","");
  if(!*Uuid) return 0; // failed
  strcpy(G.Uuid,Uuid);
  double Filled = strvar(Response,"fillQuantity",0);
  if(Filled == 0. && !(G.OrderType&2))
    return 0; // unfilled FOK/IOC order
  double Price = strvar(Response,"proceeds",0);
  if (Filled > 0. && Price > 0. && pPrice)
    *pPrice = Price/Filled;
  if (*pFill) *pFill = Filled/min(1.,G.Unit);
  return -1; 
}

The function first composes a message body in this JSON format (example):

{
  "marketSymbol": "ETH/BTC",
  "direction": "BUY",
  "type": "LIMIT",
  "quantity": "0.1",
  "limit": "0.008",
  "timeInForce": "IMMEDIATE_OR_CANCEL"
}

If the order is accepted, the response has this JSON format:

{
  "id": "12345-6789-007-4711",
  "marketSymbol": "ETH/BTC",
  "direction": "BUY",
  "type": "LIMIT",
  "quantity": "0.1",
  "limit": "0.008",
  "timeInForce": "IMMEDIATE_OR_CANCEL",
  "fillQuantity": "0.05",
  "commission": "0.000002",
  "proceeds": "0.00001",
  "status": "CLOSED"
}

The relevant fields, especially the id, the fill amount, and the fill price, are parsed from the response and returned. The return value -1 indicates to Zorro that the order generated no identifer number, but an UUID. It was stored and can be retrieved with a subsequent command. G.Unit is the lot amount that was generated with the previous BrokerAsset call. 

The remaining functions not described here – BrokerTrade, BrokerAccount, BrokerHistory2, and BrokerCommand –  are implemented in a similar way. You can find them in the full source code in the Source folder of the latest Zorro version. 

Update, November 2023: Bittrex recently announced that they will terminate their operation. So the Bittrex API plugin described herein lost its purpose, but you can still use the code as a template for connecting Zorro to any other broker or crypto exchange APIs – at least as long as they remain operational.  

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.

The algorithm is plain math, based on three variables: The vaccination percentage of your country, the vaccination percentage among cases, and the 7-day incidence, i.e. the number of cases per week and per 100,000 people.  ‘Case’ can be infection, hospitalization, or death, dependent on what result you want to calculate. Those 3 variables are often available from health organizations in most countries, or can be derived from publicly available statistics. The script calculates the vaccinated and unvaccinated incidences and the average survival time in weeks before a vaccinated or unvaccinated person is infected, hospitalized, or dead. It makes no assumptions about the effectivity of vaccinations.

First, incidence calculation. Let’s assume that your country has a total 7-day incidence of 400, and that 70% of people, and 35% of the infected are vaccinated. The incidence of the vaccinated is then:

I_vac = 400 * 35/70 = 200

The incidence of the unvaccinated:

I_unv = 400 * (100-35)/(100-70) = 867

Thus, in that hypothetical case you’re four times more likely to catch the virus when you’re unvaccinated – despite the relatively high 35% vaccinated infection rate. But what does this mean for your survival time?

The probability P to survive a week without becoming a ‘case’ depends on incidence I:

P = 1-I/100000

The chance to survive N weeks is thus

(1-I/100000)^N

The half life – the time T in weeks until 50% of people are infected – is given by

T = ln(0.5)/ln(P)

When we enter the above figures, first for the vaccinated:

T = ln(0.5)/ln(1-200/100000) = 346 weeks

Then for the unvaccinated:

T = ln(0.5)/ln(1-867/100000) = 80 weeks

Thus, in the given scenario most of the unvaccinated will be either dead or recovered within two years. Of course under the assumption that the incidence does not change during that time. We know that this is not the case: due to the exponential spread, pandemics tend to come and go in waves, as in the above image. Therefore, in the case of COVID, use not the current incidence, but the  average incidence from top to valley of the most recent wave for estimating your average survival time.

The script in C for Zorro:

// Covid Vaxxed vs Unvaxxed survival calculator ///////////////////////////

void click(int Row,int Col)
{
	if(Row != -1) return; // [Result] clicked?
	sound("click.wav");
	printf("\nTotal: Vaxx %.0f%% Unvaxx %.0f%%",
		slider(1),100-slider(1));
	printf("\nCases: Vaxx %.0f%% Unvaxx %.0f%%",
		slider(2),100-slider(2));
	var Vaxx = slider(3)*slider(2)/slider(1);
	var Unvaxx = slider(3)*(100-slider(2))/(100-slider(1));
	printf("\nIncidence: Vaxx %.0f Unvaxx %.0f",
		Vaxx,Unvaxx);
	printf("\nRisk/week: Vaxx %.2f%% Unvaxx %.2f%%",
		Vaxx/1000,Unvaxx/1000);
	printf("\nSurvival/weeks: Vaxx %.0f Unvaxx %.0f",
		log(0.5)/log(1.-Vaxx/100000),
		log(0.5)/log(1.-Unvaxx/100000));
	printf("\n");
}

void main()
{
	slider(1,70,1,99,"Total %","Vaccinated in population");
	slider(2,30,1,99,"Cases %","Vaccinated cases");
	slider(3,1000,1,2000,"Incidence","Weekly cases per 100,000"); 
	while(wait(100)); // keep script alive
}

Start the script and set up the 3 sliders to:

• the total vaccination percentage in the population,
• the vaccination percentage of cases,
• the 7-day per 100,000 case incidence.

Then click on [Result]. The printout should look like this:

Total: Vaxx 70% Unvaxx 30%
Cases: Vaxx 35% Unvaxx 65%
Incidence: Vaxx 200 Unvaxx 867
Risk/week: Vaxx 0.20% Unvaxx 0.87%
Survival/weeks: Vaxx 346 Unvaxx 80

The script can be downloaded from the 2021 repository. Zorro can be downloaded from zorro-project.com. 

If it were true…

Our politics and media are controlled by elites who worship Satan and run a child sex ring. According to a recent poll, 17% of Americans agree to this statement, 46% disagree, 37% say they don’t know. The 17% believers seem no  big surprise. In most groups of 100 people you’ll  find 17 crackpots . Or maybe 17 antisemitists, since “elites” or “globalists” are code for “the Jews”. But how is it possible that 37% “don’t know”?

You normally match a conspiration narrative with your model of reality. How plausible is it? If it were true, how would it work? How many had to be involved? How could it be hidden? Why would someone post it when it’s so secret? How trustworthy is the source? What interest has the source in spreading it? What interest have I in believing it?

It’s not too difficult to answer these questions. But if half of the US population still either wants to believe, or just doesn’t know whether their country is run by a satan worshipping, child abusing cabal, we have a problem.

The Bear Test

In the far past, alternative facts tended to correct themselves. If you propagated that cave bears don’t exist, sooner or later all your followers would end up in bears’ bellies. Reality check at work. But if you today believe in QAnon, chemtrails, evil elites, or China funded election stealing conspiracies, reality won’t reach out and slap you in the face. Your belief won’t put you at an immediate disadvantage. But nevertheless it will have consequences.

The obvious one is incompetent political leadership. Representative democracies compete all the time with other forms of government. The United States, with their economical and military power, could be the natural leader in that competition. Instead, in the last 4 years they became the global laughingstock. Administration by bragging and alternative facts can please followers, but is ill suited for real challenges, such as handling a pandemic. And when US voters decided in November 2020 to terminate that debacle, they were unaware that the worst was yet to come…

There might be other, more sinister consequences of widespread conspiration belief. Real conspirations can easily hide behind the walls of disinformation. Real whistleblowers are not taken seriously because of all the crackpots. In this way, conspiration theories can become self fulfilling prophecies.

Monetizing Twitter Likes

Trump & Co. are not the cause, but the effect of a global phenomenon – the emergence of bizarre parallel worlds that compete with reality. In those wolds, Trump has won the election, communists invade America, and evil scientists, pedophiles, the FBI, Fauci, and George Soros plot to take away citizens’ freedom, their health, even their steaks. Far-right social platforms such as Parler or Gettr are full of invented quotes or made up ‘news’ that endlessly confirm themselves. Those parallel worlds won’t disappear by voting, nor by censorship. Attempts by Twitter and others to shield users from the flood of misinformation are futile: People will always find ways of confirming what they want to believe. You cannot censor the Internet – and if you could, like China, it would be a questionable achievement. But it is still possible to fight disinformation. And even derive a decent income in this way. 

This post, 8 weeks after the election, was obviously at odds with reality. Still, 128700 people apparently agreed to the alternative fact. But instead of the lame “Election officials have certified bla bla bla…”, or even worse, censoring the nice TV lady – dear Twitter, how about this? 

If you’re Twitter, imagine that you would get 50 cents for any of the 128k likes to this post. Simply add a [Buy] and [Sell] button for any post with a controversial, but easily verifiable claim. Any user that’s buying Christina’s brilliant analysis can just click [Buy] and invest one dollar in that post. Then they will be able to like or retweet it. If someone is not buying it, they click [Sell] and short the post for 1 $. After a previously defined time, Twitter will evaluate the Pennsylvania outcome and distribute 50% of the stakes to the buyers or sellers, whoever were right. The remaining 50%  stay with Twitter. 

The Q Opportunity

You don’t need to wait for Twitter to monetize alternative facts. There are already some platforms that show how this works – check out  https://www.predictit.org/, https://polymarket.com/, or https://ftx.com/trade/TRUMPGO/USD. You can see that many conspiration believers are indeed investing money on those platforms. There are bets that Joe Biden will soon get arrested, or that Trump will soon have a comeback as president, and possibly execute some leading democrats on the way. The stakes are usually in the 80% range that this won’t happen, but a trade with 20% certain profit is still not to be sniffed at. Look out for conspiration bet opportunities! Do it before major contenders, such as Twitter or Facebook, enter that lucrative business. That will be in the interest of the common good – but it will likely reduce your profit. 

In this way, just being reasonable minded can earn you some decent extra income. Admittedly, if you’re a cult follower, conspiration believer, and/or Trump fanboy, you might have to pay the price – but hey: consider it a proof of faith. And if you lost too much money with your bets, you could be motivated to check facts before buying them. This will possibly improve your grip on reality. And can end up, maybe, with better leadership of your country. So it’s a win-win situation.

That’s my comment to last week’s events, and my today’s tip for getting rich, or even richer if you’re Twitter or Facebook. Establish fact brokerages, let more people bet on facts, and let the truth win!

One should think that most clients come up with very similar trading systems, so we could meanwhile just click them together from ready code. But it is not so. There’s apparently no limit of trading ideas. Almost any other system uses some new trading method, unusual data source, or exotic indicator. Still, the systems can be classified in several simple categories. Any of them has its specific success and failure rate.

Trading systems categorized

We classify the systems by their market and by their trading rules, both specified by the client. The 4 main markets are Forex/ CFDs, cryptocurrencies, stocks/ETFs/futures, and options. And the 4 main algorithmic trading methods are risk premia, market models, data mining, and indicator soups.  To recap:

Risk premium systems gain higher profits by accepting higher risks. In that category fall many stock portfolio rotation and options trading systems.

Market model systems exploit a particular market inefficiency by detecting anomalies in price curves. Mean reversion, market cycles, market events, or statistical arbitrage are typical model based trade methods. 

Data mining systems predict a price trend by evaluating signals with a machine learning algorithm (aka ‘artificial intelligence’). Those signals are usually derived from the order book or the price curve, but sometimes also from fundamental data or exotic data sources.

Indicator soups are the most often demanded systems. They do not target a particular market inefficiency, except maybe for going with the trend. They generate trade signals from a combination of traditional or new invented ‘technical indicators’. 

Some algo trading systems can fall in more than one category. For instance, a grid trader can be considered a risk premium system (high probability of small wins against low probability of high losses), but also a model based system (exploitation of volatility anomalies). If a system cannot be clearly assigned, it is split among several categories in the table below. We can see that clients favor some of the 16 possible combinations, while others are rare:

For determining the success or failure rate, we used 8-years backtests for unoptimized systems, and a walk forward analysis for optimized systems. A successful system had to return at least 12% CAGR for stocks, futures, or options, or 30% annual profit for Forex, CFDs, or cryptocurrencies. The R2 parameter had to be above 0.7. If clients ordered a Montecarlo analysis, the system had to pass it at 95% confidence. If one of those conditions was not fulfilled, the system was classified as failure. 

The percentages of successful systems:

 The average success rates at the end of the columns and rows are weighted by the number of systems. We can see that the overall success rate was only 66%. In 34% of cases we had to break the bad news to the client that it’s not advised to trade this system live. It produced no, or too little profit in the tests. Sometimes we could see what the problem was, and suggest ways to improve the system. But even total failures were no wasted money. When you know that your favorite manually traded system won’t work in the long run, you’ll save a lot more money than spent for programming and testing. 

And the winner is…

The statistics are spoiled by the forex and crypto systems, half of which were losers. This is at least better than most such systems from trading books or trader forums, of which 90% fail already in a simple out-of-sample test, or at least in a cluster or Montecarlo analysis. We got a surprising result in the ‘Indicator soup’ systems. You would normally expect that they all fail big time, since they are not based on a market model. But in fact almost every third indicator hodgepodge was successful, even in live trading on a test server. Maybe the clients knew more than we did. 

It is also a bit surprising that the most complex systems of all, the data mining systems that usually employ deep learning algorithms, did not fare much better. They have an acceptable success rate, but are easily surpassed by a certain sort of much simpler systems. 

Of all systems we tested so far, the big winners were the long-term trading systems for stocks, ETFs, or options. Of the option traders, the simpler systems had often better performance. It’s relatively hard to specify a losing option system, but some still managed it by using short expiration dates, complex entries, fancy rollovers, or intraday buying and selling. One of the very simple, but successful option traders was included in the Zorro scripts.

We found another trend that is not visible in the table: With a few exceptions like HFT or arbitrage, there was an almost linear correlation between time frames and performances. Systems on one, five, or ten minute bars were rarely profitable. The good systems traded mostly on 1-hour, 4-hour, or 24-hour time frames. Faster is not always better.

This does not mean that we all should now abandon forex and cryptos and trade only long-term options or ETF portfolios. Diversification is a key to success. All markets still have long periods of ineffectivity and plenty opportunities of trading profits. Maybe the statistics above help to look for them. 

Update (2025): This article was posted 5 years ago, and we have meanwhile more than 2000 systems programmed for clients. Due to technical progress especially with machine learning systems the overall success rate is now slightly better at 71%. But the success relations between the various trading methods are still the same.

Related articles

⇒ I Hired a Contract Coder

⇒ Build Better Strategies!

News about a “1000% tax for traders” and even a “tax on losses” spread quickly in January 2020. Hopefully, fake news? This is the relevant section of the new law (Art. 5 § 20 sentence 6 number 4):

“The Income Tax Act as published on October 8, 2009 (Federal Law Gazette I p. 3366, 3862), last amended by Article 1 of the Law of August 4, 2019 (Federal Law Gazette I p. 1122), is changed as follows. The following sentences are inserted after § 20 paragraph 6 sentence 4: Losses from financial assets within the meaning of paragraph 2 sentence 1 number 3 may only be offset in the amount of 10,000 euros with profits within the meaning of paragraph 2 sentence 1 number 3 and with income within the meaning of § 20 paragraph 1 number 11; sentences 2 and 3 apply mutatis mutandis with the proviso that losses that have not been offset each year may only be offset against profits up to the amount of 10,000 euros with profits within the meaning of paragraph 2 sentence 1 number 3 and with income within the meaning of § 20 paragraph 1 number 11. “

Translation: For the income tax, trading losses cannot anymore be offset against trading profits in excess of EUR 10,000 per year.

Bad enough. But surely they mean that an annual loss can only be offset in 10,000 EUR portions against annual profits in subsequent years? That was at least my interpretation. It made a sort of sense, and appeared harmless if you anyway do not plan to have an annual trading loss. But rumors said that they mean to tax not the annual net profit, but the profit of every single trade. Some said it’s even a tax on every favourable price tick of any open position, since this already constitutes a profit. In any case, this would quickly sum up to an insane tax amount – no matter if you win or lose. It’s in fact not a tax on income, but a tax on volatility, portfolio diversification, and hedging. And it was not even clear for which sorts of assets that tax is due. The relevant § 2 sentence 1 number 3 can be applied to options, futures, and bonds, but possibly also to all leveraged assets such as forex, CFDs, ETFs, and stocks. Only the risky and ecologically damaging speculation with cryptocurrencies seems exempt.

The win/loss offset mystery

For getting clarification, I wrote a letter:

Dear Federal Ministry of Finance,

on my blog I would like to inform readers about the current “Law for introducing a duty to report cross-border tax structuring”, in particular about Art 5 § 20 sentence 6 number 4. However, I am not sure that I fully understood the new law. Therefore I kindly ask you to briefly answer my subsequent questions.

1) Which of the following financial products fall under the referred “financial assets”: stocks, currencies (‘Forex’), options, futures, CFDs, savings contracts with a limited term, German treasury bonds?

2)  Which tax is due in this scenario: Bob owns EUR 20,000 that he invests in options trading. He buys about 200 options per year. In one winning year, 101 of the transactions ended with a profit of EUR 1000 each, 99 transactions with a loss of EUR 1000 each. The annual result is EUR 2000. The taxable profit is EUR 101,000, for which Bob has to pay a tax of EUR 91,000 x 25% = EUR 22,750 after deducting EUR 10,000 loss. The tax rate in relation to the EUR 2000 profit is 1137.5%.  Is the tax calculation correct?

3) Same scenario, but a losing year. 101 transactions ended with a loss of EUR 1000, 99 transactions with a profit of EUR 1000. The annual loss is EUR 2000. The taxable profit is EUR 99,000. After subtracting EUR 10,000, Bob has for his loss a tax liability of EUR 89,000 x 25% = EUR 22,250.

4) Same scenario, but Bob now tries to outwit the new trader tax. He buys a single long-term position for EUR 20,000 at the begin of the year. Due to leverage, the total value of the position has risen by EUR 100,000 by the middle of the year, then dropped again by EUR 100,000 by the end of the year. Bob sells at the end of the year at purchase price. The year ends profit-neutral and Bob intends to pay no tax.
   But the finance ministry is not as easily fooled. Since the tax also applies to the value increase in the middle of the year, the taxable profit minus loss deduction is EUR 90,000. Bob gets a tax bill of EUR 90,000 x 25% = EUR 22,500.

5) Same scenario as 2), but for stepping around the new trader tax, Bob now avoids closing positions. Instead he exercises all options, no matter of in the money or not, shortly before expiration. The paid premium is then not a loss, but a purchase fee. Since the broker offsets simultaneous long and short positions automatically, the finance ministry can do nothing about that.
   At the end of the year remains a single long position in the underlying with a value of EUR 2,000, which is then sold. The taxable profit amount is EUR 2,000 x 25% = EUR 500.

6) Same scenario as 2), but for stepping around the new trader tax, the broker has now offered a new structured product. Instead of closing positions, they are converted directly into another asset of the client’s choice that does not fall under § 20 sentence 6 number 4 (for instance, a nonleveraged stock). The premium for selling options is also not paid in cash, but in a position of that asset. At the end of the year, a position with a value of EUR 2,000 remains in Bob’s account, which is then sold. The taxable profit amount is EUR 2,000 x 25% = EUR 500.

I would be pleased if you could briefly tell me which of the tax calculations in the 5 scenarios are appropriate. I would also be interested in a brief explanation of the purpose and motivation behind the new law. And I would be very interested in an explanation how Bob in scenarios 2-4 is supposed to pay his taxes, since  they exceed all his capital.

Sincerely yours

Johann Christian Lotter

I was obviously not the only one who asked the ministry about the new law. I got a long formal response with little information content. It did not answer any of my questions, but confirmed that the 1137% tax and the tax on losses in scenarios 2 and 3 is for real. They did not comment on the tick tax of scenario 4.

Even the experts in Scholz’ finance ministry seem mystified about the implementation, motivation, or objective of this new law. It does not stand alone, but is part of a bundle of similar (although slightly less absurd) laws against retail traders and small investors. Their purpose is a mystery. They seem not motivated by populism. Except for the upcoming transaction tax, few know about them. Some say that they were originally intended against tax scams and large-scale speculation, and only designed in a wrong way.  But that is of course impossible, since it would imply a remarkable intellectual incapacity of our lawmakers. Maybe Scholz just intended to show a leftist position for his election to party chairman (which failed nevertheless). Or he’s really convinced that people who live from trading are all speculators and capitalist pigs, and must be hit whenever possible. Who knows. A personal confession at this point: I, also, am responsible for the new tax. I have always voted for Olaf Scholz’ party in the past. Often just out of tradition. This was apparently not always a wise decision.

Four ways to fix the tax

The trader tax will be in effect from 2021. It will then be unique in the world. No other country has a tax on volatility or diversification. I think it will not last long: Traders financially ruined by it, like Bob in some of the above examples, will challenge it in court. The Federal Supreme Court might eventually annul it due to unlawful overtaxation or its blatant absurdity. But until that happens, we’ll have to live with it.

Large-scale tax scammers, speculators, and hedge funds can laugh at Scholz’ tax constructs. They just incorporate, preferably offshore, and are exempt. That’s no solution for small private investors. Scenarios 5 and 6 are two possible ways to avoid the trader tax. A third, relatively simple method would be a trading account in a cryptocurrency. As long as the tax is not applied on open positions, converting one financial asset into another should be tax-neutral, since it does not realize any profit. The problem: You never know what bitcoin, or another account base that brokers might offer for outwitting the tax, will be worth next year. And the ministry was unable to precisely describe how the tax will be applied and which assets are affected. So there’s no guarantee that these workarounds do really work. The safe way is staying below the loss limit.  

I know that the Zorro platform, on demand of several German users, will get a new indicator, the Scholz Brake. This indicator will be implemented in the next Zorro release. It can be set up at the session start and at the begin of any year, like this:

if(is(INITRUN) || year(0) != year(1)) // any new year
  ScholzBrake = 10000; // activate the Scholz Brake

Once set, the ScholzBrake variable will be counted down by all trading losses of all Zorro instances that run on the same PC and have activated it. So the script can always check the distance to the critical EUR 10,000 total loss limit, and decide what to do. If the variable reaches zero, trading is automatically suspended until the end of the year.

This prevents you (mostly) from the effects of the new law. Of course at the price of not trading for the rest of the year. If you live from trading and have hit the Scholz limit early in the year, you got enough time to look for a new job. Maybe as an expert in the finance ministry.

References

1. Gesetz zur Einführung einer Pflicht zur Mitteilung
grenzüberschreitender Steuergestaltungen

2. ARD Börsenmagazin

3. ScholzBrake

4. Petition

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