+7 906 906 18 20 Envelop 5927e2bc4f7195a77dda21f7859ed9d3bf9c3c724f49439b85f191cfc618519c info@megatrader.org

Calendar arbitrage, Part 2 - Trading Robot

In this article, we will have a look at a practical implementation of calendar arbitrage and create (with the help of Megatrader) a trading robot working on FORTS derivatives market. The trading robot will use a calendar spread between Gazprom shares' futures (GZU2 - GZM2).

We shall now proceed directly to robot’s logic creation, which is described by a built-in scripting language. Simple logic can be as follows: we put a long-period moving average (for example, 50000) on our chart, which will determine the mean line around which the spread will oscillate. Then, we sell spread when it rises by a set deviation from the mean, and buy when falls below a set level from the mean. When spread oscillates back to the mean, positions are closed.

In addition, a kind of position averaging, ie distribution of purchases or sales over several levels relative to the mean. For example, at a distance of 30 points we open first two positions. Then, if spread continues to deviate further, at 35 points we open 2 more positions, atf 40 - 2, etc. in increments of 5 points.

To implement this trading strategy in Megatrader one must first add necessary indicators to the chart. To do so, use the menu command "Chart” > “Add chart” ”> “Mean Price” to add a Mean Price indicator, which shows the average of best bid prices (Bid) and offer (Offer) spread (B+O/2). Tthen we use "Chart> “Add chart” > “Moving Average” to add a moving average, when choosing data source pick “Mean Price”. Also we should provide our moving average with an identificator to call it from our script. Let it be “MA”.

Now we can create a script. A simple script that implements the strategy will as follows:

Note that this script opens and closes positions gradually one by one. This is done to avoid possible problems related to the lack of liquidity in far futures contracts, where in case of lack of liquidity order will be executed at a worse price, so "slippage" occurs.

This script is ready and it will be usable, but some risks encountered in real market were omitted. Let's take a closer look at those risks and try to incorporate their handling in the script.

As noted in the first part of our article Calendar arbitrage, Part 1, the greatest risk of calendar arbitrage is slippage risk, ie risk of orders executed at worse prices than expected. A situation where slippage most likely occurs is shown on the chart below, where chart forms so-called "spikes" - moments of sharp price change or gapping:

These “spikes” occur usually for less than a quarter of a second, and if you try to make a deal at this "spike", most likely by the time of order getting to exchange, it will be gone, and your order will be filled on a different price.

To demonstrate the effect of slippage, the system will carry out two backtests:first - without delay in order execution, the second - with a 500ms delay. Backtesting period is from 05 to 14 June 2012, ie last 10 days before near futures contract expiry, at a time when slippage risk reaches its maximum. Both tests include a commission of 1 point, and maximum size of floating position is 10 contracts.

Graph of backtesting without delay:

Graph during testing with a delay of 500 milliseconds:

As can be seen from testing results, slippage of 0.5s "eats" all the profit system could generate. Of course, period chosen for backtesting was the most risky in terms of slippage, and if tested within a not so “competitive” period, the results would be better and not affected that much by slippage. However, it is best to foresee any risks that may fall in and prepare our robot to withstand them.

Based on our experience, we can say that avoiding slippage completely is all but impossible, however, we can reduce the chances of slippage occuring. There are two solutions: 1) increasing quotes and execution speed and 2) using a more complex algorithm of opening and closing positions, allowing to filter out "spikes".

The first option from our point of view is futile, because it involves “racing” with other traders and requires continuous investments in colocation and fast exchange connection to maintain a competitive advantage. Also, there will always be someone faster, be it connection, hardware or algorithm-wise. Therefore, we will use our second option - we will change the algorithm.

Let’s have a look at a simple “spike” filtering algorithm. The idea is to sell spread when not just Offer price exceeds sell level, but when short-period Moving Average of Offer price does that. Similarly, when short-period Moving Average of Bid price goes over buy level, we buy the spread. Short-period moving average filters out "spikes" and only reacts to significant price changes which will help to partially avoid slippage.

To implement this idea we should add two moving averages w/short period (for example 10). Then choose Bid as data source for first MA, Offer for the second one. To be able to call these averages in our script, we assigned some IDs, “BidMA” and “OfferMA” respectively:

Final script with “spike” filtering:

Backtest of modified script over the same period, 05 to 14 June 2012, with delay set to 500 milliseconds:

As you can see, the results of the system has improved a bit as it “chooses” time when to enter a position more carefully.

And finally, we backtested our trading robot with a new script on earlier period - from March 15 to May 14, 2012, which is working period for the system (futures expirations). Test parameters were the same: commission fee - 1 point, delay - 500 milliseconds, maximum size of of floating position - 10 contracts:

During this period, trading robot has earned 360 $. Let’s calculate how much of a ROI it gives us. Maximal margin for a contract did not exceed 70$ during the backtesting period. Given the fact that when trading calendar spreads on FORTS exchange, for example, margin is reserved for only one side of spread, it is easy to calculate that for trading a ten contracts spread we will need to have no more than 700$ of funds. Thus, the performance of strategy during two months (from March 15 to May 14, 2012) without reinvesting found out to be about 50%.

In conclusion, we would like to note that robot provided in this article is quite versatile and can be used to implement virtually any arbitrage strategies. It's would be enough to change instruments traded in composite instrument settings and set appropriate levels of spread deviation in the script.