Your First Automated Strategy

Where my strategy ideas come from, the checks each one has to pass, and why nothing touches the live book without three months of live data.

My strategy ideation has many different forms. I try and take ideas or “hypotheses”, as I call them, from many different places. The main ones we’ll get into in this article. I’ll go through some of the key practices that I have to take a hypothesis and turn that into a strategy idea, because oftentimes there’s a lapse between the two.

I usually find that people who are struggling with building strategies are trying to force every idea or hypothesis that they have to work, which really doesn’t benefit you in your building process. You have to be able to take a hypothesis, test it fast, and see if it has legs. If it does, great, you move it on to the next step of the building process. If it doesn’t, you kill it and bin it and move on. That’s really important.

“Breakout trading doesn’t work”

I was always a mean-reversion trader when I had a discretionary approach and coming into systematic and building algorithms, I really found it difficult to reprogram my mind to not be looking to try and catch tops and bottoms of every single move and to approach different hypotheses that I’d never really looked at before (for example, breakouts). I had had this notion drilled into my mind that breakout trading doesn’t work. I can categorically say, as of doing it for the past year and a half, breakout trading is phenomenal. It makes up a large percentage of my live-book trading: breakouts on multiple assets and it’s one of the most robust algorithmic strategies that you can build.

There are so many variations of a breakout strategy. You can trade a bar breakout, an ADX breakout, a volatility breakout, a Bollinger Band breakout and so on. There are so many different approaches but effectively all you’re doing is riding momentum instead of trying to fade it.

Great. Now what system am I going to build?

I suppose a lot of the people that I’ve spoken to, upon reflection of those conversations, see the hypothesis generation as the most difficult part. They look at the screen, you explain the tools, you say, “This is how you’re going to build a system,” and they go, “Great. Now what system am I going to build?”

Generally the first strategy anybody ever tries to produce, if they have a discretionary background, is their discretionary edge (if they have one). Quite often this is a poor way to start because:

1. You’re not opening your mind to the new possibilities that you have with algorithmic execution.
2. Generally it’s very, very difficult to programme a discretionary edge. It’s very difficult. You can put in loops, you can make gates, you can code logic but the intuition that you feel as a discretionary trader with many years of experience observing the market is near impossible to put into a line of code, because remember most code is either A or B for the most part.

When you’re looking at a trade or a potential setup, it’s an A or B approach:

• A: Is every criterion met? Yes, okay, let’s take it.
• B: Is every criterion met? No, okay, we don’t take it.

When you start going, “Well all the criteria are met but I don’t like the look of this setup,” and you can’t explain why, then good luck putting that into an algorithm.

Forget everything that you know

With that in mind I think the best place to start and the best approach to have is to become a systematic trader with a completely open mind. Allow yourself to explore new ideas and allow yourself to be the student again. This is specifically talking to traders who have a discretionary background. Forget everything that you know. Keep the experience but forget everything you know because this is a completely different ball game.

One of the more interesting strategies that I put together fits this conversation impeccably. It is a strategy that I built during a conversation with a friend. I was helping him learn how to trade and he said to me (and I’ve mentioned this many times): “Have you ever noticed that if the S&P closes red on a Friday it always opens bullish on a Monday?”

The bit that stuck with me on that was his use of the word “always.” It always closes bullish on a Monday so I thought, “Okay I’ll put your words to the test,” and I spent 20 to 30 minutes putting the strategy together.

It was fairly simple:

A check of whether Friday is bearish (i.e., whether the close is lower than the open). If so we buy the cash open on a Sunday evening and we run it 1:1 risk to reward with a fixed stop.

It was a brilliant strategy and it had a phenomenal win rate, obviously because it’s trading long on the S&P 500. However there were many, many capacity constraints, which I spoke about in my previous article, the article before this one. If you want to read more about that, then the link is here. Please go ahead and read it. I think you’ll enjoy it.

My point here is that I was in a simple conversation. I wasn’t in strategy-building mode but an idea came to me, presented to me on a plate even. You get these constantly, no matter where you are. You could be scrolling through X, YouTube, Substack, Instagram, or reading a book, and you’re constantly presented with ideas or hypotheses. The person who’s saying them might not be explaining their strategy to you. They may just say something that’s interesting. Your job as a systematic PM is to go: “I’m going to test that. I’m going to build what you’ve just said and I’m going to test it.” You always have to be a shark. You have to be waiting patiently for the hypothesis to come to you. When it does you pounce.

What inefficiency am I looking to exploit?

Now let’s get into the actual building of. Before you write any code, before you put anything together, you have to be able to explain to yourself: What is my goal with this strategy? What inefficiency am I looking to exploit?

“Is it a breakout where I’m looking to break all-time highs on the Nasdaq? Am I trying to put that into a strategy? Am I trying to fade an overextension on ATR?”

You have to be able to explain the strategy. You have to be able to know when the strategy is going to operate and when it’s not going to operate, and the conditions therein.

At this point I try and keep the idea as simple as possible. I want to see as many trades in the strategy as possible before looking to apply filters or combine it with any other logic. For example what I don’t want to do is throw a strategy together that already has 100 preconditioned rules, test it, and realise there are only 5 trades a year, because you’re not going to get any quality data on 5 trades a year. You just won’t. It’s not enough volume to be able to understand whether there’s edge there, whether it’s randomness, or, even if it is randomness, how long that randomness will last. Will it last for a year, 5 years, 10 years? We don’t know because you don’t have the data.

How am I going to build this strategy?

Once we have this hypothesis written down with the end goal there and what it provides to the book, we need to go: How am I going to build this strategy?

• Am I going to use a block builder like FX Dreema if I have no coding experience?
• Am I going to use StrategyQuant to mine through various entries with different management techniques?
• Am I going to use an AI agent to put it together under my instruction?
• Am I going to spend the time writing the code?

Me personally, even if you’re a developer, I think there’s very little efficiency in sitting there and writing your whole codebase at this point in the build journey. You need to get a prototype as fast as possible because you want to do your initial checks and make sure that it’s worth your time to be investing in this strategy.

A golden nugget of information here is: never get emotionally attached to a strategy idea. Some work, some don’t. It’s not your choice which one applies to your favourite strategy. Some don’t work from an algorithmic perspective but might work from a discretionary perspective and you have to be able to build it, bin it, and move on.

The code encyclopaedia

One of the more interesting things that I’ve started doing is building a code encyclopaedia. Over my journey, I’ve used various different mechanisms to build strategies, some of which perform better than others. What I do is I take the best of each function of building and I save it in my code encyclopaedia.

For example when I built the order splitter function, I did that using Claude because it was far easier and understood the task far better than using a block builder. If I used a block builder it would have been very difficult to implement that as a mechanism in every individual strategy without having all the logic in there. I used Claude and then I saved that code in my encyclopaedia.

If I pull a strategy from any building path, I can say to my agents, “My Claude, make this strategy our own,” and it already knows all of the code to put into the strategy.

I don’t have to explain what I want or how I want it to work because Claude already knows. We have our encyclopaedia that says the way Kieran’s trading needs to be is XYZ.

Backtest or bin?

Moving on to the first backtest of the strategy, again here efficiency is key. You probably invested half an hour at this point, maybe a couple of hours depending on the complexity of the strategy, and you need to understand: Is it worth investing more time or is now the time to bin and move on?

Your first test should be run on open, high, low, close on your in-sample period (IS). Get that test done as quickly as possible. Understand: Is the curve up and to the right or is it down and to the right? Is it a curve that looks like it has promise or is it a curve that looks fabricated or it’s just a losing strategy?

If it looks like it has promise then we take a look at expanding on the strategy. Do I need to move it to a real tick test or do I need to try and optimise the system?

• Are there too many trades?
• Are there not enough trades?
• Is the curve a little bit too volatile and you’d want something more stable?
• Do we need to apply a news filter, a weekend close, an end-of-day close?

All of these different sorts of questions should now be coming into your mind now that you have a working strategy, your prototype that you’re testing on semi-poor data. It’s all about efficiency.

I personally don’t optimise strategies too much. I like to know that there’s edge in the raw state because I think that’s far more likely to survive than if I start fine-tuning and tweaking stop loss targets, moving average periods, bar periods, and all of the things that you have set in your filters.

If you start fine-tuning and tweaking every parameter so that it is the perfect backtest, then you are falling victim to overfitting: you’re building your strategy for past data that will unlikely perform the same way in the future.

I would rather give up some performance metrics (a lower or deflated Sharpe, a lower profit factor, lower kurtosis, lower Sortino, lower Calmar) and know that the strategy is far more likely to survive. That is because it makes trading far, far easier when you trust that the trades aren’t overfitted and that your performance is likely to follow in the same way that your out-of-sample and in-sample do.

Throwing as much at it as possible

The first checks that I do when I get to this point and we have a strategy that I’m happy isn’t overly overfitted and overoptimised are that I start putting it through some stress tests. How do we make sure that this strategy isn’t going to break in the live market?

We can:

• artificially increase the spread
• artificially increase the slippage
• increase commissions
• trade it on different assets
• trade it on different timeframes

I’m not saying that it has to tick all of these boxes. For example if you built a breakout strategy long only on gold, of course it’s not going to work if you try and run it on Pound Dollar. You wouldn’t expect it to work as well because the instrument bias is completely different.

The point here is we’re trying to throw as many robustness checks at the strategy as possible. You’re trying to break it down in any which way. You’re throwing as much at it as possible and seeing if it still stands. The main ones for me are the spread and the slippage because you want to know that your strategy isn’t built on such fine margins for success.

Other assets and other timeframes: again it’s a nicety if it does work and it’s nice to know that even if it doesn’t work, it still maybe has a slightly positive skew on the scale of edge, even if it’s nowhere near as good. Whereas if you build a strategy and it only works on the 15-minute but you drop to the 5-minute or the 10-minute, or you increase to the hour or the H2, and it falls apart, then there’s some cause for concern there. It’s important to know that. It’s not an absolute red flag because the edge that you’ve built may be specifically designed for a timeframe; however if it’s not then it can show some early warning signs.

Unicorn data points

The next stage is moving on to out-of-sample. Again I don’t do many optimisations. In fact I hadn’t done any optimisations at all, really, until probably about 6 months ago. I don’t like doing them. I think they can be a waste of time because you’re actually taking a step backward. However in some unique cases I think it’s worthwhile.

What you have to be looking for with an optimisation is: if I’m tweaking these parameters, am I getting a one-off unicorn data point? For example what I mean by that is: if I increase the moving average from 50 period to 122 period, which is a completely random number, but then the performance skyrockets and around that number (let’s say at 120 or 125) the performance is down, or the performance dips massively, then you have found an anomaly in the data and you shouldn’t trust it.

Anyway optimisations aside, this is where I start now testing the strategy that I’ve generated on out-of-sample data, or, better known as OOS. This is the true test because at the moment we might have only been looking at a 1-year or 2-year period. I prefer a 2-year period in-sample. I usually do 2018 and 2019 as my 2 years of data. I build the strategy there. I do any tweaks to the parameters, any optimisations if any. I do all my spread and slippage filter checks. I do everything that I need to do to go, “Okay I have a strategy that has legs to now test moving forward.”

This is the most difficult one because at this point you’re probably starting to feel an attachment to the strategy, especially if it’s performed well in-sample. You’ve sunk real hours into the system. It might have been a hypothesis that you’ve been researching for a long time and now that you’re starting to see some positive results from that, it is going to feel good. You are going to feel a type of way about it. However when you test on out of sample, it is absolutely crucial that you are as brutal as possible with yourself.

That strategy is dead

If you test your strategy that you built on out-of-sample data and it fails, that’s it: that strategy is dead. You don’t go back to the in-sample and start fine-tuning and tweaking things again because at that point you’re merging your out-of-sample and in-sample periods together. The whole point in your out-of-sample data is to go, “I have built a strategy. Now I’m going to validate it.” It’s not about improving at this stage. It’s about saying, “The improvements that you’ve already made and the build that you’ve already made, does it work moving forward on data that it hasn’t already seen?”

It’s easy to make a strategy look good when you know what’s happening in the data. If you’re losing loads of profit because you’re cutting your trades too early on your in-sample and you extend that, good. You know that that’s the case but then when you take that idea and you put it on the out-of-sample (where you’ve never tested that strategy), you don’t know whether you’re leaving money on the table. You don’t know whether your stop is the right size. You don’t know if the strategy even has legs. Does it only work on a period where interest rates are positive? Does it only work on a period where Donald Trump is in office?

There are so many variables that you now need to test in the thought of the unknown because even if you have a massively positive backtest overall of your strategy, when you then go and test it live, again you’re testing on unknown data.

This is the warm-up, okay, before going live. This is the final check where we go, “Yes this strategy has legs”. Do not skip this. Do not ignore your in-sample versus out-of-sample windows and most importantly do not test on your out-of-sample and then completely ignore the fact you’ve done an out-of-sample test, go back to your in-sample and start tweaking things again.

I feel like it’s also important at this point to say: all of these changes that you’re making, write them down. You’re more inclined to be brutal with yourself and to be a better builder if you’re writing things down and ticking off these checks as you go.

Let’s have a bit of a reality check

Now at this point you have a strategy that’s passed all the robustness checks. It’s passed its in-sample and out-of-sample periods and now you do a final check of the full curve, your in-sample plus out-of-sample. You take a look and go, “Okay this was the validated strategy across my whole testing period”. Now it might look good. It might look really good. It might induce FOMO. You might go, “I need to get this strategy live ASAP” but before you do that let’s have a bit of a reality check.

Let’s run some Monte Carlo simulations. Let’s see what happens if you reshuffle all of the trade orders. Let’s see what happens if we remove your top two highest-paying trades. Let’s see if we skip every tenth trade. Does the curve still hold up? Again in each of these tests, it’s a tiny little test that probably makes little-to-no difference but if the strategy is still standing after being peppered and peppered and peppered by all of these little robustness checks, then you kind of have a golden goose and it earns a place in your test book.

Note: I did not say live book yet. I like to run some Monte Carlo simulations, which I usually do on QuantAnalyzer because it’s the easiest way to do it, but with Claude you can run Monte Carlo simulations on anything pretty much within 10 minutes. I do a load of what-if statement testing: what if, I say, you remove the two biggest losers? What if you don’t trade on X days? What if every second trade isn’t taken? All of these sorts of things.

Again if it fails one of these tests, it doesn’t mean bin the strategy but it does highlight a weak area of the system. It might show that if you remove your two biggest trades, then the profit factor drops from 1.5 down to 1.1. That would highlight a massive weakness to me in the fact that it’s relied on two massive trades to hold up all of the metrics for the strategy.

You never, ever, ever touch the live book until you have live data

Now to my point about the live book.

You never, ever, ever touch the live book until you have live data. It is the number one cardinal sin.

You’ve built a strategy, you’ve robustness-checked it, you’ve tested it on your out-sample periods, and you’ve run Monte Carlos. Maybe you’ve done some walk-forward optimisations, which we won’t get into in this article. You might feel really happy about the work that you’ve done and the time and energy you’ve invested into this strategy at this point and then you go, “Okay I’m going to set this live because it’s a phenomenal strategy”.

You do not have the experience of that strategy operating live. You probably haven’t seen the size, you haven’t lived through its losing days, and you haven’t checked that it calculates everything properly. I say this from experience. I’ve been public about a gold strategy that I built previously on StrategyQuantX. I built a Gold system with stop losses included and then I ran it on a test book and I woke up to a massive losing trade. I was offside massively, about five times the size of my normal loss, and I had to close it manually.

I went through the Experts log on my MetaTrader and what had happened is MetaTrader had struggled to calculate my stop loss on the trade. Therefore because it couldn’t calculate it, it didn’t enter a stop. Now I put things in place, such as max loss filters: Every tick my P&L is being monitored by my strategies or by my portfolio layer and it will close a trade if it exceeds the max loss.

I built that filter from this specific lesson but the point here is that your testing or “incubation phase”, as I call it, is truly important to figure out: does the strategy replicate what you see on your backtests (i.e. you survive the overfitting reality check) and also does the code work as you intended it to? This is so important and please, everybody who’s reading this, implement this into your process. You need live data and it can’t be on a demo account.

I work for Darwinex so of course I have a vested interest in saying this but I also think Darwinex Zero is the best place to validate a strategy. I myself have an incubation account at Darwinex Zero. The reason it’s so good is because you have $100,000 in margin or $1,000,000 in margin if you’re building using futures, so you don’t have to put any capital at stake. You can run strategies low risk. You can run a portfolio low risk because you have enough margin. Like I say, you’re not losing money if the strategy fails, which some of them will.

3 months is what you need minimum

3 months is what you need minimum.

I like 3 months because it’s a quarter, depending on the frequency of the strategy, of course. Any longer than that I kind of feel like maybe you’re overkilling it.

With the final checks 3 months with a decent trade frequency is enough data for me. Any less than that and you might be moving on randomness again. A month is not enough; weeks really are not enough. 3 months is where I would go “Hell yeah I’m happy with that”.

It’s passed all the checks. The equity curve live is similar to or follows the same path as my backtests and therefore I’m happy to migrate that strategy from the incubation or the test account to the live account and then start running it over there.

If I was starting from scratch today

If I was starting from scratch today, I would be going all in on AI agents. I would be building my own code encyclopaedia, and I would be building upon that constantly because it’s the most agile, the most flexible, and the fastest way of taking a hypothesis and building a strategy from it.

If you have access to StrategyQuant X, it’s also a great place to mine entries and to be able to operate in without time being a barrier. I run StrategyQuant on my dedicated server from Hetzner and therefore it can run in the background. If I go away for a week, it can still be building strategies that I come back to and do my robustness checks on there.

I do want to finish this off by saying, however, there is no right or wrong way of strategy building. Everybody finds their own path and yes I’ve probably forgotten parts of my process and omitted them from this article. I’ve covered the most basic and the most necessary and important things that you need to do.

However find your own path, do your own checks, do your own tests. Don’t just think that because this guy whose Substack article you read said XYZ, you need to do XYZ. Do A, B, C. Find your own path. This is about you becoming the best systematic portfolio manager that you can be and so you absolutely have to adapt everything that you read into your own process in your own way.

Thank you all so much for reading. You guys are why I spend so much time putting my thoughts down on paper and I truly appreciate every single one of you.

Common questions

Where do systematic strategy ideas come from?
From everywhere except a strategy-building session. Conversations, X, YouTube, Substack, books. One of my strategies came from a friend saying the S&P always opens bullish on a Monday if it closed red on the Friday, and I spent 20 to 30 minutes testing his words. The job is to hear a claim and go and test it. Take the hypothesis, test it fast, and if it has no legs, bin it and move on.

What is the difference between in-sample and out-of-sample testing?
In-sample is the window you build in. I use two years, usually 2018 and 2019, and I do any parameter work, any optimisation and all my spread and slippage checks there. Out-of-sample is data the strategy has never seen, and its job is validation. You are not there to improve anything. If the strategy fails out-of-sample, that strategy is dead. You do not go back to the in-sample and start tweaking, because at that point you have merged the two windows and you no longer have a validation set.

What robustness checks should a strategy pass before going live?
Artificially increase the spread, artificially increase the slippage, increase commissions, then run it on different assets and different timeframes. Spread and slippage are the two that matter most, because they tell you whether the edge is built on fine margins. After the out-of-sample passes, run Monte Carlo simulations: reshuffle the trade order, remove the two biggest winners, skip every tenth trade. A strategy that still stands after all of it has earned a place in the test book.

How long should you incubate a strategy before it touches the live book?
Three months minimum, on live data, and it cannot be a demo account. A month is not enough and weeks are nowhere near enough. Three months is roughly a quarter, which with a decent trade frequency gives enough data to see whether the live equity curve follows the backtest and whether the code does what you intended. I built a gold system with stops included, woke up to a loss five times my normal size, and found MetaTrader had failed to calculate the stop and never placed it. You only find that live.

Personal commentary, not advice. Capital at risk. I work for Darwinex (FCA-regulated) and this is my own opinion.