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!

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

The profit diagram of an option is its profit or loss at or before expiration in dependence of the price of the underlying. Let’s assume that we know that the price of a certain asset will rise in the next months. So we buy a call option on that asset. Our profit diagram then looks like this:

This is the potential return when buying a current (June 2017) AAPL call option with 4 months expiration time. We have to pay $668 premium for that option. The current AAPL price is $144, and that’s also our strike price. The blue line is our profit or loss, dependent on the AAPL price at expiration. The option will expire out of the money when AAPL stays below $144, so we’ll then lose the premium. We’ll still lose a part of the premium if the option expires only slightly in the money. The break even point is at about $151. And if AAPL floats even higher at expiration time, we can collect huge profits of a multiple of the premium. So buying a call option means an unlimited profit chance at a limited risk. You can not lose more than the premium.

The green line in the diagram is the theoretical option value after 2 months, at half the expiration time. It is approximated with a finite difference method or calculated with the Black-Scholes formula, dependent on option type. The real option price is normally close to that theoretical value. So we can see that we could already sell the option with a profit after two months when the AAPL price is then above $148.

By the way, this option profit diagram resembles the response function of a Rectified Linear Unit in a neural network. So we can speculate that when a billion option traders permanently sell and buy large numbers of options, when the underlying price depends on option demand, and when profits are always reinvested in new options, the option market becomes a huge neural net. Some day artificial intelligence might emerge and the options start buying and selling themselves…

Option combos

Now let’s assume we know for sure that the AAPL price will move in the next time, but we do not know if it will rise or fall. For making profit in both cases, we just buy a call and a put option, both with the strike at the current price of $144:

We can see that a call and a put option with the same parameters don’t cancel out each other! The resulting profit diagram is just the sum of the profit diagrams of the single options. For both options we have to pay a $1310 total premium. If the AAPL price stays inside the $131 – $157 range, we lose. If it ends up outside this range, we win. If it ends up outside by a wide margin, we win big.

Now suppose we think an asset won’t be very volatile in the next time and its price will stay inside a range. We’ll then sell the two options instead of buying them. Selling instead of buying just turns the above profit diagram upside down. And we can already see the problem with that: The profit is now limited and the risk unlimited.

For fixing this, we need to add some more options to the combination:

For this profit diagram we’ve used 4 options. We bought one call at a strike $5 below the current price, another call at a strike $5 above the current price, and we sold short two calls with the strike at the current price. For the two long options we paid $1400 premium, and for the two short options we got $1340. This leaves us with $60 total premium cost, and a chance of up to $440 profit when the price stays inside the $140 – $148 range. This option combo, for whatever reason, got the name “Long Butterfly” by option traders.

By the way, you can see from this butterfly that you can really produce any profit diagram with a suited combination of options. The position of the butterfly peak is determined by the strike prices, its width by their distance, its height by the number of options. This way, many different butterfly peaks can be theoretically put together to a profit diagram of any shape. Unfortunately, you cannot just as freely determine its vertical position – a part of the diagram will be always below the zero line…

The code

Here’s a small C script (for Zorro) for experiments with all sorts of option combinations:

#include <contract.c>
void optionAdd(int Num,int Type,var StrikeOffs);

#define ASSET     "AAPL"
#define EXPIRY	  120	// 4 months
#define BUY	(1<<10)
#define SELL	(1<<11)

void combo() // "Butterfly"
{
	optionAdd(1,BUY|CALL,-5);  
	optionAdd(2,SELL|CALL,0);
	optionAdd(1,BUY|CALL,5);
}

//////////////////////////////////////////////////
#define POINTS 100 
var OptionGains[POINTS],OptionVals50[POINTS];
var UnderL,HistVol;

void optionPlot(int Num,CONTRACT* C,var Premium,var RangeMin,var RangeMax) 
{
	PlotScale = 10;
	var Step = (RangeMax-RangeMin)/POINTS;
	Step = round(Step+0.5,1); // round up
	RangeMin = round(RangeMin,1);

	int i;
	for(i=0; i<POINTS; i++)
	{
		if(Num == 0) {
			OptionGains[i] = OptionVals50[i] = 0;
		} else {
			var Price = RangeMin + i*Step;
			if(Price > RangeMax) break;
			var Gain = 0;
			var Strike = C->fStrike; 
			var Val50 = contractVal(C,Price,HistVol,0,0);
			switch(C->Type&(BUY|SELL|CALL|PUT)) {
				case BUY|CALL: 
					if(Price > Strike) Gain = Price - Strike;
					Gain -= Premium;
					Val50 -= Premium;
					break;
				case BUY|PUT: 
					if(Price < Strike) Gain = Strike - Price;
					Gain -= Premium;
					Val50 -= Premium;
					break;
				case SELL|CALL: 
					if(Price > Strike) Gain = Strike - Price;
					Gain += Premium;
					Val50 = Premium - Val50;
					break;
				case SELL|PUT: 
					if(Price < Strike) Gain = Price - Strike;
					Gain += Premium;
					Val50 = Premium - Val50;
					break;
			}
			OptionGains[i] += Multiplier*Num*Gain;
			OptionVals50[i] += Multiplier*Num*Val50;
			plotBar("Zero",i,0,0,LINE,BLACK);
			plotBar("ValueAt50%",i,Price,OptionVals50[i],LINE|LBL2,GREEN);
			plotBar("ValueAtExpiry",i,Price,OptionGains[i],LINE|LBL2,BLUE);
		}
	}
}

void optionAdd(int Num,int Type,var StrikeOffs)
{
	CONTRACT C;
	C.Type = Type;
	C.Expiry = EXPIRY;
	C.fStrike = round(UnderL+StrikeOffs,1);
	var Premium = contractVal(&C,UnderL,HistVol,0,0);
	C.Expiry = EXPIRY*0.5; // for the value at 50% expiration 
	optionPlot(Num,&C,Premium,0.8*UnderL,1.2*UnderL);
}

void run() 
{
	BarPeriod = 1440;
	StartDate = NOW;
	set(PRELOAD);
	if(is(INITRUN)) {
		initRQL();
		assetAdd(ASSET);
		assetHistory(ASSET,FROM_GOOGLE);
		asset(ASSET);
	}
	vars Close = series(priceClose());
	HistVol = Volatility(Close,20);
	UnderL = Close[0];
	Multiplier = 100;

	if(!is(LOOKBACK)) 
	{
		optionAdd(0,0,0); // reset the graphs
		combo();
		quit("Ok!");
	}
}

This script plots the above diagrams. The core of the script is the combo() function at the begin. It contains one or several optionAdd calls that get as parameters the number of options, the type (BUY, SELL, CALL, PUT, EUROPEAN, BINARY), and the strike difference to the current price. In the example above you can see the combination for the long butterfly. The asset and expiration can be set up in the #define lines above. The script downloads the current asset prices from Google and calculates the volatility that is needed for getting the options values and premiums. For running it you need Zorro, R, and the RQuantLib package from https://cran.r-project.org/bin/windows/contrib/3.3/RQuantLib_0.4.2.zip.

Some more examples of popular option combos:

// Call Spread
void combo()
{
	optionAdd(1, BUY|CALL, -5);
	optionAdd(1, SELL|CALL, 5);
}

// Put Spread
void combo()
{
	optionAdd(1, BUY|PUT, 5);
	optionAdd(1, SELL|PUT, -5);
}

Call or Put Spreads limit our risk as well as our profit to a fixed amount. The steepness of the center slope can be controlled with the strike difference. We can see from the diagrams that Spreads are (almost) equivalent to binary options – but with a much better payout factor. The diagrams are not completely symmetrical, and the Call Spread above has $514 potential profit and $486 potential loss – equivalent to a binary option with 105% payout. If the asset has the same likeliness of going up and going down, a Call Spread gives us a statistical advantage similar to the seller’s advantage of single options. With a Put Spread it’s the other way around.

The green line shows us whether it makes sense to sell the combo prematurely. Suppose we learned that the new iPhone tends to sudden explosions, and opened an AAPL Put Spread. When the AAPL price goes down and falls below $120 after 2 months, it makes no sense to wait until expiration, since the green line at 120 has almost the same value than the blue line. Only problem is that selling reduces our profit by the bid/ask spread and commission. An option expiration has no bid/ask spread and, if out of the money, also no commission.

Some more combos:

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

// Condor
void combo()
{
	optionAdd(1, BUY|CALL, -10);
	optionAdd(1, SELL|CALL, -5);
	optionAdd(1, SELL|CALL, 5);
	optionAdd(1, BUY|CALL, 10);
}

Combos that involve both selling and buying options – such as Spreads, Condors, or Butterflys – are especially attractive. Their investment is only the difference of the premiums, and the broker’s margin requirement is also accordingly smaller due to the limited risk. This allows trading with small capital and high leverage.

Get rich quick

Here’s my today’s get-rich-quick tip, this time for brokers. The problem with options is that you often need to wait weeks, months, or years until they finally expire and you can book your profit. Dear brokers, how about opening a market for short-term options? Options that expire at the end of each trading day, with strike prices in steps of cents, not dollars? Those options would be a very interesting instrument especially for short-term algorithmic trading. They would become very popular and produce a lot of commissions. Of course, 10% of those commissions are mine. I just patented this concept. Contact me for license conditions.

Conclusion

• Options can be clever combined for reducing the investment, limiting the risk, increasing the leverage, and generating profit diagrams of any shape.
• Depending on premiums, profit diagrams are often not perfectly symmetrical. This results in a statistial advantage (or disadvantage) of option combos with nondirectional assets.

I’ve included the OptionsCurve script in the 2017 script repository. Since price data download from Google rather than Yahoo was only recently implemented, you’ll need Zorro 1.59 or above. You’ll also need R and the RQuantLib package. In the final article of this series we’ll test a real options trading strategy.

Options Trading, Part 3

Options 101

Options are explained on many websites and in many trading books, so here’s just a quick overview. An option is a contract that gives its owner the right to buy (call option) or sell (put option) a financial asset (the underlying) at a fixed price (the strike price) at or before a fixed date (the expiry date). If you sell short (write) an option, you’re taking the other side of the trade. So you can enter a position in 4 different ways:

Buy a call – pay for the right to buy the underlying.
Buy a put – pay for the right to sell the underlying.
Write a call – get paid for the obligation to sell the underlying.
Write a put – get paid for the obligation to buy the underlying.

And this with all possible combinations of strike prices and expiry dates.

The premium is the price that you pay or collect for buying or selling an option. It is far less than the price of the underlying stock. Major option markets are usually liquid, so you can anytime buy, write, or sell an option with any reasonable strike price and expiry date. If the current underlying price (the spot price) of a call option lies above the strike price, the option is in the money; otherwise it’s out of the money. The opposite is true for put options. In-the-money is good for the buyer and bad for the seller. Options in the money can be exercised and are then exchanged for the underlying at the strike price. The difference of spot and strike is the buyer’s profit and the seller’s loss. American style options can be exercised anytime, European style options only at expiration.

Out-of-the-money options can not be exercised, at least not at a profit. But they are not worthless, since they have still a chance to walk into the money before expiration. The value of an option depends on that chance, and can be calculated for European options from spot price, strike, expiry, riskless yield rate, dividend rate, and underlying volatility with the famous Black-Scholes formula. This value is the basis of the option premium. The real premium might deviate slightly dependent on supply, demand, and belief in the underlying’s future price.

By reversing the formula with an approximation process, the volatility can be calculated from the real premium. This implied volatility is how the market expects the underlying to fluctuate in the next time. The partial derivatives of the option value are the Greeks (Delta, Vega – don’t know what Greek letter that’s supposed to be – and Theta). They determine in which direction, and how strong, the value will change when a market parameter changes.

That’s all basic info needed for trading options. By the way, it’s interesting to compare the performances of strategies from trading books. While the forex or stock trading systems described in those books are mostly bunk and lose already in a simple backtest, it is not so with option systems. They often win in backtests. And this even though apparently almost no book author has really backtested his system. Are options trading book authors just more intelligent than other trading book authors? Maybe, but we’ll see that there is an alternative explanation.

Why trading options at all?

They are more complex and more difficult to trade, and you need a Nobel prize winning formula to calculate a value that otherwise would simply be a difference of entry and exit price. Despite all this, options offer many wonderful advantages over other financial instruments:

• High leverage. With $100 you can buy only a few shares, but options of several hundred shares.
• Controlled risk. A short position in a stock can wipe your account; positions in options can be clever combined to limit the risk in any desired way. And unlike a stop loss it’s a real risk limit.
• Additional dimensions. Stock profits just depend on rising or falling prices. Option profits can be achieved with rising volatility, falling volatility, prices moving in a range, out of a range, or almost any other imaginable price behavior.
• Fire and forget. Options expire, so you don’t need an algorithm for closing them (unless you want to sell or exercise them on special conditions). And you pay no exit commission for an expired option.
• Seller advantage. Due to the premium, options can still produce a profit to their seller even if the underlying moves in the wrong direction.

Hacker ethics requires that you not just claim something, but prove it. For getting familiar with options, let’s put the last claim, the seller advantage, to the test:

void run() 
{
	BarPeriod = 1440;
	assetList("assetsIB");
	assetHistory("SPY",FROM_YAHOO|UNADJUSTED);
	asset("SPY");
	if(is(INITRUN)) dataLoad(1,"SPY_Options.t8",9);

	Multiplier = 100;
	contractUpdate("SPY",1,CALL|PUT);	
	int Type = ifelse(random() > 0,CALL,PUT);
	contract(Type,30,priceClose());
	static int LastExpiry = 0;
	if(ContractType && LastExpiry != ContractExpiry) {
		enterShort();
		LastExpiry = ContractExpiry;
	}
}

This is a very simple option trading system. It randomly writes call or put options and keeps the positions open until they expire. Due to the put/call randomness it is trend agnostic. Before looking into code details, just run it in [Test] mode a couple times (you’ll need Zorro version 1.53 or above). You’ll notice that the result is different any time, but it is more often positive than negative, even though commission is subtracted from the profit. A typical outcome:

You can see that most trades win, but when they lose, they lose big. Now reverse the strategy and buy the options instead of selling them: Replace enterShort() by enterLong(). Run it again a couple times (the script needs about 3 seconds for a backtest). You will now see that the result is more often negative – in fact almost any time.

It seems that options, at least the tested SPY contracts, indeed favor the seller. This is somewhat similar to the positive expectancy of long positions in stocks, ETFs, or index futures, but the options seller advantage is stronger and independent of the market direction. It might explain a large part of the positive results of option systems in trading books. Why are there then option buyers at all? Options are often purchased not for profit, but as an insurance against unfavorable price trends of the underlying. And why is the seller advantage not arbitraged away by the market sharks? Maybe because there’s yet not much algorithmic trading with options, and because there are anyway more whales than sharks in the financial markets.

Functions for options

We can see that options trading and backtesting requires a couple more functions than just trading the underlying. Without options, the same random trading system would be reduced to this short script:

void run() 
{
	BarPeriod = 1440;
	assetList("assetsIB");
	assetHistory("SPY",FROM_YAHOO);
	asset("SPY");

	if(random() > 0)
		enterLong();
	else
		enterShort();
}

Options require (at least) three additional functions:

• dataLoad(1,”SPY_Options.t8″,9) loads historical options data from the file “SPY_Options.t8” into a data set. Options data includes not only the ask and bid prices, but also the strike price, the expiration date, the type – put or call, American or European – of any option, and some rarely used additional data such as the open interest. Unlike historical price data, options data is usually expensive. You can purchase it from vendors such as iVolatility. But there’s an alternative way to get it for free, which I’ll describe below.
• contractUpdate(“SPY”,1,CALL|PUT) loads the current option chain. In backtest mode it’s loaded from the above data set, in live trading mode it’s loaded from the broker. The option chain is a list of all available option contracts of the selected underlying, with all available strike prices and all expiration dates. If you open it manually in the IB trading platform, it looks like this:

The center column lists different strike prices and expiry dates, the right and left parts are the ask and bid prices and order book sizes for their assigned call (left) and put options (right). The prices are per share; an option contract always covers a certain number of shares, normally 100. So you can see in the list above that you’ll collect $15 premium when you write a SPY call option expiring next week (Feb 03, 2017) with a $230 strike price. If SPY won’t rise above $230 until that date, the $15 are your profit. If it rised to $230 and 10 cents and the option is exercised (happens automatically when it expires in the money), you still keep $5. But if it suddenly soared to $300 (maybe Trump announced 100-ft. walls all around the US, all paid by himself), you have to bear a $6985 loss.

The image displays 54 contracts, but this is only a small part of the option chain, since there are many more expiry dates and strike prices available. The SPY option chain can contain up to 10,000 different options. They all are downloaded to the PC with the above contractUpdate function, which can thus take a couple seconds to complete.

• contract(Type,30,priceClose()) selects a particular option from the previously downloaded option chain. The type (PUT or CALL), the days until expiration (30), and the strike (priceClose() is the current price of the underlying) are enough information to select the best fitting option. Note that for getting correct strike prices in the backtest, we downloaded the underlying price data with the UNADJUSTED flag. Strike prices are always unadjusted.

Once a contract is selected, the next enterLong() or enterShort() buys or sells the option at market. The if() clause checks that the contract is available and its expiry date is different to the previous one (for ensuring that only different contracts are traded). Entry, stop, or profit limits would work as usual, they now only apply to the option value, the premium, instead of the underlying price. The backtest assumes that when an option is exercised or expires in the money, the underlying is immediately sold, and the profit is booked into the buyer’s account and deducted from the seller’s account. If the option expires out of the money, the position just vanishes. So we don’t care about exiting positions in this strategy. Apart from those differences, trading options works just as trading any other financial instrument.

Backtesting option strategies

Here’s an easy way to get rich. Open an IB account and run a software that records the options chains and contract prices in one-minute intervals. That’s what some data vendors did in the last 5 years, and now they are dear selling their data treasures. Although you can easily pay several thousand dollars for a few year’s option chains of major stocks, I am not sure who really owns the copyright of this data – the vendor, the broker, the exchange, or the market participants? This might be a legal grey area. Anyway, you need historical data for developing options strategies, otherwise you could not backtest them.

Here’s a method to get it for free and without any legal issues:

#include <contract.c>

string Code = "SPY"; 
string FileName = "History\\SPY_Options.t8";
var StrikeMax[3] = { 5,25,100 }; // strike ranges
var StrikeStep[3] = { 1,5,10 }; // strike step widths
int DaysMax = 180;  // max contract life in days
var BidAskSpread = 2.5; // bid/ask spread in percent
var Dividend = 2.0; // annual dividend in percent
int Type = 0; // or EUROPEAN, or FUTURE 

/////////////////////////////////////////////////////////

CONTRACT* c;
int N = 0;

void run() 
{
	BarPeriod = 1440;
	StartDate = 2011;
	EndDate = 2017;
	LookBack = 21;
	assetList("AssetsIB");
	assetHistory(Code,FROM_YAHOO|UNADJUSTED);
	asset(Code);
	if(is(INITRUN)) {
		initRQL();
		int MaxContractsPerDay = 2*(1+2*(StrikeMax[0]/StrikeStep[0] + StrikeMax[1]/StrikeStep[1] + StrikeMax[2]/StrikeStep[2])) * (1+DaysMax/7);
		int TotalContracts = (1+EndDate-StartDate)*252*MaxContractsPerDay;
		printf("\nAllocating %d Contracts",TotalContracts);
		c = (CONTRACT*)dataNew(1,TotalContracts,9);
		N = 0;
	}

	vars Close = series(priceClose());
	var HistVolOV = VolatilityOV(20);
	var Unl = Close[0];
	var Interest = yield();

	if(!is(LOOKBACK)) {
		var Strike;
		int i, Days = 1;
		while((dow()+Days)%7 != FRIDAY) Days++;
		for(; Days <= DaysMax; Days += 7)
		for(Strike = max(10,round(Unl-StrikeMax[2],StrikeStep[2])); Strike <= Unl+StrikeMax[2]; Strike)
		for(i = 0; i < 2; i++)
		{
			c->time = wdate();
			c->fUnl = Unl;
			c->fStrike = Strike;
			c->Type = Type | ifelse(i,PUT,CALL);
			c->Expiry = ymd(c->time+Days);
			c->fBid = contractVal(c,Unl,HistVolOV,0.01*Dividend,0.01*Interest);
			if(c->fBid < 0.01) continue; // probably no liquidity
			c->fAsk = (1.0+BidAskSpread/100)*c->fBid;

			if(abs(Unl-Strike) < StrikeMax[0]) Strike += StrikeStep[0];
			else if(abs(Unl-Strike) < StrikeMax[1]) Strike += StrikeStep[1];
			else Strike += StrikeStep[2];
			N++; c++;
		}
	}
	
	if(is(EXITRUN)) {
		printf("\nSaving %d Records",N);
		dataSort(1);	// reverse the entry order
		dataSave(1,FileName,0,N);
		printf("\nOk!");
	}
}

This script is a bit longer than the usual Zorro scripts that I post here, so I won’t explain it in detail. It generates artificial option chains for any day from 2011-2017, and stores them in a historical data file. The option prices are calculated from the underlying price, the volatility, the current risk free interest rate, and the dividend rate of the underlying. It uses three ranges of strike prices, and expiry dates at any Friday of the next 180 days. You need R installed for running it, and also the RQuantlib package for calculating option values. All functions are described in the Zorro manual. The yield() function returns the current yield rate of US treasury bills, and contractVal() calculates the premium by solving a differential equation with all option parameters. The source code of both functions can be found in the contract.c include file.

Due to the slow differential equation solver and the huge number of options, the script needs several hours to complete. Here’s a comparison of the generated data with real SPY options data:

The blue line are the artificial option prices, the black line are the real prices purchased from an options data vendor, both for 3-weeks SPY contracts with 10 points spot-strike distance. You can see that the prices match quite well. There are some tiny differences that might be partially random, partially caused by anomalies in supply and demand. For strategies that exploit those anomalies – that includes all strategies based on implied volatility – you’ll need real historical options prices. For option strategies that exploit only price or volatility changes of the underlying, the artificial data will most likely do. See, reading this article up to the end already saved you a couple thousand dollars.

Conclusion

• Options and option combinations can be used to create artificial financial instruments with very interesting properties.
• Option strategies, especially options selling, are more likely to be profitable than other strategies.
• Algorithmic option strategies are a bit, but not much more complex than strategies with other financial instruments.

I’ve included all scripts in the 2017 script repository, and also a historical data set with the yield rates (otherwise you needed the Quandl bridge or Zorro S for downloading them). You’ll need Zorro 1.53 or above, which is currently available under the “Beta” link of the Zorro download page. The error message from the free Zorro version about the not supported Quandl bridge can be ignored, due to the included yield rates the script will run nevertheless.

In the next article we’ll look more closely into option values and into methods to combine options for limiting risk or trading arbitrary price ranges. Those combinations with funny names like “Iron Condor” or “Butterfly” are often referred to as option strategies, but they are not – they are just artificial financial instruments. How you trade them is up to the real strategy. Some simple, but consistently profitable option strategies will be the topic of the third article of this mini-series.

=> Part 2

Strategies come in two flavors

You can use mainly two methods to develop trading systems: model-based and data-mining. A model-based system starts with a model of a market inefficiency – based on trader psychology, economy, market microstructure, or any other price affecting force. The inefficiency produces a price curve anomaly or pattern that deviates from the random walk and can – when predictive – be used for a trade algorithm. Examples of model based trading methods are trend following, mean reversion, price cycles, price clusters, statistical arbitrage, and seasonality.

The problem: A model is not the reality. It is a simplified image of it. It can not be proven and can often not even be falsified. Its validity can only be determined by its effects on the price curve. The usefulness of this method thus depends on the significance and long-term stability of its price curve anomalies. For judging this you need good test algorithms. 

The pure data mining method works the other way around. It just looks for price curve patterns and attempts to fit an algorithm to them. By which market forces the patterns are caused is of no interest; only assumption is that patterns of the past will repeat in the future. This allows the generation of trade systems, often, but not always with machine learning software. The most popular methods in this approach are trial-and-error TA, candle patterns, regression, autocorrelation, k-means clustering, neural networks, support vector machines, and decision trees.

The advantage of data mining is that you do not need to care about market hypotheses. The disadvantage: those methods usually find a vast amount of random patterns and thus generate a vast amount of worthless strategies. Since mere data mining is a blind approach, distinguishing real patterns – caused by real market inefficiencies – from random patterns is a challenging task. Even sophisticated reality checks can normally not eliminate all data mining bias. Not many successful trading systems generated by data mining methods are known today.

Are you cleverer than the market?

Obviously, no trading system would work when market inefficiencies do not exist. And it would not work either when they exist, but can not be exploited since better equipped players are doing that already. In this first part of the mini-series I look into the possibility of trading better than the majority of market participants, a prerequisite of a successful strategy. 

The three hypotheses of market efficiency that you’ll hear from time to time are as follows: 

• Hypothesis A: The markets are efficient. Prices follow real events, such as the publication of company results, and reflect the real value of the asset. All traders are ‘informed’, decide rationally and act immediately. Price curves are mostly random-walk curves with no information for predicting future prices. Technical trading systems can not work, or if they do, it’s just luck.
   
• Hypothesis B: The markets are not efficient, but their inefficiencies are of no value for private traders. Only large trading firms and hedge funds can exploit them successfully, since they have lots of capital, very fast computers, very experienced analysts and very clever quants – much more intelligent than you. Beware of entering their terrain, or else you’ll become their prey.
   
• Hypothesis C: Enough market inefficiencies are free for you to exploit. Large trading firms and hedge funds are too slow and cumbersome to tackle them effectively. Their capital and their fast computers give them no real advantage in the game that you’re going to play. Neither do their clueless analysts, overpaid traders, and overestimated quants.

Not many today do still believe in hypothesis A. It can be easily shown that most price curves do not follow a random walk (a fellow blogger recently posted a great article about Hacking the Random Walk Hypothesis). And the markets are anything but rational or effective. Counter-examples are plenty. Jack Schwager, in his book ‘Market Sense and Nonsense’, listed cases of blatant market dumbness and grotesque analyst failures. More often than not, asset prices are far, far away from their true value. Although all this is anecdotical evidence, a pattern is visible. The markets react fast and firm when rumors or news give them a clear direction. But when the information is a little more subtle and requires a minimum of interpretation, they react slow or not at all. Here’s the story of a typical example.

The Swiss Franc case

In September 2011 the Swiss National Bank established a price cap to the Swiss Franc. Purpose was protecting the tourism and export industries against an overvalued currency. The limit was set to an EUR/CHF price of 1.20, and the SNB vowed to defend it against all enemies.

A price cap is a rare and striking market inefficiency. It can immediately be translated into a highly profitable, almost risk-free trading system (how this works is explained below). So you would normally expect a strong market reaction after the EUR/CHF price move to 1.20. But the reaction was a long time in the coming.

No doubt, Switzerland is an obscure European country and for the major US trading firms probably known for cheese, if at all. They did either not notice the price cap, or they had just forgotten to equip their European offices with modern communication gear. So it took the mounted messenger from Europe three months riding over hill and dale, sailing over the Atlantic Ocean, maybe fighting off brigands, pirates, and indians on his way, to reach New York City and shout: “The Swiss have a price cap!”.

But what the heck can you do with a price cap? By January 2012, large market participants had finally come up with an idea. Not something as subtle as a trading system. Instead, they began to buy mad amounts of Francs for bringing pressure on the EUR/CHF price: 

The obvious idea was that when there is a price boundary, there must be some profit in breaking it. A lot of effort, patience and money was put in that game. From May 2012 on the EUR/CHF price was nailed shut to its 1.20 limit. But alas, the price cap collapse did not happen. You do not mess with the SNB. During 2012 the Swiss erected a wall of 200 billion dollars for defending the price cap. The attackers never had a chance. The first gave up in September 2012, and by the end of January 2013 all had retreated with their tails between their legs (and probably painful losses):

Now the way was free for algorithmic systems. During the 2012 CHF battle they were forced to inactivity, since private traders and hackers lack the capital to participate in a market manipulation game. In January 2013 the first hackers started to exploit the market inefficiency with a specific method, a Grid Trader. This turned out a money-printing machine.

The money press algorithm

A grid trader is a very simple system. It places pending long and short trades at a fixed grid above and below the current price, with profit targets of the same grid distance. So trades are opened and closed whenever the price crosses a grid line in any direction. Such a system has a hypothetical 100% win rate, since trades close either in profit or not at all. But grid traders normally use a virtual hedging mechanism that closes an open position instead of opening a new one in opposite direction. This improves the total profit by reducing trade costs and margin. But it allows trades to be closed with a loss. So the real win rate of a grid trader is in the 60% area.

This is the Zorro script of such a grid trader:

// helper function to check if the grid line has no trade
bool isFree(var Price,var Grid,bool IsShort)
{
  bool result = true;
  for(open_trades) {
    if(TradeIsShort == IsShort
      && between(TradeEntryLimit,Price-Grid/2,Price+Grid/2))
        result = false;
  }
  return result;
}

// EUR/CHF grid trader main function
int run() 
{
  BarPeriod = 60;
  Hedge = 5; // activate virtual hedging

  var Grid = 20*PIP; // set grid distance to 20 pips
  var Close = priceClose();
 
// place pending trades at 5 grid lines above and below the Close
  int i;
  for(i = Close/Grid - 5; i < Close/Grid + 5; i++)
  {
    var Price = i*Grid;
// place short trades with profit target below the current price
    if(Price < Close && isFree(Price,Grid,true))
      enterShort(1,Price,0,Grid); 
// place long trades with profit target above the current price
    else if(Price > Close && isFree(Price,Grid,false))
      enterLong(1,Price,0,Grid);
  }
}

A grid trader is a typical model-based system. It assumes that some market force keeps the price inside a channel. This is the case here: The cap prevents the EUR/CHF from falling below 1.20, but it also prevents it from rising too high, since the SNB must eventually buy back all the Francs they have sold for defending the cap. The mathematical model of this would be a random walk with a 1.20 boundary and some drift term that pulls the price down. Such a constraint is a prerequisite for a grid trader; without it grid trading would be just high-risk gambling and is consequently listed in the irrational trade methods collection.

This is the P&L-curve (blue) of the above script applied to the EUR/CHF in 2013:

We can see that large price fluctuations, as in January and May, cause large drawdowns (the red underwater peaks in the chart). But since the fluctuations have a limit, we can estimate the maximum loss and just keep enough capital on the account. This way the above script produces an annual return of 130% and a Sharpe Ratio of 1.7 – with virtually no risk ( as long as the price cap stays in place).

The news of such a trading strategy slowly spread in 2013. More and more private traders and financial hackers, and also more and more large market participants jumped on the bandwagon. Three years after installation of the price cap, thousands of such systems sat on the EUR/CHF price curve like leeches and sucked off money. The result was a continuously falling price volatility:

Lower volatility means lower profits to a grid trader. More capital must be invested and the grid must be tightened for compensating. But there is a natural limit. You can not have a grid size smaller than the trading costs. By autumn 2014 the volatility was close to zero. And this was accompanied by an ominous price downwards drift, as if some large market participant (possibly the SNB itself) would continously sell EUR and buy CHF in anticipation of some future event. That would have been high time for private traders to retreat from the game. Of course, thickheads like me didn’t. It is well known what then happened to the Swiss Franc:

In the morning of 15 January 2015, the SNB gave a press conference and announced the cancellation of the price cap. The EUR/CHF fell in minutes like a stone from the 1.20 limit to below parity. Obviously a fast and extreme market reaction – very different to the introduction of the price cap 4 years before. The price drop killed many accounts and even a few brokers. By the way, the ‘real value’ of the EUR/CHF, based on the relative buying power of the two currencies, was in the 1.50 area all the time. 

What can we learn from this and from similar examples?

Conclusions

• The financial markets react immediately and often hysterically on news with a clear price upwards/downwards direction.
• The markets react slow or not at all on more subtle information. It can take years until they become aware of new inefficiencies or trading methods.
• The markets prefer brute-force methods. Complex strategies are normally only used by a small part of market participants.
• Simple systems based on very obvious inefficiencies can be extremely profitable, but have a limited lifetime. 

The next parts of the Build Better Strategies series will deal with model-based systems, with known market inefficiencies and with a methodical approach of exploiting them. 

⇒ Build Better Strategies – Part 2

Choice of languages

Algo trading systems are normally based on a script in some programming language. You can avoid writing scripts entirely by using a visual ‘strategy builder’, ‘code wizard’ or spreadsheet program for defining your strategy. But this is also some sort of programming, just in a different language that you have to master. And visual builders can only create rather simple ‘indicator soup’ systems that are unlikely to produce consistent trading profit. For serious algo trading sytems, real development, and real research, there’s no stepping around ‘real programming’.

You’re also not free to select the programming language with the nicest or easiest syntax. One of the best compromises of simplicity and object orientation is probably Python. It also offers libraries with useful statistics and indicator functions. Consequently, many strategy developers start with programming their systems in Python… and soon run into serious limitations. There’s another criterion that is more relevant for system development than syntax: execution speed.

Speed mostly depends on whether a computer language is compiled or interpreted. C, Pascal, and Java are compiled languages, meaning that the code runs directly on the processor (C, C++, Pascal) or on a ‘virtual machine’ (Java). Python, R, and Matlab is interpreted: The code won’t run by itself, but is executed by an interpreter software. Interpreted languages are much slower and need more CPU and memory resources than compiled languages. It won’t help much for trading strategies that they have fast C-programmed libraries. All backtests or optimization processes must still run through the bottleneck of interpreted trading logic. Theoretically the slowness can be worked around with ‘vectorized coding’ – see below – but that has little practical use.

R and Python have other advantages. They are interactive: you can enter commands directly at a console. This allows quick code or function testing. Some languages, such as C#, are inbetween: They are compiled to a machine-independent interim code that is then, dependent on implementation, either interpreted or converted to machine code. C# is about 4 times slower than C, but still 30 times faster than Python.

Here’s a benchmark table of the same two test programs written in several languages: a sudoku solver and a loop with a 1000 x 1000 matrix multiplication (in seconds):

Speed becomes important as soon as you want to develop a short-term trading system. In the development process you’re all the time testing system variants. A 10-years backtest with M1 historical data executes the strategy about 3 million times. If a C-written strategy needs 1 minute for this, the same strategy in EasyLanguage would need about 30 minutes, in Python 2 hours, and in R more than 10 hours! And that’s only a backtest, no optimization or WFO run. If I had coded the trend experiment in Python or R, I would today still wait for the results. You can see why trade platforms normally use a C variant or a proprietary compiled language for their strategies. HFT systems are anyway written in C or directly in machine language.

Even compiled languages can have large speed differences due to different implementation of trading and analysis functions. When we compare not Sudoku or a matrix multiplication, but a real trading system – the small RSI strategy from this page – we find very different speeds on different trading platforms (10 years backtest, ticks resolution):

• Zorro: ~ 0.5 seconds (compiled C)
• MT4:  ~ 110 seconds (MQL4, a C variant)
• MultiCharts: ~ 155 seconds (EasyLanguage, a C/Pascal mix)

However, the differences are not as bad as suggested by the benchmark table. In most cases the slow language speed is partically compensated by fast vector function libraries. A script that does not go step by step through historical data, but only calls library functions that process all data simultaneously, would run with comparable speed in all languages. Indeed some trading systems can be coded in this vectorized method, but unfortunately this works only with simple systems and requires entirely different scripts for backtests and live trading.

Choice of tools

Zorro is a software for financial analysis and algo-trading – a sort of Swiss Knife tool since you can use it not only for live trading, but also for all sorts of quick tests. It’s my software of choice for financial hacking because:

• It’s free (unless you’re rich).
• Scripts are in C, event driven and very fast. You can code a system or an idea in 5 minutes.
• Open architecture – you can add anything with DLL plugins.
• Minimalistic – just a frontend to a programming language.
• Can be automatized for experiments.
• Very stable – I rarely found bugs and they were fixed fast.
• Very accurate, realistic trading simulation, including HFT.
• Supports also options and futures, and portfolios of multiple assets.
• Has a library with 100s of indicators, statistics and machine learning functions, most with source code.
• Is continuously developed and supported (new versions usually come out every 2..3 months).
• Last but not least: I know it quite well, as I’ve written its tutorial…

A strategy example coded in C, the classic SMA crossover:

void run()
{
  double* Close = series(priceClose());
  double* MA30 = series(SMA(Close,30));	
  double* MA100 = series(SMA(Close,100));
	
  Stop = 4*ATR(100);
  if(crossOver(MA30,MA100))
    enterLong();
  if(crossUnder(MA30,MA100))
    enterShort();
}

More code can be found among the script examples on the Zorro website. You can see that Zorro offers a relatively easy trading implementation. But here comes the drawback of the C language: You can not as easy drop in external libraries as in Python or R. Using a C/C++ based data analysis or machine learning package involves sometimes a lengthy implementation. Fortunately, Zorro can also call R and Python functions for those purposes.

R is a script interpreter for data analysis and charting. It is not a real language with consistent syntax, but more a conglomerate of operators and data structures that has grown over 20 years. It’s harder to learn than a normal computer language, but offers some unique advantages. I’ll use it in this blog when it comes to complex analysis or machine learning tasks. It’s my tool of choice for financial hacking because:

• It’s free. (“Software is like sex: it’s better when it’s free.”)
• R scripts can be very short and effective (once you got used to the syntax).
• It’s the global standard for data analysis and machine learning.
• Open architecture – you can add modules for almost anything.
• Minimalistic – just a console with a language interpreter.
• Very stable – I found a few bugs in external libraries, but so far never in the main program.
• Has tons of “packages” for all imaginable mathematical and statistical tasks, and especially for machine learning.
• Is continuously developed and supported by the global scientific community (about 15 new packages usually come out every day).

This is the SMA crossover in R for a ‘vectorized’ backtest:

require(quantmod)
require(PerformanceAnalytics)

Data <- xts(read.zoo("EURUSD.csv", tz="UTC", format="%Y-%m-%d %H:%M", sep=",", header=TRUE))
Close <- Cl(Data)
MA30 <- SMA(Close,30)
MA100 <- SMA(Close,100)
 
Dir <- ifelse(MA30 > MA100,1,-1) # calculate trade direction
Dir.1 <- c(NA,Dir[-length(Dir)]) # shift by 1 for avoiding peeking bias
Return <- ROC(Close)*Dir.1 
charts.PerformanceSummary(na.omit(Return))

You can see that the vectorized code just consists of function calls. It runs almost as fast as the C equivalent. But it is difficult to read, it can not be used for live trading, and many parts of a trading logic – even a simple stop loss – cannot be coded for a vectorized test. Thus, so good R is for interactive data analysis, so hopeless is it for writing trade strategies – although some R packages (for instance, quantstrat) even offer rudimentary optimization and test functions. They all require an awkward coding style and do not simulate trading very realistically, but are still too slow for serious backtests.

Although R can not replace a serious backtest and trading platform, Zorro and R complement each other perfectly: Here is an example of a machine learning system build together with a deep learning package from R and the training and trading framework from Zorro.

More hacker’s tools

Aside from languages and platforms, you’ll often need auxiliary tools that may be small, simple, cheap, but all the more important since you’re using them all the time. For editing not only scripts, but even short CSV lists I use Notepad++. For interactive working with R I recommend RStudio. Very helpful for strategy development is a file comparison tool: You often have to compare trade logs of different system variants and check which variant opened which trade a little earlier or later, and which consequences that had. For this I use Beyond Compare.

Aside from Zorro and R, there’s also a relatively new system development software that I plan to examine closer at some time in the future, TSSB for generating and testing bias-free trading systems with advanced machine learning algorithms. David Aronson and Timothy Masters were involved in its development, so it certainly won’t be as useless as most other “trade system generating” software. However, there’s again a limitation: TSSB can not trade or export, so you can not really use the ingenious systems that you developed with it. Maybe I’ll find a solution to combine TSSB with Zorro.

References

TIOBE index of top programming languages

Speed comparison of programming languages

Update (November 2017). The release of new deep learning packages has made TSSB sort of obsolete. For instance, the H2O package natively supports several ways of features filtering and dimensionality reduction, as well as ensembles, both so far the strength of TSSB. H2O is supported with Zorro’s advise function. Still, the TSSB book by Davin Aronson is a valuable source of methods, approaches, and tips about machine learning for financial prediction.

Download links to the latest versions of Zorro and R are placed on the side bar. A brief tutorial to both Zorro an R is contained in the Zorro manual; a more comprehensive introduction into working with Zorro can be found in the Black Book.

Because the money amount always corresponds to the same amount of private and public debt, this debt amount also must inevitably grow, in spite of all the political lamentoes. Reducing public debt would either destroy money or increase private debt proportionately. This happened in fact in the United States around the turn of the millennium, when then-President Bill Clinton managed to get by without borrowing, and even achieved a budget surplus. Which caused interests to drop and banks to look elsewhere for distributing their money. The indirect result of Clinton’s good deed was a massive increase in private debt that eventually led to the mortgage crash of 2007.

How to acquire it in large amounts

Money is considered a good thing in almost all cultures. After all, it allows you to do the things you want, and – even more important – not to do things you don’t want to do. It thus represents freedom. You can get to it with different methods. The most obvious is taking away other people’s money. Here’s the Top Ten fortunes by known villains, according to Forbes (in US $):

1. Hugo Drax – 7.6 billion
2. Auric Goldfinger – 6.5 billion
3. Max Zorin – 5.3 billion
4. Lex Luthor – 4.7 billion
5. Franz Sanchez – 1 billion
6. Ernst Stavro Blofeld – 640 million
7. Karl Stromberg – 640 million
8. Elektra King – 420 million
9. Francisco Scaramanga – 115 million
10. Dr. Julius No – 110 million

But the most successful in money taking are not, as you might think, drug cartel bosses or leaders of criminal underground organizations, but presidents and other heads of state. They can take their share of money with no risk, since they need not fear the law. Here’s the Top Ten of the acquired fortunes by this way (in US $):

1. Muammar Gaddafi, Libya – 55 billion
2. Hosni Mubarak, Egypt – 50 billion
3. Mohamed Suharto, Indonesia – 25 billion
4. Alexander Lukashenko, Belarus – 12 billion
5. Mobutu Sese Seko, Congo – 7 billion
6. Ben Ali, Tunisia – 4 billion
7. Gnassingbé Eyadéma, Togo – 4 billion
8. Obiang Nguema, Equatorial Guinea – 3 billion
9. Slobodan Milosevic, Serbia – 1 billion
10. ‘Baby Doc’ Duvalier, Haiti – 600 million

This list does naturally not include assets of monarchs such as the Sultan of Brunei, who have no need of pilfering because the country belongs to them by law anyway. Or of dictators like Wladimir Putin, whose estimated 125 billion booty (plus a 17,000 sqft palace) officially does not belong to them, but is kept for them by friendly oligarchs. The listed sums must also be considered in relation to the economy of the country. To bag 600 million in grinding poor Haiti is a much more impressive performance than the lousy one billion that Milosevic could siphon off in industrialized Serbia. But as long as you’re neither a supervillain, nor a head of state, nor both at the same time, you have no choice but to use other means to acquire money. There’s also the method of buying something cheap and selling it dear. Not as profitable as being a head of state, but it still can produce some handsome gains (annual income in US $):

1. Jim Simons, Renaissance – 1.7 billion
2. Ken Griffin, Citadel – 1.7 billion
3. Raymond Dalio, Bridgewater – 1.4 billion
4. David Tepper, Apaloosa – 1.4 billion
5. Izzy Englander, Millenium – 1.1 billion
6. David Shaw, Shaw Group – 750 million
7. John Overdeck, Two Sigma – 500 million
8. David Siegel, Two Sigma – 500 million
9. Andreas Halvorsen, Viking – 370 million
10. Joseph Edelman, Perceptive – 300 million

All in this list acquired their wealth with algorithmic trading. Which is the topic of most of the rest of this blog. It does not produce any goods. But on the other hand, it does not steal from anyone. On the contrary, private, small-scale financial trading can boost demand and soften economic inequality. It can redistribute money from the rich to the poor. So it should be rewarded by the government, for instance by a tax exemption. Well, one can dream, at least…

Why financial hacking?

Part of my job is developing financial tools and trading systems for clients. So far we coded hundreds of trading strategies with all sorts of algorithms for all sorts of financial instruments. Some worked and fulfilled the client’s expectations. Some failed miserably. And some worked in the backtest, but not in live trading. Coming from a background of theoretical physics and computer game programming, I wondered why trading seems not to be an exact science at all. What is the difference between a successful and a doomed strategy? And how can you determine that before actually trading it?

On this blog I’ll attempt a hacking approach to algorithmic trading. Hacking is nothing illegal, it’s just a pragmatic way to solve problems. Hackers prefer experiment over theory. They don’t give a damn about the wisdom of gurus or authorities. So I’ll start with considering all praised trade systems worthless and all “trader’s wisdom” irrational and nonsense until proven otherwise. I will try to evaluate by systematic experimenting whether, why, when, and how algorithmic trading does work. My goal is to find out how it can be a reliable income source for a private trader. This might require complex statistical or machine learning algorithms – but that’s no big deal with today’s software tools. All scripts and software to the articles will be put up for download, so anyone interested can reproduce all the results and use the strategies. After all, successful private trading is for the common good.

As this blog is about algorithmic trading, I’m going to post here a lot of algorithms and source code. Naturally not any trader is able to read code. On the other hand, some basic code and math understanding is required for making sense of the articles. To go from zero to a full understanding of the articles on this blog, here’s a list of Useful Books.