Fully automated futures trading

In my system I pre-generated roll dates (historical and future ~ 100 years total) simply using the rules described in the contract specs on CME web-site or other corresponding exchanges, like "every third Friday before the last Monday prior to the next Tuesday" :), I used an open-source library that knows all historical public holidays to adjust for them.
Interesting, thanks for sharing. The way I do this is have offsets like Rob has in pysystem trade, then use those in combination with dates for which prices exist (I use this to eliminate weekends and holidays) to generate a list of roll dates. Then using that, and the actual prices, I generate adjusted prices. This works really well, unless in situations where data is wrong (wrong is worse than missing), like is the case with Platinum right now.

I'm using it exactly the same way as it would've been used in reality, so I'm pumping historical EOD prices as if they were real-time, and the system stitches them internally as in normally would
Out of curiosity, how long does this take to run a backtest?
I store adjusted prices, and at the beginning of the backtest I precompute and cache some stats, like all moving averages, all breakouts, risk etc. Then backtest just feeds in the current caapital and current price. For 12 instruments and 20 years this takes about 25 min, on a modern CPU. Granted, it's in Python and I haven't bothered to optimize so it only runs on a single core.
 
Out of curiosity, how long does this take to run a backtest?
I store adjusted prices, and at the beginning of the backtest I precompute and cache some stats, like all moving averages, all breakouts, risk etc. Then backtest just feeds in the current caapital and current price. For 12 instruments and 20 years this takes about 25 min, on a modern CPU. Granted, it's in Python and I haven't bothered to optimize so it only runs on a single core.

The full backtest with all 37 instruments that I trade in paper account with all historical data that I have (1990 or later, depending on the instrument) takes hours, like many hours but less than a day :) don't remember exactly, maybe 3-4h?. It's not optimised for it, as in reality, a lot of heavy operations would be done only once a day and then cached for the rest of the day, but when I run it in the backtest mode on EOD prices it recomputes everything on every tick (in this mode I only substitute one module of the system that normally feeds RT bid-ask ticks from IB to instead read EOD prices from a database add and subtract average bib-ask spread for this contract making 2 prices Bid and Ask out of a single EOD price).
The purpose of this is also to test my system in the exact conditions as if it was running in reality and see what comes out.
I have good hardware (btw, noways one can buy a used double-xeon-CPU+256GBRam+Chinese-brand motherboard with 2 sockets online for like 1000$, which is a beast of a machine, so hardware is definitely cheaper than my time and sanity to endlessly optimise all of that :) ). The biggest reason for slowness is that I also run it in a single thread, but I can't really make it parallel, I don't know how to split it. Per instrument wouldn't work because there are some tnter-instrument-dependencies and I can't run different time intervals in parallel either because there's still some path-dependence in the system(e.g. when we calculate the current overall portfolio risk for the risk-overlay, or the current drawdown to reduce the current base-capital, etc., although some of these things can probably be ignored in a backtest..)
But again, what I'm doing isn't really a backtest, it's just sort of technical quality-control\test of the system. A real research-style backtest is probably more appropriate to do in a vectorized form in some "matrix calculator" like matlab\python\R, ignoring certain not too-important things to make it possible and fast..

Btw, all the P&L stats I calculate on the individual contracts, because that's what I actually bought and sold in reality. And for things like volatility I use Rob's formulas (btw, the excel spreadsheets from here https://www.systematicmoney.org/systematic-trading-resources were quite useful for implementation as I remember )
 
Last edited:
Interesting.. "Prediction Company" had a sharp ratio of 3 over 15-20 year period:
(the video is from 2014).,
But looks like it was shut down in 2018. If, as it's written in some articles, it mostly did stat-arb, maybe that explains why my stocks pairs trading is not working at all :)
 
Last edited:
Interesting.. "Prediction Company" had a sharp ratio of 3 over 15-20 year period:
(the video is from 2014).,
But looks like it was shut down in 2018. If, as it's written in some articles, it mostly did stat-arb, maybe that explains why my stocks pairs trading is not working at all :)

This is the book about them that got me into the industry


GAT
 
Interesting.. "Prediction Company" had a sharp ratio of 3 over 15-20 year period:
(the video is from 2014).,
But looks like it was shut down in 2018. If, as it's written in some articles, it mostly did stat-arb, maybe that explains why my stocks pairs trading is not working at all :)

That's Doyne Farmer in the video who I met when he was visiting professor at Oxford in the same research centre which AHL funded. Fun guy!

GAT
 
Yes, which is why if you are using percentage returns for risk you should use the *current priced contract* as the denominator, and return difference of adjusted price as the numerator (this is what happens inside pysystemtrade). If you use return difference of the current contract you will get jumps when the contract rolls, so don't do that.

Thanks Rob. This ended up looking a bit complex in my implementation, so I'll put here which price I use for what if folks are interested. Below, by adjusted prices I mean prices modified to remove or smooth out differences between different contracts, also sometimes called stitching. By "carry prices" I refer to the actual traded price on a given day, for current (the one you're holding) and carry contracts.

- computing risk (volatility) - adjusted prices for the price diff, carry prices for percentage (as Rob mentions in the quote above)
- computing breakout rule - adjusted prices
- computing MAC rule - adjusted prices
- adjusting MAC rule for risk - risk computed on carry prices and current (last) price from carry prices (to get risk in price units)
- computing carry rule - carry prices
- price used for computing notional exposure - carry prices (this doesn't matter in the prod run as the latest price is the same in adjusted and carry series, but matters for backtest)
- price used as fill price in backtest - adjusted price (on the fence for this one, but if I use actual price here, then there are bumps in PnL when rolling. Maybe that's the way it's supposed to be?)
- price used for computing PnL in backtest - same as above

Note to self: it would be awesome if the next system you make would work with non-dated instruments. :D
 
Did anyone look into trading coffee, sugar and cotton futures? the margins seem to be low (2-3k$), so should be good for small-capital systems, and these commodities should probably add good diversification compared to adding another stock index..?
 
Did anyone look into trading coffee, sugar and cotton futures? the margins seem to be low (2-3k$), so should be good for small-capital systems, and these commodities should probably add good diversification compared to adding another stock index..?
Recently I did not look into these. But when I did so in the past I had the impression that the liquidity was rather low: the number of contracts being traded per day a lot lower than e.g. corn/wheat/soybean. Therefore I assumed that the bid/ask spread on these would be high. So I am currently not using these futures.
 
Back
Top