Why you need two systems for running automating trading strategies

Trading Reality — Markets in Production

SubscribeSign in

Why you need two systems for running automating trading strategies<br>Issue 1 · The Model Is Not the Market — Gate 3: how to run in production?<br>Jul 15, 2026

Share

Suppose the gates behind you are passed. The numbers were honest. The edge is real — you can say who pays you and why. There is one gate left, and it is the one where the invoice arrives: you are cashing in — or out. This is where the model finally touches the market, and the issue takes its title from what happens next.<br>Rob Carver spent seven years at AHL and has run his own fully automated futures system, on his own money, since 2014. He has sat in both seats this problem has — the institutional one and the kitchen-table one — which is why his answer to it is structural rather than motivational.<br>He wrote this piece in 2014, and I have deliberately not asked him to update a word, because the intervening decade is the argument. We now have tools that will write a working backtest in an afternoon. The temptation to promote that artifact into production has never been stronger, and the gap Carver describes — between code that simulates and code that runs — has not moved an inch. The backtest got cheap. Production didn’t. And my suggestion to read this piece as if it was written today, in the age of “AI confusion”.<br>The intro above is mine; everything below the line is his, untouched, from where it first appeared.

by Robert Carver published at This Blog is Systematic, on Monday, 8 December 2014

Running a fully automated trading strategy requires very little time. Apart from the 6 months or so of flat out coding you need to do first of course. Before doing this coding there is a chicken or the egg question to resolve. Do you write backtesting code and then some extra bits to make it trade live, or do you write live trading code which you then try and backtest?<br>Some background

If you haven’t had the pleasure of writing an automated trading strategy, perhaps because you use prebaked software like “Me Too! Trader“ or an online platform such as https://www.quantopian.com/1, you may wonder what on earth I am talking about.<br>The issue is that there are two completely different user requirements for what is usually one piece of software. The first user is a researcher. They want something highly flexible that they can use to test different, and novel, trading strategies; and to simulate their profitability by “backtesting”. Any component needs to be interactive, dynamic and easy to modify.<br>The next user - lets call them the implementor - does not rate flexibility, indeed it may be viewed as potentially dangerous. They want something that is ultra robust and can run with minimal human intervention. Every component must be unit tested to the eyeballs; modifications should be minimal and rigorously tested. Interaction is strongly discouraged and should be limited to reading diagnostic output. The code needs to be stuffed full of fail safes, “what ifs?”, and corner case catchers.<br>Ultimately you won’t benefit from a systematic trading strategy unless both users are happy. You will end up with a product which is either untested with market data and which may not be profitable (unhappy researcher), or with one which should be profitable but is so badly implemented it will either crash daily or produce fat finger class errors and buy 10e6 too many contracts (unhappy implementor).<br>Weirdly of course if, like myself, you’re trading with your own money these users are the same person!<br>Ideas have to be tested

In the vast majority of cases the backtest code comes first, for the same reason that when it comes to building a new car you don’t just weld together a bunch of panels and see what they look like; you get out your little clay model (or in this less romantic world, your CAD package). Pretty much every design discipline uses a ‘sandbox’ environment to develop ideas. Important fact: The people playing in the sandpit aren’t usually professionally trained programmers (including yours truly).<br>Either in a greenfield corporate context, or if you are developing your own stuff, the first thing you will do is write some code that turns prices or other data into positions; and then a little routine to pretend you were actually trading live in the past to see how much money you did, or didn’t make.<br>If you’re sensible then you might even have some of your core mathematical routines tidied up and unit tested so they are properly reusable. You can try and modularise the code as much as possible, so running a different trading rule just involves repointing one line of code. You could get quite fancy and have code that is flexible and is configurable by file or arguments, rather than “configuration” by script. Your simulation of backtested performance can get quite sophisticated.<br>At some point though you’re going to want to run real money on...