Front matter

Who this is for (and who it isn't)

This guide is for any trader who wants to build rule-based strategies, test them properly, and learn to act and think like a professional portfolio manager. If you have been trading discretionary for a while and you are curious about what systematic looks like in practice, this is a good starting point. If you are brand new to markets but willing to learn, you will be fine here too. I define jargon as it comes up.

The point of this handbook is to help you understand how systematic trading actually works so you can build something yourself.

Some honesty upfront: systematic trading is not a passive income machine. You will still spend hours researching, testing, debugging, and maintaining strategies. The work shifts from watching charts to engineering systems. That trade-off suits some people and frustrates others. Both reactions are reasonable.

Nothing in this guide constitutes investment advice or a personal recommendation. I am sharing what I have learned so far. Your capital is your responsibility.

How to use this guide

You can read it front to back. The chapters build on each other, so that is probably the best first pass. After that, use it as a reference. Each chapter covers one concept and stands on its own well enough to revisit in isolation.

If a chapter references something from an earlier one, I will point you back to it. No need to hold everything in your head at once.

My note

I came to systematic trading from the discretionary side. I spent years trading FX by hand, learning the craft through a mix of mentors, courses (some good, some terrible), and a lot of screen time. In January 2025 I made the full switch to building rule-based strategies. I stopped discretionary trading and committed to learning the systematic approach from scratch.

I am largely self-taught on the systematic side. A friend helped point me in the right direction early on, and I have leaned heavily on LLMs (large language models, the AI tools that have become widely available over the past couple of years) to accelerate the learning curve. They are genuinely useful for understanding concepts, debugging code, and pressure-testing ideas. I use them daily.

I now run a live multi-strategy portfolio across FX, indices, and metals. It is a real book, with real capital, executing real trades. I am not writing this guide from a position of decades of systematic experience. I am writing it as someone who went through the process recently enough to remember what was confusing, what was hard, and what I wish someone had told me at the start.

That is the gap this guide tries to fill. Not theory from a textbook. Not war stories from a hedge fund. Just a practical walkthrough from someone who is obsessed with getting better and transitioning from a retail to professional portfolio manager.

What systematic trading really is

Systematic trading means you write the rules before you take the trade. All of them. Entry, exit, position size, risk limits. You define the conditions, encode them, and then follow them. The computer can do the following, or you can do it manually. The defining feature is the rules, not the automation.

That distinction matters because most people hear "systematic" and picture a black box printing money while they sleep. That is not what this is. A system is a set of instructions that removes the need for real-time judgement. It does not remove the need for thinking. It moves the thinking to a different stage: the research and design phase, where you have time and no market pressure.

Rules versus discretion

A discretionary trader looks at a chart, reads the context, and makes a call. That call draws on experience, pattern recognition, and gut feel. Done well, it works. Plenty of successful traders operate this way.

A systematic trader writes the decision into code before the market opens. When the conditions are met, the trade fires. When they are not, nothing happens. There is no interpretation in the moment.

The difference is where the skill lives. In discretionary trading, the skill is in the execution: reading the market in real time. In systematic trading, the skill is in the design: building a strategy that performs across enough market conditions to be worth running.

Neither approach is inherently better. They suit different people, different temperaments, different life circumstances. I respect the discretionary craft. I spent years doing it. But systematic fits my life better now, and this guide is about how to do it properly.

What "an edge" means

An edge is a statistical bias. A small, repeatable tendency in market data that you can exploit across a large number of trades. It does not mean you know what will happen next. It means that over hundreds or thousands of trades, your strategy captures slightly more profit than it gives back.

Think of it like a casino. The house does not know who will win at any given table on any given hand. The house knows that across thousands of hands, the maths favours it by a few percent. That few percent, compounded over volume, pays for the building.

Your edge works the same way. Any single trade can lose. A run of ten trades can lose. That is fine, provided the strategy has a genuine statistical bias that reasserts itself over a large enough sample.

Chapter 3 covers this in detail. For now, the point is: if someone tells you a system "always works" or "never loses," they are either lying or confused. An edge is a probability, expressed over volume.

What automation does (and does not solve)

Automation handles execution. It watches the market, checks the conditions, places the orders, manages the position, and logs the result. It does this without fatigue, without emotion, and without forgetting a step. That is genuinely valuable.

What automation does not do: find edges for you, adapt to regime changes on its own, or fix a bad strategy. If your rules have no edge, automating them just lets you lose money faster and more consistently.

Automation also introduces its own problems. Connectivity drops. Broker feeds glitch. VPS servers restart at inconvenient moments. Code has bugs. These are engineering problems, and they require engineering solutions. You are swapping one type of operational risk (human error in the moment) for another type (infrastructure failure and software bugs). The net is usually positive, but it is not free.

The difference between a system and a money printer

I want to kill this idea early because it poisons everything downstream.

A trading system is a tool. It encodes a hypothesis about how a market behaves, and it acts on that hypothesis consistently. When the hypothesis is correct, the system makes money. When the market shifts and the hypothesis stops holding, the system loses money or sits flat until you update it.

Good systems break. Good systems have drawdowns. Good systems go through periods where they look like they have stopped working, and sometimes they genuinely have. The job of the systematic trader is to build systems that are resilient enough to survive normal variation, and to recognise when abnormal variation means the edge is gone.

If you came here looking for a formula that prints money, this guide will disappoint you. If you came here to learn how to build, test, and manage rule-based strategies with realistic expectations, you are in the right place.

Why go systematic

The honest answer is: because it solves specific problems that discretionary trading creates, and it creates new problems in exchange. Whether the trade-off is worth it depends on you.

Here is what I gained when I made the switch. Here is what I did not.

Where the advantage lives

Consistency. A system does exactly what you told it to do, every time. It does not get tired at 3am. It does not revenge-trade after a loss. It does not skip an entry because the last three trades were losers and the setup "feels" wrong. Consistency is the thing that turns a statistical edge into actual returns. Without it, you can have the best strategy in the world and still lose money because you did not follow it.

Testability. Before risking a penny, you can run a strategy against years of historical data and see how it would have performed. You can stress-test it against specific events. You can measure its drawdowns, its win rate, its expectancy, its behaviour in trending markets and in choppy ones. Discretionary trading does not give you this. You cannot backtest judgement.

Scalability. Once a strategy is built and automated, adding a second one is incremental work. Adding a third is easier still. I run a multi-strategy portfolio. Doing that discretionary would require me to watch multiple markets simultaneously and make independent decisions in each one in real time. That is not realistic for a retail trader with a day job. Systematic makes it possible.

Emotional distance. When a system takes a loss, it is the system's loss. I designed it, so I own it, but I did not make a bad call in the moment. That separation is surprisingly useful for staying rational during drawdowns. The temptation to interfere still exists (more on that in a second), but the structure helps.

Where it does not

It is not less work. This is the misconception I want to stamp out hardest. People assume that once you automate a strategy, you are done. You are not. The strategy needs monitoring. The infrastructure needs maintaining. The edge degrades over time and needs refreshing. New strategies need researching, building, testing, and deploying. The work shifts from execution to engineering and research. The total hours do not shrink. They might even grow.

It does not eliminate bad ideas. A systematic process can take a terrible hypothesis and test it rigorously, which is great. It will tell you the idea is terrible. But it cannot generate good ideas for you. The creative part (where do edges come from? what market behaviour am I trying to capture?) is still on you. LLMs help with implementation, but the strategic thinking is yours.

It does not remove emotion entirely. You will watch your system take a string of losses and feel the urge to intervene. You will see a drawdown hit and wonder if the strategy is broken or if this is normal variance. You will be tempted to override the rules "just this once." The psychology of systematic trading is different from discretionary, but it is not easier. It is its own discipline.

The new psychology: trusting a system through a drawdown

This deserves its own section because it catches everyone off guard.

When you trade discretionary, a losing trade feels like a mistake. You re-examine the setup, figure out what you misread, and try to do better next time. There is a feedback loop between action and outcome that feels natural.

When your system takes a losing trade, you did nothing wrong. The system executed correctly. The trade just lost. That is supposed to happen some percentage of the time. Intellectually, you know this. Emotionally, it is hard to sit with.

Now extend that to a drawdown. Ten losing trades in a row. Your equity curve is dropping. Every morning you check the numbers and they are worse than yesterday. The system is doing exactly what it was built to do. The question you face is: is this normal variance, or has the edge disappeared?

That question is the central psychological challenge of systematic trading. If you turn the system off every time it draws down, you will miss the recovery. If you leave it running when the edge is genuinely gone, you will bleed capital. The only way to navigate this is to define, in advance, what constitutes normal variance for your strategy and what constitutes evidence that something has changed. Chapter 13 covers how to set those boundaries through proper testing.

So why do it?

Because, for certain people, the advantages compound. You build a strategy once, test it thoroughly, deploy it, and it runs. While it runs, you are free to research the next one. Over time, you accumulate a portfolio of strategies that diversify across markets, timeframes, and trade types. The portfolio becomes more resilient than any single strategy could be on its own.

That is the prize. It takes months of work to reach. I started systematic in January 2025, and the learning curve was steep. But the structure scales in a way that discretionary trading, for me, never did.

Whether it fits your life is a question only you can answer. The rest of this guide assumes you have decided to find out.

Edge is a statistical bias

This chapter installs the single most important mental model in the guide. Everything that follows, from strategy design to backtesting to portfolio construction, depends on it.

An edge is a small, repeatable statistical bias that you exploit across a large number of trades. That is it. No prophecy, no secret formula, no ability to see the future. Just a slight tilt in the probabilities, expressed over volume.

You are not predicting the next candle

Beginners (myself included, when I started) tend to think of trading as prediction. You look at a chart, form a view about what happens next, and bet on it. Sometimes you are right. Sometimes you are wrong. The goal, in that frame, is to be right more often.

Systematic trading reframes the whole thing. You are not trying to predict what the next candle does. You are trying to identify a pattern that, across hundreds of occurrences, resolves in your favour slightly more often than it resolves against you. Or resolves in your favour by a larger amount when it works than it costs you when it does not.

The individual trade is noise. The aggregate is signal. Once you internalise that, your relationship with winning and losing changes completely. A losing trade is not a failure. It is one data point in a distribution. The question is whether the distribution has a positive mean, and whether you have enough evidence to believe it will persist.

Expectancy over outcome

Expectancy is the number that tells you whether your strategy makes money over time. The formula is simple:

Expectancy = (win rate x average win) minus (loss rate x average loss)

If expectancy is positive, the strategy makes money in the long run. If it is negative, it loses money in the long run. The long run is the operative phrase. A strategy with a positive expectancy of £2 per trade will, over a thousand trades, generate around £2,000 in profit. But over ten trades, it might show a loss. Over fifty, it might still be underwater.

This is where people break. They build a strategy with positive expectancy, run it for three weeks, see a drawdown, and shut it off. They just killed a profitable system because the sample was too small to express the edge.

Two strategies can have identical expectancy but look completely different trade by trade. One wins 70% of the time with small gains and occasional larger losses. The other wins 30% of the time with frequent small losses and occasional large gains. Same expectancy. Very different experience of running them. The second one will test your patience. It will spend most of its time losing. But over enough trades, it pays the same.

Knowing your strategy's expectancy, and believing it, is what lets you sit through the losing periods. Without that conviction, every drawdown feels like the end.

Why this reframes everything

Once you accept that edge is statistical, several things follow naturally.

Sample size matters. Ten trades tell you almost nothing. A hundred trades start to tell you something. A thousand trades give you a distribution you can actually reason about. This is why backtesting (Chapter 13) is so central: you need enough simulated trades to estimate whether the bias is real, before you risk real capital.

Any single trade is unimportant. You stop agonising over individual entries and exits. The system either has an edge or it does not. Obsessing over one trade is like a casino owner sweating over one hand of blackjack. It misses the point.

Risk management becomes intuitive. If each trade is one sample from a distribution, you want to survive long enough to see the distribution express itself. That means keeping position sizes small enough that a run of losses does not wipe you out before the edge kicks in. Risk management stops being an afterthought and starts being the thing that keeps you in the game.

Strategy failure becomes diagnosable. If your edge is a measured statistical property, you can set thresholds. If the live results deviate from the backtested distribution by more than you would expect from normal variance, something has changed. The edge may have decayed. You have a framework for the decision, rather than guessing based on how the equity curve feels.

This mental model, edge as a statistical bias expressed over volume, is the foundation. I will reference it constantly in the chapters that follow. If it feels abstract now, that is fine. It will get concrete when we start building and testing strategies. But the principle does not change: you are playing a numbers game, and the only way to win a numbers game is to understand the numbers.

Realistic expectations

I am going to be blunt here, because nobody was blunt with me when I started, and it would have saved me a lot of time.

Systematic trading is not a shortcut. It is not passive income. It will not replace your salary in six months. If anyone tells you otherwise, they are selling something, and you should close the tab.

What returns actually look like

The strategies in XAQP target risk-adjusted returns. The goal is a portfolio that compounds steadily while keeping drawdowns within limits I can live with. That sounds boring. It is. Boring is the point.

A realistic annual return for a well-built retail systematic portfolio, before fees and slippage, sits somewhere in the range of 10% to 30%. Some years will be higher. Some will be lower. Some will be negative. If a single strategy in your book has a drawdown of 15% to 25% at some point during its life, that is normal. Expected, even. If you have never experienced a drawdown that large, you have not been trading long enough.

The numbers that get thrown around on social media (300% returns, "10x your account") come from one of three places: survivorship bias, leverage that would destroy most accounts, or outright fabrication. Ignore them. They will warp your sense of what good looks like.

How long before anything works

I started investing in crypto in 2017, moved to discretionary FX trading in 2018, and spent years learning the hard way. When I made the full switch to systematic in January 2025, XAQP went live in April 2025. Three months from zero to live. That sounds fast.

It was fast, and I would be dishonest if I did not acknowledge the role that seven years of prior experience played in compressing that timeline. I already understood position sizing, drawdown management, and the emotional discipline of sitting through losing streaks. What I had to learn was the systematic-specific layer: backtesting properly, robustness testing, building a pipeline that produces strategies without overfitting. That took focused work every day for three months.

If you are genuinely starting from scratch, think in two-year blocks. The first two years are learning. Learning the tools, learning what a real edge looks like, learning (mostly through failure) what overfitting feels like from the inside. Do not expect to be profitable in year one. Expect to still be settling into the process of building, testing, reviewing, and iterating.

That process, the loop itself, is the thing you are really building. Strategies come and go. The process that produces them is what lasts.

The effort nobody mentions

Here is the part that surprised me most. I assumed systematic trading would be primarily about strategy logic. Finding the right entry signal, the right filter, the right parameters. The intellectual puzzle of figuring out where the edge lives.

In reality, the bulk of the work is architecture, infrastructure, capacity, and execution. Building a testing pipeline that does not leak look-ahead bias. Setting up data feeds that do not have gaps. Writing code that compiles cleanly and does what you think it does. Managing a portfolio of strategies so that adding a new one does not blow up the correlation structure of the existing book. The strategy logic is maybe 20% of the job. The rest is engineering and process.

If you enjoy building systems, that is good news. If you just want to find the magic formula and press go, you will hit a wall quickly.

What makes people quit

Two things, in my experience. First: overfitting. You build a strategy that looks spectacular in backtesting. Beautiful equity curve, high Sharpe ratio, minimal drawdowns. You go live, and it immediately starts losing money. You tweak the parameters, re-optimise, go live again, and it fails again. After three or four cycles of this, you conclude that systematic trading does not work and walk away. The strategy was never real. It was memorisation dressed up as an edge.

Second: focusing on the wrong things. Spending weeks adjusting indicator parameters by one tick, searching for the perfect entry, instead of building a book designed to survive. A single strategy will always fail eventually. The question is whether you have a portfolio and a process that can absorb that failure and keep going. If your entire account depends on one strategy, you are one regime change away from being done.

What success actually is

I want to reframe this, because the way most people define success in trading is broken.

Success is not a return number. It is having a process that produces strategies with a genuine edge, a portfolio structure that manages the risk across those strategies, and the discipline to let the system run without constantly second-guessing it. It is building something that compounds, quietly, alongside the rest of your life.

Trading should complement your life, not consume it. I spent three years trading as my sole income. I will not do it again. The pressure distorts your decision-making. The model I run now is simple: a day job pays the bills, performance fees compound into a long-term portfolio, and the systematic book grows in the background. There is no rush.

If you come into this expecting to get rich quickly, you will take too much risk, overtrade, and blow up. If you come in expecting to build a skill over years, something that gets better the longer you work at it, you give yourself a real chance.

Why MT5, and getting set up

You need a platform. Something that can chart prices, run code, send orders to a broker, and backtest strategies on historical data. There are dozens of options, and the debates about which one is best are endless. I am going to sidestep all of that and tell you what I actually use: MetaTrader 5.

Why MT5

MT5 is free. It runs on Windows natively (and on Mac or Linux through workarounds, though I would not recommend that path for beginners). It connects to hundreds of brokers. It has a built-in strategy tester, a built-in code editor, and a scripting language called MQL5 that can do everything from placing market orders to running a neural network. You will not need most of that power yet. The point is that it is there when you do.

The other reason is practical: MT5 is what the majority of retail brokers support. If you pick a niche platform, you limit your broker options. If you pick MT5, almost every broker in the CFD and forex space will have a server you can connect to. That matters more than people realise, because changing platforms later means rewriting every strategy from scratch.

I use MT5 for execution. My research happens elsewhere (Claude for analysis, StrategyQuantX and Block Builders for strategy generation).

Installing MT5

Go to the MetaTrader 5 website and download the installer. Run it. The defaults are fine. You do not need to change the installation directory or tick any special boxes. The whole process takes about two minutes.

When the installer finishes, MT5 will open and ask you to log into a trading account. Close that dialogue for now. We will set up a demo account in the next step.

One thing to note: MT5 updates itself automatically. You will occasionally open it and find it installing a patch. Let it finish.

Demo first, always

Before you connect real money, you want a demo account. Every broker that supports MT5 offers one. A demo account gives you fake capital to trade with, on live market prices, with the same execution environment you would get on a real account. It is the closest thing to consequence-free practice that exists.

To set one up: open MT5, go to File > Open an Account, and pick a broker from the list (or type in a broker's server address if you have one). Choose "demo account", fill in the details, and you are in.

Pick any reasonable starting balance. I would suggest something close to what you would actually fund a live account with, because position sizing feels different on a million-dollar demo than it does on a five-thousand-dollar one. You want the numbers to feel real, even when they are not.

Brokers and symbols

MT5 is a terminal, not a broker. The data you see, the instruments available, and the spreads you pay all depend on which broker you connect to. Two people running MT5 side by side can see completely different symbol lists.

This matters for backtesting (more on that in Chapter 7). The historical data MT5 provides comes from your broker's server. Different brokers have different data depth, different naming conventions (one calls it EURUSD, another calls it EURUSD.r), and different trading hours. Keep that in mind when you start comparing results.

I am deliberately not recommending a specific broker here. Broker choice depends on your jurisdiction, your capital, and the instruments you want to trade. Do your own due diligence. What I will say is: check that the broker offers the symbols you care about, check the spreads and commissions on a demo before going live, and read the fine print on execution policy.

The parts of the UI that matter

MT5's interface is busy. There are toolbars, panels, tabs, and windows everywhere. You do not need most of them right now. Here is what to focus on.

Market Watch (Ctrl+M): this panel lists every symbol your broker offers. Right-click to add or remove symbols. This is where you drag instruments onto charts.

Chart window: the main area. You can open multiple charts, tile them, change timeframes. For now, open one chart on a major pair (EURUSD is the standard starting point) and set it to H1 (one-hour candles). Get used to scrolling through price history.

Navigator (Ctrl+N): this panel shows your account, your indicators, your Expert Advisors (the automated strategies), and your scripts. When you start running strategies, this is where you find them.

Toolbox (Ctrl+T): the bottom panel. The "Trade" tab shows open positions. The "History" tab shows closed trades. The "Journal" tab shows system messages and errors. When something goes wrong, the Journal is the first place to look.

Strategy Tester (Ctrl+R): this gets its own chapter (Chapter 6). For now, just know it exists.

What to ignore for now

Ignore the built-in indicators. Ignore the drawing tools. Ignore the MQL5 community marketplace. Ignore the signals service. Ignore the virtual hosting.

Your goal right now is simple: MT5 installed, demo account connected, one chart open, and the Navigator and Toolbox panels visible. That is your workspace. Everything else builds from here.

The Strategy Tester

The Strategy Tester is the most important window in MT5. It is where you find out whether an idea has any merit before risking a penny on it. If you learn one thing from this guide, learn how to use this tool properly. Getting the settings wrong does not throw an error. It just gives you results that look convincing and mean nothing.

Open it with Ctrl+R. You will see a row of settings across the top: the Expert Advisor to test, the symbol, the timeframe, the date range, the modelling mode, and the deposit. Every one of these matters.

Modelling modes

MT5 offers several tick-generation modes for backtesting. This is the single most important setting, and the one beginners get wrong most often.

Every tick based on real ticks: uses actual recorded tick data from the broker's server. This is the most accurate mode. Every price movement that occurred in the market is replayed, and your strategy reacts to it in sequence. If your broker provides tick data for the period you are testing, use this mode. Always.

Every tick: generates synthetic ticks by interpolating between OHLC (open, high, low, close) candle data. Better than the faster modes, but still an approximation. Price paths within each candle are fabricated. Your strategy might trigger on moves that never happened.

1 minute OHLC: one-minute candles only, no tick interpolation. Faster, but entries and exits that depend on intra-candle price action become unreliable.

Open prices only: evaluates once per candle at the open. Legitimate for strategies that only trade on candle opens and hold at least one full bar. If your strategy does anything more granular, this mode will lie to you.

The temptation is to use a faster mode because "every tick" backtests can take minutes or hours on large datasets. Resist that temptation. A fast backtest that gives you wrong results is worse than no backtest at all. You make decisions based on those numbers. They need to be as close to reality as the tool allows.

Spreads and commissions

MT5 lets you choose between "current spread" and a fixed spread for backtesting. Neither option is ideal, but you need to understand what each one does.

Current spread uses whatever the spread is right now, at the moment you hit "Start". If you run your backtest on a Sunday evening when spreads are wide, every trade in your ten-year backtest will carry that wide spread. If you run it during London session on a Tuesday, the spread will be tighter. Same strategy, different results, based on when you pressed a button. That is not useful.

Fixed spread lets you type in a value. The problem is choosing the right one. Too tight and your backtest flatters the strategy. Too wide and you kill edges that are real.

My approach: I look at the typical spread during the sessions my strategy would actually trade, add a small buffer, and use that as the fixed value. Then I run the test again with a wider spread to see how sensitive the results are. If doubling the spread kills the strategy, the edge was too thin to survive real conditions.

Commissions are separate. If your broker charges a per-lot commission (many ECN brokers do), enter it in the Expert Advisor's settings or hardcode it into the strategy. MT5 does not always pull commission data automatically. A backtest that ignores commissions overstates profit by exactly what you will pay in fees. On a high-frequency strategy, that gap turns a winner into a loser.

The settings beginners get wrong

Beyond modelling mode and spread, here are the mistakes I see most often.

Date range too short, and not split properly. Testing a strategy on two years of data tells you what it did in those specific conditions. It tells you almost nothing about what it will do next. Use the longest clean dataset you can get, and split it into in-sample (the portion you build and optimise on) and out-of-sample (the portion you hold back and never touch until the strategy is finished). If you optimise on all your data and then judge the strategy by those same results, you have tested nothing. You have just measured how well you fitted the past. Chapter 13 covers how to split your data properly.

Wrong starting balance. Your starting deposit affects position sizing, which affects drawdown, which affects whether the strategy survives or blows up. Set the deposit to match what you would actually trade with. A strategy that looks fantastic on a $100,000 account might be untradeable on a $5,000 one because the lot sizes round to zero.

Optimisation without validation. The Strategy Tester has a built-in optimiser that will sweep through parameter combinations and find the best one. The best one on historical data, that is. If you optimise and then judge the strategy by its optimised results, you have tested nothing. You have curve-fitted. Optimisation is a research tool, not a validation tool. Chapter 13 covers this in depth.

Ignoring slippage. MT5's Strategy Tester executes orders at the exact price specified, with no slippage. In live trading, you will get slippage, especially on entries and exits around news events or in thin markets. Your live results will almost always be slightly worse than your backtest. Budget for that gap.

Reading the report

After a backtest finishes, click the "Results" and "Backtest" tabs. The numbers that matter most, in order:

Net profit is obvious, but look at it relative to starting deposit. $10,000 on a $100,000 account is 10%. The same on $5,000 is 200%, but the drawdown to get there might have been terrifying.

Maximum drawdown (in currency and as a percentage): the worst peak-to-trough decline. This determines whether you can sit through the bad periods. A strategy with 60% drawdown might be profitable on paper. In practice, you will switch it off at 40% and lock in the loss.

Profit factor: gross profit divided by gross loss. Above 1.0 means it made money. Below 1.5, I start worrying whether the edge survives real-world costs.

Number of trades matters more than people think. Fifteen trades over ten years proves nothing statistically. You need hundreds for the results to mean something.

The equity curve: look at it. Smooth upward is ideal. Long flat periods mean the strategy goes dormant in certain conditions. Sudden jumps mean a handful of trades drive the profit, which is fragile.

The Strategy Tester is a powerful tool, but it rewards attention to detail and punishes sloppiness. Get these settings right, and you have a reliable sandbox for testing ideas. Get them wrong, and you will build your entire process on numbers that fall apart the moment real money is involved.

Data, the part nobody warns you about

You can have the best strategy logic in the world. If the data underneath it is wrong, your backtest is fiction. And the uncomfortable truth is that most retail traders never check. They open MT5, load a chart, hit backtest, and trust that the price history is accurate. Sometimes it is. Often it is not.

Where MT5 data comes from

MT5 pulls its historical data from your broker's server. When you scroll back on a chart or run a backtest, the terminal requests candle data from the broker and caches it locally. That is the entirety of the pipeline. There is no independent data vendor sitting behind the scenes. Your broker is the source.

This means the data you see is shaped by your broker's liquidity providers, their server uptime, and their data retention policies. Some brokers store tick data going back years. Others only keep a few months. Some have clean records through major events (the SNB unpeg in January 2015, the COVID crash in March 2020). Others have gaps, spikes, or missing candles during exactly those periods.

The problem is that you cannot tell by looking. A chart with a gap does not show a gap. MT5 simply connects the last known price to the next available one with a straight line. If your broker's server was down for two hours during a volatility spike, your chart will show a calm, smooth move. Your backtest will trade through that calm, smooth move. In reality, you would have been sitting in a trade with no price feed and no ability to exit.

The gaps that matter

Not all data gaps are equal. A missing candle at 3am on a quiet Tuesday probably will not change your results. A missing candle during a central bank announcement absolutely will.

Here are the common problems I have encountered.

Weekend gaps and rollovers. Forex trades nearly 24 hours, but the Sunday open often has a gap between Friday's close and the first available price. Some brokers fill this; others leave it blank. Your backtest either trades through the gap (unrealistic) or skips it (also unrealistic, if you would have been holding a position).

Holiday data. Thin liquidity during public holidays produces wide spreads and erratic price action. Some brokers filter this out; others include it. If your backtest trades Christmas Eve the same way it trades a regular Tuesday, the results are skewed.

Broker-specific spikes. Every so often, a broker's liquidity provider sends a bad tick: a price that is wildly off-market for a fraction of a second. Your backtest will trigger a stop loss or take profit on that spike. In live trading, the spike might not have occurred on your feed at all, or the broker would have filtered it out. One bad tick can turn a losing backtest into a winning one, or the reverse.

Symbol naming and data continuity. If you switch brokers, the symbol might be called something different (EURUSD vs EURUSD.r vs EURUSDm). More importantly, the historical data behind each name comes from a different source. A strategy that works on one broker's EURUSD data might produce different results on another's, purely because the price history differs.

Getting clean history in

MT5 does allow you to import custom data, but it is not a smooth process. You can download historical data from third-party providers (Dukascopy is a well-known one for tick data) and import it through the terminal's history centre. The format requirements are strict, and the process is fiddly enough that most people give up halfway through.

The easier route, if you are staying within MT5, is to pick a broker with deep data history and verify it manually. Scroll through major events on the chart. Check that the SNB unpeg shows a genuine spike on EURCHF. Check that March 2020 shows the volatility you would expect. If the chart looks suspiciously smooth during periods that were anything but smooth, your data is lying to you.

For more serious validation, export the data from MT5 (right-click a chart, select "Save" or use MQL5's file functions) and compare it against an independent source. This takes time. It is also the only way to know for certain what you are testing against.

Why this matters

A backtest on bad data does not just give you wrong numbers. It gives you confidence in wrong numbers. You see a positive equity curve, a good profit factor, a reasonable drawdown. You allocate capital. You go live. And then the strategy behaves nothing like the backtest predicted, because the backtest was running on a version of history that did not actually happen.

Check your data before you trust your backtest. It is tedious work, and there is no shortcut. But every hour you spend validating data saves you from building on a foundation that is not there.

Scouting for edges

Before you can build, test, or automate a strategy, you need something to test. This is the point most explanations skip. They show the backtest. They show the rules. They show the equity curve. They do not show the messy first step: where did the idea come from, and why was it worth testing in the first place?

I do not think of this as finding profitable strategies. That wording is too neat. A profitable strategy is what might exist at the end of the process. At the start, you are scouting for behaviours that might contain an edge. Most of them will not. Your job is to find candidates cheaply, reject weak ones quickly, and only spend serious time on the ideas that survive the first filters.

An edge starts as a hypothesis

A strategy idea should begin as a plain-English claim about market behaviour. For example: price tends to continue after breaking a multi-day high during high-volatility regimes. Or: certain instruments mean-revert after sharp intraday moves when the broader trend is flat. Or: spreads, session timing, and liquidity create repeatable conditions where some breakouts are worth avoiding.

The exact idea matters less than the discipline of writing it down. A hypothesis gives you something to disprove. If you cannot explain why the behaviour should exist before you code it, you are probably just hunting for a pretty backtest.

Where ideas come from

Your own trading observations. If you traded discretionary before moving systematic, your old observations are raw material. The question changes from "can I see this setup?" to "can I define this setup well enough that a machine can test it without me?"

Existing research. Academic papers, factor databases, market microstructure notes, broker research, and old trading books all contain ideas. You are not looking for something to copy blindly. You are looking for a behaviour, a reason it might persist, and a way to test whether it still survives costs.

Strategy decomposition. When you study another system, break it into the four pieces covered in the next chapter: entry, exit, sizing, and filters. Sometimes the useful idea is not the entry. It might be the exit logic, the regime filter, or the way the strategy avoids certain market conditions.

Tools and data mining. Platforms like StrategyQuant X can generate candidate structures at a scale a human cannot match. That is useful, but dangerous. Data mining can surface real patterns, and it can also produce thousands of memorised accidents. Treat mined strategies as candidates, not answers.

AI agents. I use AI to increase idea throughput. Agents can scan sources, summarise hypotheses, propose variants, and turn promising ideas into first-pass code. But the model does not know which edge is real. The model generates; the operator picks.

Failed and retired strategies. Your dead strategies are not wasted if you study them. A retired trend system might reveal that the entry was fine but the filter was too slow. A failed mean-reversion system might show that the edge only existed in one volatility regime. Those observations become new hypotheses.

The first filter

Before I build anything properly, I want a candidate idea to pass a few basic questions.

Why should this behaviour exist? There should be a structural, behavioural, liquidity, risk premium, or market-design reason behind the idea. "It looked good once" is not a reason.

Can I test it with the data I have? Some ideas need order book data, clean tick history, news timestamps, or funding-rate history. If you do not have the right data, the idea might be interesting, but it is not testable yet.

Is there enough sample size? A setup that triggered 12 times in ten years tells you almost nothing. You need enough trades to distinguish a possible edge from random noise.

Can it survive costs? If the average trade is tiny, spread and slippage can eat the whole edge. This matters early. There is no point spending a week polishing a strategy that needs impossible fills to work.

Would it add something different to the book? A strategy can be profitable and still be a bad addition if it is just another version of exposure you already carry. Portfolio fit starts at the idea stage, not after deployment.

The funnel

The process is a funnel: idea, hypothesis, simple rules, crude prototype, baseline backtest, robustness testing, portfolio fit, demo or secondary-account observation, then live deployment. Each stage exists to reduce uncertainty. Each stage should make it harder for a weak idea to survive.

This is why speed matters. Not because speed makes you smarter, but because most ideas die. If it takes you a month to test one idea, the learning loop is too slow. If you can review 20 candidates and build the best two, you get more feedback from the market and from your own mistakes.

Most ideas should die

On a productive day, my process might surface 5 to 15 raw ideas. Two or three might be worth building into a backtest. Fewer still survive robustness testing. Fewer again deserve live observation. That hit rate is not a failure. That is the work.

The mistake is expecting every idea to become a strategy. That expectation makes you protect bad ideas because you spent time on them. A better mindset is to treat every candidate as guilty until proven otherwise. The backtest has to earn your attention. The robustness tests have to earn your trust. The live behaviour has to earn its place in the book.

The edge is not one magic setup. The edge is the process that keeps scouting, testing, rejecting, and occasionally promoting strategies without lying to itself.

Anatomy of a strategy

Every systematic trading strategy, regardless of market or timeframe, has exactly four components. Entry rules. Exit rules. Position sizing. Filters. That is the full list. If you understand how these four pieces interact, you understand the skeleton of every system you will ever build.

Beginners spend almost all their time on entries. I did the same. It feels like the important part: finding the signal, spotting the pattern, calling the direction. It is the least important of the four.

Entries

An entry rule answers one question: under what conditions do I open a position? This could be a breakout above a 20-day high, a moving average crossover, a mean reversion signal when price touches a Bollinger Band (a band plotted a set number of standard deviations above and below a moving average). The specifics do not matter at this stage. What matters is that the rule is unambiguous. You should be able to hand your entry logic to a stranger and have them arrive at the same trades you would.

The reason entries get all the attention is that they feel like the "skill" part of trading. Picking the right moment. Calling the turn. In discretionary trading, that instinct is the whole game. In systematic trading, it is one cog in a machine, and rarely the most important one.

I run breakout, trend-following, and mean reversion entries across XAQP. Some of those entries are right less than 40% of the time. The strategies still make money, because the other three components do the heavy lifting.

Exits

An exit rule tells you when to close the position. This includes your stop loss (the price level where you accept the trade is wrong and cut the loss), your take profit (the level where you lock in gains), and any time-based or signal-based exit. Trailing stops, which move your stop in the direction of profit as the trade moves in your favour, are exits. So is "close if the trade has not moved after ten bars."

Exits determine how much you make on winners and how much you lose on losers. That ratio, reward to risk, shapes the entire character of a strategy. A system with a 35% win rate and a 3:1 reward-to-risk ratio will outperform a system with a 60% win rate and a 0.8:1 ratio. The maths is straightforward once you lay it out.

Most beginners set a stop loss because someone told them to, then spend zero time thinking about whether that stop distance actually fits the strategy's behaviour. A trend follower with a tight stop will get shaken out of every trade before the trend develops. A mean reversion system with a wide stop will hold losers far longer than the edge justifies. The exit has to match the entry's logic, or the two work against each other.

Position sizing

Position sizing answers: how much capital do I allocate to this trade? This is the component that controls whether a losing streak dents your account or destroys it.

The simplest approach is fixed fractional sizing: risk a fixed percentage of your account on each trade. If you risk 1% per trade and you have ten consecutive losers, you have lost roughly 9.6% of your account (each loss is 1% of a shrinking balance). If you risk 5% per trade, those same ten losers cost you around 40%. Same strategy, same entries, same exits. The only difference is position sizing, and it is the difference between an uncomfortable month and a blown account.

A more advanced approach is volatility-adjusted sizing. Instead of risking a flat percentage, you size each position based on the instrument's recent average true range (ATR, a measure of how much an instrument moves in a typical period). When volatility rises, position sizes shrink automatically. When volatility falls, they expand. This keeps the dollar risk per trade roughly constant even as market conditions shift.

Position sizing is also where you enforce portfolio-level risk limits. A single strategy might risk 1% per trade, but if you have five strategies all entering positions at the same time in correlated instruments, your real exposure is much higher than any individual strategy suggests. Sizing is where you catch that.

Filters

A filter is a condition that must be true before the strategy is allowed to take a trade. The entry signal fires, but the filter says "not now."

Common filters include trend filters (only take long entries when price is above the 200-day moving average), volatility filters (do not trade when implied volatility is below a threshold), time filters (avoid trading during the Asian session if your strategy is designed for London hours), and regime filters (reduce exposure when correlations across your universe spike).

Filters exist to keep a strategy out of environments where its edge does not apply. A breakout strategy that works well in trending markets will chop you to pieces in a range-bound environment. A trend filter will not make the strategy profitable in ranges, but it will stop it from bleeding during them.

The danger with filters is overfitting. Every filter you add improves your backtest, because you are removing losing trades with the benefit of hindsight. The question is always: does this filter represent a real structural reason the strategy should not trade, or am I just curve-fitting my way to a prettier equity curve? If you cannot explain why the filter should work going forward, it probably will not.

How the four interact

These four components are not independent. Change one and you change the character of the entire system.

Widen your stop (exit) and your win rate goes up, but your reward-to-risk ratio drops. Add a trend filter and your trade count falls, which changes the statistical reliability of your backtest. Increase your position size and a strategy that looked smooth on paper starts producing drawdowns that test your ability to stick with it.

This is why building a strategy is not a matter of finding a good entry and bolting on a stop loss. It is a design problem. The four components have to work together as a coherent system. A trend-following entry needs a trailing exit that lets winners run, sizing that can absorb a low win rate, and filters that keep it out of choppy regimes. Swap in a tight profit target and you have broken the system, even though you only changed one component.

When I review a strategy, I start with the interaction between these four pieces before I look at any performance metrics. If the components do not fit together logically, the backtest results are noise.

Build the habit early: when you look at any strategy, identify the entry, exit, sizing, and filter. If you cannot find one of the four, it is either missing (a problem) or hidden inside another component (also a problem, because it makes the system harder to analyse and debug). Four pieces. Every system. No exceptions.

Choosing your path

There are several ways to build a systematic trading strategy. Each has trade-offs. None of them eliminates the hard part, which is knowing whether the thing you have built has a real edge. The tools just change how you get to that question.

I use a hybrid of most of these approaches, so this is not a theoretical overview. I will tell you what I actually use, where each tool fits in my workflow, and where each one falls short.

Writing code by hand

The traditional route. You learn MQL5 (MetaTrader's programming language), Python, or both, and you write your strategies from scratch. Line by line, function by function.

The advantage is total control. You know exactly what every line does, because you wrote it. When something breaks, you can find the bug. When you want to add a feature, nothing is stopping you. There is no abstraction layer between you and the logic.

The disadvantage is speed. Writing, debugging, and iterating on hand-coded strategies is slow. If you are also learning the language as you go, it is glacial. A strategy that takes an afternoon to prototype in a visual builder might take you a week to hand-code, test, and get compiling cleanly.

This route suits people who already know how to code, or who want to learn programming as part of the process. If you enjoy the engineering side, it is deeply satisfying. If you just want to test ideas quickly, it is a bottleneck.

Visual block builders

Tools like FxDreema (Block Builders) let you construct strategies by dragging and dropping logic blocks instead of writing code. You connect entry conditions to exit conditions, add filters, set position sizing rules, and the platform generates the MQL5 code for you.

I use FxDreema for quick hypothesis testing. When I have an idea for a strategy structure and I want to see whether the basic logic holds up before investing time in a full build, a block builder lets me prototype it in an hour or two.

The barrier to entry is low, which is both the strength and the risk. You can build something that compiles and runs a backtest within your first session. That speed is useful if you know what you are looking for. It is dangerous if you do not. The platform cannot tell you why an edge should exist. It cannot tell you whether your backtest is overfitted. It cannot tell you whether the logic you have assembled makes structural sense for the market you are trading. It just builds what you tell it to build.

Block builders lower the code barrier, but they drop you at the real wall: designing an edge. Learn the design questions (Chapters 9 and 13 through 17 cover these in detail) before you spend time in the platform. Otherwise you will produce a lot of strategies that look good in backtesting and fall apart live.

StrategyQuant X

StrategyQuant X (SQX) is a data-mining platform. It generates thousands of strategy candidates algorithmically, runs them through robustness tests, and surfaces the ones that pass. The idea is brute-force search across the strategy space, filtered by statistical checks.

I own SQX and use it, though I will be honest: I have not used it to its full advantage. Other traders I know have gone all in on SQX-based workflows and built entire portfolios from its output. My use has been more occasional, primarily as a source of candidate strategies that I then rebuild and validate through my own pipeline.

The upside is scale. SQX can explore a volume of strategy combinations that no human could test manually. The robustness testing built into the platform (Monte Carlo simulation, walk-forward analysis, out-of-sample validation) is solid.

The downside is that you still need a trader who understands what a real edge looks like to operate the tool. SQX will produce strategies that pass its statistical filters. Whether those strategies have a structural reason to work in the future is a question the software cannot answer. You have to bring that judgement yourself. Data mining without a hypothesis is a fast path to overfitting at scale.

The cost is meaningful (several hundred dollars for the licence plus data feeds), and the learning curve is steep. If you are going to use it, commit to learning it properly. Half-measures produce noise.

AI-assisted building

This is where I spend most of my time now. I use Claude and Codex as code-generation and research tools, integrated into a workflow that produces strategy candidates daily.

The setup works like this. I run Claude Cowork scheduled tasks that scour web sources for trading strategy ideas each day. Those tasks synthesise what they find, apply my code libraries and strategy structure templates, and drop compiled files into my strategy funnel. From there, I review the candidates, test them through my full pipeline, and either discard or promote them. Claude Code and Codex handle the final code production, pulling together my existing codebase to build the strategies out properly.

AI is strong at certain things: generating a high volume of candidates quickly, writing first-pass code that compiles and runs (it gets to 80% to 90% on the first attempt in my experience), red-teaming risk rules, surfacing factor exposures you might have missed. On a good afternoon, I can generate 5 to 15 ideas, of which 2 or 3 are worth backtesting. That throughput was not possible before these tools existed.

AI is weak at other things. It does not follow my strategy structure correctly unless I build explicit skills and processes for the agents to follow every time they work. Left to its own defaults, it will produce code that compiles but does not match my architecture. Portfolio construction is another gap. The model cannot see my live book or the real-time correlation between strategies. It generates candidates in isolation. The operator picks, and the operator (you) is still responsible for everything that matters.

Which should you choose?

If you are starting today, my honest recommendation is to go all in on AI agents. The speed advantage is too large to ignore. You can set up scheduled tasks that generate and test hypotheses while you sleep. You can iterate on strategy ideas in a fraction of the time it would take to hand-code them.

But "go all in on AI" does not mean "let AI do everything." Every route on this list, hand-coding, block builders, SQX, AI, has the same limitation: it still needs a trader who knows what they are doing sitting behind it. The tool changes the speed. It does not change the requirement for judgement.

If you do not yet know what a real edge looks like, what overfitting feels like, or how to read a backtest critically, no tool will protect you from yourself. Learn those things first (the next several chapters are designed to teach exactly that), and then pick the tools that match the way you want to work.

I use all four in some combination. FxDreema for quick prototyping. SQX for occasional data-mined candidates. Claude and Codex for daily production. And I still read MQL5 code line by line when something needs debugging. The tools are not mutually exclusive. Use whatever gets you to a tested, validated strategy fastest, and do not let the tool choice distract you from the actual work.

Using AI agents

Chapter 10 covered the tools at a high level. This chapter goes deeper on the one I use most: AI agents. Specifically, how I use LLMs and agentic coding tools to build expert advisors (EAs, the automated strategies that run on MetaTrader 5) without shipping nonsense.

I want to be direct about something first. AI has never handed me a finished edge. The hard part of systematic trading was never writing the code. It was always knowing what to build, knowing how to test it, and knowing when to throw it away. AI accelerates the mechanical work. It does not replace the judgement.

If you take one thing from this chapter: the model generates; the operator picks.

My actual workflow

The pipeline has two stages.

Stage one: candidate generation. I use Claude Cowork scheduled tasks to generate strategy hypotheses daily. These tasks run on a schedule, scraping web sources (forums, research papers, trading blogs, factor databases) for strategy ideas. Each task applies my filters: does the idea have a structural rationale? Is it testable with the data I have? Does it target a market and timeframe I actually trade? The output is a set of candidate hypotheses, ranked and annotated, dropped into a queue for review.

On a productive day, this generates 5 to 15 raw ideas. Of those, 2 or 3 are worth building out to a backtest. The rest get discarded. That hit rate is normal. The value is in the throughput: I am reviewing more ideas per week than I could generate manually in a month.

Stage two: build and test. I use Claude Code and Codex to build the actual strategies. They pull from my database of existing code, libraries, helper functions, and strategy architecture templates to assemble compiled EA files. The first-pass code compiles and runs correctly 80% to 90% of the time. The remaining 10% to 20% usually involves edge cases in order management or indicator calculation that need manual correction.

From there, the strategy enters my standard testing pipeline (covered in Chapters 13 through 17). AI does not get a shortcut through testing. Every strategy, regardless of how it was built, runs through the same battery of in-sample/out-of-sample splits, robustness checks, and stress tests before it goes anywhere near live capital.

Where AI actually helps

Candidate volume. The compounding speed of the process itself is the edge. More ideas tested per unit of time means more chances to find something real. AI makes the generation step almost free.

Code generation. Building backtest infrastructure, writing boilerplate EA code, implementing standard entry/exit patterns. AI handles these reliably. It is a strong first-pass coder for well-defined tasks.

Red-teaming. I feed my strategies back to the model and ask it to find weaknesses. Overconcentration in a single factor. Entry logic that is functionally equivalent to another strategy already in the book. Risk rules with gaps. It catches things I miss, especially when I have been staring at the same code for hours.

Surfacing factor exposures. Ask the model what macro factors a strategy is implicitly betting on, and it will often identify exposures you did not intend. A breakout strategy on GBPUSD during London open might have a hidden correlation to UK gilt yields that you did not design for. Knowing about it does not make the strategy bad, but not knowing about it means you cannot manage the risk.

Where AI fabricates

The model does not know what is in my live book. It cannot see the real-time correlation between my running strategies. When it suggests a new candidate, it has no idea whether that candidate doubles up on an exposure I am already carrying. Portfolio construction remains a manual, human-operated process.

AI also has a consistency problem. Left to its defaults, it will write code that compiles but does not follow my strategy architecture. The function names are different. The order management logic uses a different pattern. The risk checks are in the wrong place. It works in isolation, but it does not fit into the portfolio's codebase.

The fix is explicit structure. I build skills and processes, essentially detailed instruction sets, for the agents to follow every time they work. These skills define the exact file structure, naming conventions, order management pattern, risk check sequence, and logging format that every strategy must use. With the skills in place, the output is consistent. Without them, every strategy is a one-off.

This is a broader point about AI tools: they are as good as the constraints you give them. Unconstrained, they produce plausible-looking output that falls apart under scrutiny. Properly constrained, they produce reliable output at speed.

The trust rule

Here is how I decide whether a piece of AI-generated code is ready to trade.

First, I have multiple agents review the code independently. One agent builds it; a different agent reviews it against my strategy specifications. Disagreements between agents surface bugs and structural issues faster than a single review pass.

Second, I do a manual review. This is non-negotiable. If I cannot explain what every function does, the strategy does not go live.

Third, I test the strategy on a secondary portfolio before it touches my live book. This is a separate account, running the same broker and data feed. The strategy runs there for long enough to confirm that live execution matches backtest expectations. Only after that observation period does it get promoted to the main book.

Three layers: agent review, manual review, live observation on a secondary account. Skip any one of them and you are gambling on code you do not fully understand.

What beginners should not do

Do not assume AI will do everything for you. It will not. It is a serious part of research and pressure-testing risk, and it has materially increased the speed at which I can develop and test strategies. But every step that requires judgement, deciding whether an edge is real, sizing it correctly, managing correlation across a portfolio, knowing when to kill a strategy, is still yours.

The market for "AI trading" products right now is full of course merchants wrapping AI around the oldest scam in retail trading: selling the dream that the hard part can be automated away. The hard part cannot be automated away. The hard part is you. Your understanding of risk, your ability to sit through drawdowns, your discipline in following a process when the results are ugly.

AI is a tool. A very good tool, used properly. Treat it the way you would treat any other part of your infrastructure: with clear specifications, rigorous testing, and the assumption that it will occasionally get things wrong. Build the guardrails before you build the strategies.

A worked example

This chapter takes an idea from plain English to written rules to an annotated Expert Adviser (EA) in MQL5. The point is the process, not the strategy. The strategy itself is deliberately simple, deliberately incomplete, and deliberately not something you should run on a live account. It is a teaching vehicle. Treat it as one.

The idea

Start with a sentence anyone could understand: "Buy when price breaks above a recent high; sell short when price breaks below a recent low."

That is a breakout strategy. The premise is that when price pushes through a level it has not reached in N bars, the move has momentum behind it and may continue. Breakout strategies have been studied since the 1980s. The Turtle Traders used a variant. The underlying logic is simple: a new high or new low represents a shift in the supply-demand balance, and that shift sometimes persists long enough to profit from.

Whether this particular implementation has a tradeable edge is beside the point. We are here to learn how to turn words into rules and rules into code.

Turning the idea into explicit rules

Before you write a single line of code, write your rules in plain language. Every rule must be unambiguous. If a stranger could read your rules and arrive at the same trades, you have done the job.

Entry (long): if the current bar's high exceeds the highest high of the previous N bars, and we have no open position, buy at market.

Entry (short): if the current bar's low falls below the lowest low of the previous N bars, and we have no open position, sell at market.

Exit: a fixed stop loss of S pips from the entry price, on the losing side. No take profit for now. We close the position only when the stop is hit or an opposing signal fires (which closes the current trade and opens a new one in the opposite direction).

Position sizing: risk a fixed percentage of the account equity per trade. Calculate the lot size so that if the stop loss is hit, the loss equals that percentage.

Filters: none. This is the bare skeleton. Chapter 9 covered why you would add filters; for this exercise, we leave them out so the code stays readable.

Notice what is missing. There is no trailing stop, no take-profit target, no volatility adjustment, no trend filter, no time-of-day restriction, no correlation check against other positions. This strategy is incomplete by design. It is a frame, not a finished product.

The annotated EA

Below is the full EA in MQL5. I have commented every meaningful block so you can follow what each section does and why it is there. This code will compile in MetaEditor and run in the MT5 Strategy Tester, but it is a learning exercise. Do not run it on a live account.

This code is for educational purposes only. Test it on a demo account. It is not a recommendation, not a strategy you should trade, and not investment advice.

//+------------------------------------------------------------------+
//| BreakoutExample.mq5                                              |
//| Educational EA — N-bar high/low breakout                         |
//| NOT for live trading. Learning exercise only.                    |
//+------------------------------------------------------------------+
#property strict

// --- Inputs: these are the parameters you can change in the tester ---
input int    LookbackBars   = 20;      // How many bars back to measure the high/low
input double RiskPercent    = 1.0;     // Percentage of equity to risk per trade
input double StopLossPips   = 50.0;    // Stop loss distance in pips
input int    MagicNumber    = 12345;   // Unique ID so the EA only manages its own trades

// --- Global trade request and result objects ---
MqlTradeRequest request;
MqlTradeResult  result;

//+------------------------------------------------------------------+
//| OnInit: runs once when the EA is loaded onto a chart             |
//+------------------------------------------------------------------+
int OnInit()
  {
   // Clear the trade request struct so we start clean
   ZeroMemory(request);
   ZeroMemory(result);

   // Set fields that stay constant across every order
   request.action    = TRADE_ACTION_DEAL;   // We want an instant execution order
   request.symbol    = _Symbol;             // Trade the symbol the EA is attached to
   request.magic     = MagicNumber;         // Tag orders so we can identify ours
   request.deviation = 10;                  // Max slippage in points

   return(INIT_SUCCEEDED);
  }

//+------------------------------------------------------------------+
//| OnTick: runs on every new price tick                             |
//+------------------------------------------------------------------+
void OnTick()
  {
   // --- Only act on a new bar, not every tick ---
   // This prevents multiple signals on the same bar.
   static datetime lastBarTime = 0;
   datetime currentBarTime = iTime(_Symbol, PERIOD_CURRENT, 0);
   if(currentBarTime == lastBarTime)
      return;
   lastBarTime = currentBarTime;

   // --- Calculate the breakout levels ---
   // iHighest / iLowest return the bar index of the highest high
   // or lowest low over the lookback window. We read from bar 1
   // (the last completed bar) to avoid using the current bar,
   // which is still forming.
   int highestBar = iHighest(_Symbol, PERIOD_CURRENT, MODE_HIGH, LookbackBars, 1);
   int lowestBar  = iLowest(_Symbol, PERIOD_CURRENT, MODE_LOW, LookbackBars, 1);

   double breakoutHigh = iHigh(_Symbol, PERIOD_CURRENT, highestBar);
   double breakoutLow  = iLow(_Symbol, PERIOD_CURRENT, lowestBar);

   // Current ask and bid prices
   double ask = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   double bid = SymbolInfoDouble(_Symbol, SYMBOL_BID);

   // --- Check if we already have a position ---
   bool hasPosition = false;
   long positionType = -1;

   if(PositionSelect(_Symbol))
     {
      // Only count positions opened by this EA
      if(PositionGetInteger(POSITION_MAGIC) == MagicNumber)
        {
         hasPosition  = true;
         positionType = PositionGetInteger(POSITION_TYPE);
        }
     }

   // --- Entry logic ---
   // Long breakout: ask exceeds the highest high of the lookback period
   if(ask > breakoutHigh)
     {
      if(hasPosition && positionType == POSITION_TYPE_SELL)
         ClosePosition();   // Close the short before opening a long

      if(!hasPosition || positionType == POSITION_TYPE_SELL)
         OpenTrade(ORDER_TYPE_BUY, ask, StopLossPips);
     }
   // Short breakout: bid falls below the lowest low of the lookback period
   else if(bid < breakoutLow)
     {
      if(hasPosition && positionType == POSITION_TYPE_BUY)
         ClosePosition();   // Close the long before opening a short

      if(!hasPosition || positionType == POSITION_TYPE_BUY)
         OpenTrade(ORDER_TYPE_SELL, bid, StopLossPips);
     }
  }

//+------------------------------------------------------------------+
//| OpenTrade: calculate lot size and send the order                 |
//+------------------------------------------------------------------+
void OpenTrade(ENUM_ORDER_TYPE orderType, double price, double slPips)
  {
   // --- Position sizing ---
   // Work out how many lots to trade so that a stop loss hit
   // costs exactly RiskPercent of current equity.
   double equity    = AccountInfoDouble(ACCOUNT_EQUITY);
   double riskMoney = equity * RiskPercent / 100.0;

   // Convert stop loss from pips to the instrument's price units
   double point     = SymbolInfoDouble(_Symbol, SYMBOL_POINT);
   int    digits    = (int)SymbolInfoInteger(_Symbol, SYMBOL_DIGITS);
   double pipValue  = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_VALUE);
   double pipSize   = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_SIZE);

   // Avoid division by zero
   if(pipValue == 0 || pipSize == 0)
      return;

   // Dollar value of one pip move for one lot
   double onePipPerLot = pipValue / pipSize * point;
   if(onePipPerLot == 0)
      return;

   // Lots = money we can risk / (stop distance in pips * dollar value per pip per lot)
   double lots = riskMoney / (slPips * onePipPerLot);

   // Clamp to the broker's allowed range and step
   double minLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double maxLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double lotStep = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);

   lots = MathFloor(lots / lotStep) * lotStep;
   if(lots < minLot) lots = minLot;
   if(lots > maxLot) lots = maxLot;

   // --- Set the stop loss price ---
   double slPrice = 0;
   if(orderType == ORDER_TYPE_BUY)
      slPrice = price - slPips * point * (digits == 3 || digits == 5 ? 10 : 1);
   else
      slPrice = price + slPips * point * (digits == 3 || digits == 5 ? 10 : 1);

   slPrice = NormalizeDouble(slPrice, digits);

   // --- Send the order ---
   request.type   = orderType;
   request.volume = lots;
   request.price  = price;
   request.sl     = slPrice;
   request.tp     = 0;       // No take profit in this version
   request.comment = "Breakout Example";

   if(!OrderSend(request, result))
      Print("OrderSend failed: ", GetLastError());
  }

//+------------------------------------------------------------------+
//| ClosePosition: close the current position for this EA            |
//+------------------------------------------------------------------+
void ClosePosition()
  {
   if(!PositionSelect(_Symbol))
      return;

   if(PositionGetInteger(POSITION_MAGIC) != MagicNumber)
      return;

   long   type   = PositionGetInteger(POSITION_TYPE);
   double volume = PositionGetDouble(POSITION_VOLUME);

   // To close, we send an opposite order for the same volume
   request.type   = (type == POSITION_TYPE_BUY) ? ORDER_TYPE_SELL : ORDER_TYPE_BUY;
   request.volume = volume;
   request.price  = (type == POSITION_TYPE_BUY)
                     ? SymbolInfoDouble(_Symbol, SYMBOL_BID)
                     : SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   request.sl     = 0;
   request.tp     = 0;
   request.comment = "Close Breakout";

   if(!OrderSend(request, result))
      Print("ClosePosition failed: ", GetLastError());
  }
//+------------------------------------------------------------------+

What this code does, and what it does not do

Walk through the structure. The input block at the top defines the four parameters you would vary in the Strategy Tester: lookback period, risk percentage, stop loss distance, and a magic number to tag the EA's trades. OnInit runs once and sets up the trade request object. OnTick fires on every price update but only acts on a new bar (the lastBarTime check). The entry logic compares the current price against the N-bar high and low. OpenTrade handles position sizing and order submission. ClosePosition flattens an existing trade by sending an opposite order.

That is the skeleton from Chapter 9: entries, exits, position sizing. Filters are absent because we left them out on purpose.

What the code does not do is at least as important. There is no trailing stop, so winning trades give back all their open profit before the stop or a reversal signal closes them. There is no spread or commission modelling in the sizing calculation. There is no check for whether the market is open. There is no portfolio-level risk cap. There is no logging beyond the default error prints.

This EA needs work before it is anything. That is the point. A strategy is a design problem, and this is a first sketch on a napkin. If you run this in the Strategy Tester you will get results, but those results will tell you more about the shortcomings of the code than about breakout trading.

The exercise is this: take a simple idea, force yourself to write every rule in words before touching code, then translate those words into MQL5 and see the gap between what you thought you specified and what actually happens when the machine executes it. That gap is where the learning lives.

In the next chapters, we will take a strategy through backtesting, overfitting checks, and robustness testing. You will need all of those tools before anything you build goes near real capital.

Backtesting properly

A backtest is a hypothesis. It tells you what would have happened if you had run a strategy on data you already know the outcome of. That is useful, but it is not evidence that the strategy will work going forward. The distance between those two things is what most traders get wrong (disctionary and systematic).

I run every strategy through a full testing battery before it goes anywhere near live capital. A single backtest is close to worthless on its own. Here are the traps that make it so.

In-sample versus out-of-sample

When you build a strategy, you tune it on a chunk of historical data. That chunk is your in-sample period. You adjust parameters, filters, entry rules, exit rules, position sizing, all of it, until the equity curve looks good on that data. The problem is obvious once you say it out loud: you already know what happened. You are fitting your rules to a known outcome.

The fix is to split your data. Hold back a portion the strategy has never seen. That held-back portion is your out-of-sample period. You build on the in-sample data, freeze the parameters, then run the frozen strategy on the out-of-sample data and see what happens.

If the strategy works on data it was never tuned on, you have something worth investigating further. If it falls apart the moment it hits unseen data, you have learned something valuable: the "edge" was a mirror, reflecting the past back at you.

I have seen this mistake more times than I can count. You optimise across the full dataset, see a beautiful equity curve, and assume the strategy works. It does work, on data it was already designed to fit. That is memorisation.

The look-ahead trap

Look-ahead bias is subtler. It happens when your backtest uses information that would not have been available at the time of the trade.

The classic example: you use a closing price to make a decision that, in live trading, you would need to make before the close. Your backtest assumes you knew the close before it happened. Another common one: filtering trades using an indicator calculated on the full dataset, including future data points that had not occurred yet when the trade was taken.

Look-ahead bias is dangerous because it does not look like cheating. The backtest runs, the results come out, everything appears legitimate. But the strategy is using information from the future to make decisions in the past. When you go live, that information vanishes, and so does the edge.

The discipline is simple: at every bar in your backtest, ask yourself what you would actually know at that point. If the answer includes anything that had not happened yet, you have a look-ahead problem.

Survivorship bias

Survivorship bias is the one that hides in the data itself, before you write a single line of code.

If you backtest a strategy on today's index constituents, you are testing on the winners. The companies that went bust, got delisted, or were removed from the index are not in your dataset. Your strategy never had to trade them, so it never took the losses they would have caused.

The discipline of holding data back

All three of these traps share a root cause: the temptation to use everything you have. All the data, all the information, all the instruments. It feels wasteful to hold things back. It feels like you are leaving edge on the table.

You are not. You are buying insurance against self-deception.

Here is how I approach it. I split my data into three segments: a training set for building, a validation set for checking, and a final holdout set I do not touch until the strategy has passed every other test. That holdout set is the closest thing I have to a forward test without going live.

I also replay every strategy against specific historical stress events before deployment: the Swiss franc unpeg in January 2015, the PBOC devaluation in August 2015, the COVID volatility spike in March 2020, the US election overnight in November 2016. These are not optimisation targets. They are survival checks. A strategy that cannot explain what it would have done during those events has not been tested. It has been backtested. There is a difference.

The strategies that fail any of these checks do not go live. The testing is the cheapest part of the process. The expensive part is finding out your backtest was wrong with real money on the line.

The overfitting trap

For years the most common excuse for not trying systematic trading was: "I can't code." Block builders changed that. Platforms like StrategyQuantX let you drag blocks together, define rules visually, and generate strategies without writing a line of code. More recently, agentic coding tools (Claude, Cursor, and the rest) have lowered the barrier even further. You can describe a strategy idea in plain English and watch working code appear.

That is genuinely good. Removing the code barrier opens the door for more people. The problem is what waits on the other side of that door.

The wall behind the wall

Coding was never the real obstacle. It felt like one because it was the first thing you hit. Once you get past it, you land on the actual hard part: designing an edge that survives contact with a live market.

Block builders and AI tools make it trivially easy to generate candidate strategies. I have sat down with StrategyQuantX and produced fifty strategies in a session. Lovely equity curves, all of them. Smooth lines going up and to the right. It feels like progress. You are clicking, building, watching results roll in. The dopamine is real.

A curve is not an edge.

The platform can produce the curve. It cannot tell you why the edge should exist, which regime it was built for, or how it should behave when that regime flips. Those are design questions, and they sit upstream of anything you build in a block builder.

The "just one more parameter" trap

Overfitting does not announce itself. It creeps in through reasonable-sounding decisions.

Your strategy has a moving average crossover. The equity curve is decent, but there is a drawdown in 2018 you do not like. So you add a volatility filter: only take trades when the ATR (average true range, a measure of how much price moves per bar) is above a threshold. The drawdown shrinks. Now the curve is smoother.

Then you notice a cluster of losing trades on Mondays. So you add a day-of-week filter. Remove Mondays. Better again.

Then you spot a run of losses during Asian session hours. Add a time filter. The curve is beautiful now.

Each decision felt sensible in isolation. You were "improving" the strategy. What you were actually doing was carving the rules until they fit the historical data like a key in a lock. The strategy did not get better at trading. It got better at describing what already happened.

I have done this myself. Spent a full afternoon "refining" a mean-reversion strategy until the backtest looked perfect. Sortino above 3. Max drawdown under 4%. Then I ran it on out-of-sample data and the equity curve fell off a cliff inside three weeks. The strategy had memorised the training data. It had no idea what to do with anything it had not seen before.

A perfect equity curve is a warning

This is counterintuitive, but learn it early: when a backtest looks too good, something is wrong. Markets are noisy. A real edge operating in a real market will have messy patches, losing streaks, drawdowns that make you uncomfortable. That is normal.

A strategy that navigates every historical dip with surgical precision has almost certainly been tuned to do exactly that. It found the noise and fitted it. In-sample, it looks like genius. Out-of-sample, it looks like every other blown-up retail account.

Here is a rough heuristic I use. If a strategy has more than five or six free parameters (values you optimised during development), I treat it with deep suspicion. Every parameter you add gives the optimiser another degree of freedom to curve-fit. Two parameters, you might have a real signal. Ten parameters, you almost certainly have a mirror reflecting the past.

How to stop fooling yourself

The defence is boring. It is process.

First: ask the design question before you touch the platform. What is your edge, in one sentence, and why should it exist? If you cannot answer that clearly, you are not ready to build. "Momentum tends to persist in trending FX pairs during New York session" is an answer. "I ran the optimiser and it found something" is not.

Second: hold data back. Chapter 13 covered in-sample versus out-of-sample splits. Use them. Every time. No exceptions.

Third: count your parameters. If you need seven filters to make the equity curve work, the equity curve is not working. Strip it back to two or three rules and see if anything real remains. Usually, the stripped version either works on its own or does not work at all. Both answers are useful.

Fourth: run robustness tests (Chapter 15 goes deep on this). A real edge does not evaporate when you shift a parameter by 10%. A fitted curve does.

Learn the design questions before you learn the platform. The platform is the easy part. The thinking is the hard part. And the thinking is where the edge actually lives.

Robustness testing

A backtest tells you what happened. Robustness testing tells you whether it matters. This is the battery I run on every strategy before it gets anywhere near live capital. If a strategy cannot pass these checks, it does not trade. Full stop.

Walk-forward analysis

Walk-forward is the closest thing you get to simulating real deployment on historical data.

Here is how it works. You split your data into segments. You optimise your strategy on the first segment (the training window), freeze the parameters, then test on the next segment (the out-of-sample window). Then you slide the whole thing forward: the training window moves up, the out-of-sample window moves up, and you repeat.

The result is a series of out-of-sample equity curves, stitched together. None of them were optimised on the data they traded. This is the equity curve you should be looking at, not the in-sample one.

What to look for: consistent performance across the out-of-sample windows. If your strategy works brilliantly in the first three windows and falls apart in the last two, you probably have a regime-dependent edge that stopped working. That is useful information. Better to find it here than with real money.

What to worry about: if the walk-forward equity curve looks nothing like the full in-sample backtest, the strategy was overfitted. The in-sample results were a mirage. Kill it and move on.

I typically use a 3:1 ratio for training to testing windows. So if I am training on three years of data, I test on the following year. Then slide forward. The exact ratio matters less than being consistent about it.

Out-of-sample testing

This overlaps with walk-forward but is worth covering on its own because it is simpler and you should be doing it from day one.

Hold back your OOS data. Build your strategy on the earlier portion. Do not touch the holdout until you are finished building. Then run the frozen strategy on the holdout and see what happens.

The key discipline: you only get one shot at the holdout. If you look at the holdout results, tweak the strategy, and run it again, you have contaminated it. It is no longer out-of-sample. It is just more in-sample data with extra steps.

I keep a final holdout set that I genuinely do not look at until a strategy has passed every other test. It is the last gate before a demo account.

Monte Carlo simulation

Monte Carlo takes your backtest trades and asks: what if the order had been different?

The method is straightforward. You take the list of trades your strategy produced, randomise the order, and replay the equity curve. Do this a few hundred times (or a few thousand, compute is cheap). You end up with a distribution of possible equity curves, all using the same trades but in different sequences.

Why this matters: your backtest shows one specific path through the trade sequence. In live trading, the order of wins and losses will be different. Monte Carlo shows you the range of outcomes you might actually experience.

What to look for: the worst-case drawdown across all the simulations. If 5% of the simulated paths produce a 40% drawdown while your backtest showed 12%, you need to size for the 40%, not the 12%. The backtest drawdown was one roll of the dice. Monte Carlo shows you the full distribution.

I also look at the bottom 5th percentile of final equity. If the worst realistic outcome is still profitable, the strategy has a genuine edge that does not depend on getting lucky with trade sequencing.

Parameter plateaus versus spikes

This test is simple, powerful, and catches more fitted strategies than anything else I use.

Take your key parameters (say, a moving average period and a stop-loss distance) and vary them across a range. Plot the performance metric (I use Sortino, but Sharpe or net profit work too) as a surface.

A real edge produces a plateau: a broad region of parameter space where the strategy performs well. The performance is stable across a range of nearby values. If your 20-period moving average works, the 18 and 22 should work too, probably a bit worse, but still profitable.

A fitted strategy produces a spike: one narrow peak where everything works, surrounded by poor performance. Your strategy only works with a 20-period MA, a 14-period RSI, and a 2.3x ATR stop. Change any of those by a small amount and it collapses.

Spikes are memorisation. Plateaus are signal.

When I evaluate a strategy in StrategyQuantX, parameter stability is one of the first things I check. If the performance collapses when I shift a parameter by 10-15%, the strategy is dead. I do not try to rescue it.

Stress tests: spread, slippage, and cost

Your backtest probably assumed tighter conditions than you will get in live trading. This test forces you to confront that.

Take your strategy and re-run it with progressively worse execution assumptions. Double the spread. Add 1 pip of slippage per trade. Triple the commission. See what happens to the equity curve.

A durable strategy degrades gracefully. Performance gets worse, as it should, but it remains profitable at realistic cost levels. A fragile strategy (usually one that trades frequently with small average wins) dies the moment you add real-world friction.

I run every strategy through three cost scenarios: optimistic (the numbers the broker quotes on a good day), realistic (what I actually observe in my MT5 execution logs), and pessimistic (double the realistic figures). If a strategy is not profitable in the pessimistic scenario, I either reduce the trade frequency or bin it.

Historical stress events

I covered this briefly in Chapter 13, but it deserves a mention here because it is part of the robustness battery.

Run your strategy through known stress events. The Swiss franc floor removal (January 2015). COVID volatility (March 2020). The gilt crisis (September 2022). Flash crashes. Central bank surprises. These events are not optimisation targets. They are survival checks.

You are not looking for the strategy to profit during these events (though some will). You are looking for it to behave in a way you can live with. Does the drawdown stay within your risk budget? Does the strategy do something you can explain? Does it recover within a timeframe you can tolerate?

Reading the results honestly

The temptation, after running all these tests, is to cherry-pick the good news. The walk-forward looks fine, so you ignore the Monte Carlo worst case. Or the parameter surface has a plateau, so you overlook the stress-test failure.

Do not do that. The battery works as a whole. A strategy needs to pass all of it. Not because any single test is definitive, but because a strategy that survives every angle of attack is much more likely to be capturing something real.

I have killed strategies that looked good on most metrics but failed one test badly. It stings. You have invested hours. But hours are cheaper than capital, every single time.

Metrics that matter

Numbers lie when you let them. The backtest spits out a wall of statistics, and the temptation is to find the ones that confirm what you want to believe. This chapter is about reading the numbers honestly, understanding what each one actually measures, and knowing which ones flatter.

Sharpe ratio (and when it lies)

The Sharpe ratio is the most quoted risk-adjusted return metric in the industry. The formula is simple: excess return (your return minus the risk-free rate) divided by total volatility (standard deviation of returns).

Higher is better. A Sharpe above 1.0 is generally considered decent for a live strategy. Above 2.0 and you are doing very well. Above 3.0 in a backtest and you should be suspicious (see Chapter 14 on overfitting).

Here is the problem. Sharpe treats all volatility as equally bad. A strategy that makes 2% one month and 8% the next has high volatility, and Sharpe penalises it for that. But those are both positive months. The "volatility" is the variability of your wins, which is not actually a problem you need solving.

This matters most for trend-following strategies. Trend-followers tend to have positively skewed return distributions: lots of small losses and occasional large wins. Those large wins create upside volatility, and Sharpe punishes them for it. A trend-following strategy with a Sharpe of 0.8 might be perfectly healthy. The Sharpe just cannot tell you that.

Sortino: the fix for upside penalty

The Sortino ratio fixes this by replacing total volatility with downside volatility only. Instead of penalising all variability, it only penalises the variability of negative returns. Same numerator (excess return), different denominator (downside deviation).

For strategies with symmetric return distributions (roughly equal upside and downside), Sharpe and Sortino tell a similar story. The relationship diverges when returns are skewed.

Here is a useful rule of thumb. Compare Sortino to Sharpe using the square root of 2 (roughly 1.414) as a benchmark:

Sortino greater than 1.414 times Sharpe: your returns are positively skewed. You have fat right-tail wins. Common in trend-following and breakout strategies.

Sortino roughly equal to 1.414 times Sharpe: your returns are approximately symmetric.

Sortino less than 1.414 times Sharpe: your returns are negatively skewed. You have fat left-tail losses. Common in mean-reversion and volatility-selling strategies.

Neither skew profile is inherently better. But you need to know which one you are running, because negatively skewed strategies can look great for months and then deliver a single catastrophic loss that wipes out the accumulated gains. Knowing your skew tells you what kind of risk you are actually carrying.

Max drawdown: the number that keeps you up at night

Max drawdown (max DD) measures the largest peak-to-trough decline in your equity curve. It is the worst losing streak, expressed as a percentage.

Every trader says they can handle drawdowns. Then a real one arrives and the psychology changes completely. A 20% drawdown means you need a 25% gain just to get back to where you started. A 50% drawdown requires a 100% gain. The maths gets cruel quickly.

I treat max drawdown as the single most important number in any backtest report. Not because it is the most sophisticated metric, but because it is the one most likely to make you quit. And a strategy you abandon during a drawdown produces exactly the same outcome as a strategy that does not work.

A useful floor: if your backtest max DD is above the number that would make you pull the plug in live trading, the strategy is not sized correctly. Resize first, then re-evaluate.

Time under water

Max drawdown tells you how deep the hole gets. Time under water (TUW) tells you how long you stay in it.

TUW measures the longest stretch your equity curve spent below a previous peak. A 5% drawdown that recovers in three weeks is a completely different experience from a 5% drawdown that takes ten months to recover. The depth is the same. The psychological and practical impact is worlds apart.

Allocators (people who decide where to put capital) stress-test recovery time before depth, and they are right to. Most people can endure a sharp drawdown if the recovery is quick. A shallow, grinding drawdown that drags on for months will break discipline in ways a sharp dip never does.

I build TUW into my monthly reporting alongside max DD. If a strategy's longest recovery period is longer than I can realistically tolerate without interfering, it does not matter how good the other numbers look. I will not stick with it.

Calmar ratio

The Calmar ratio approaches the risk question from the drawdown side directly: annualised return divided by max drawdown.

A Calmar above 1.0 is a useful floor. It means your annualised return at least matches your worst historical drawdown. Below 1.0, your drawdowns are eating more than you are making, and the compounding maths starts working against you.

The related MAR ratio (CAGR divided by max DD) does the same job with compound annual growth rate instead of simple return. The interpretation is identical: higher means your compounding is outpacing your drawdowns.

Expectancy

Expectancy tells you how much you expect to make per trade, on average. The formula: (win rate times average win) minus (loss rate times average loss).

A positive expectancy means your strategy makes money per trade on average. But "on average" hides a lot. A strategy with 30% win rate and a 3:1 reward-to-risk ratio has positive expectancy. So does a strategy with 70% win rate and a 0.5:1 ratio. They feel completely different to trade.

Expectancy is most useful as a sanity check. If your backtest shows positive expectancy and it holds up in out-of-sample testing, the strategy probably has a genuine edge. If the expectancy is tiny (say, a few pence per trade), costs will likely kill it live.

The full picture

No single metric tells the whole story. Sharpe alone hides the skew. Max DD alone hides the recovery. Expectancy alone hides the volatility of outcomes.

I report Sharpe, Sortino, Calmar, max DD, time under water, and expectancy together. The full set gives me a picture I can trust. When all six are telling the same story, I have something worth progressing to a demo account. When they disagree (high Sharpe, long TUW, low Calmar), something is off and I need to dig deeper.

The goal is honest assessment. The numbers are there to protect you from your own optimism. Let them do their job.

Making the test realistic

A backtest that ignores trading costs is a fantasy. It might be a useful fantasy for early-stage research, when you are just trying to see if a signal exists at all. But the moment you start evaluating whether a strategy is worth deploying, costs have to be in the model.

Spread

The spread is the difference between the bid and ask price. Every time you enter or exit a trade, you cross this gap. In a backtest, you need to decide what spread to assume.

Most platforms default to either zero spread or a fixed spread. Both are wrong, but in different ways. Zero spread overstates every trade by the full cost of the round trip. Fixed spread is closer to reality but misses the fact that spreads widen during news events, low-liquidity sessions, and market opens.

I model spread using the average observed spread from my broker's historical tick data where available, and a conservative fixed estimate where it is not. For EURUSD, I might use 0.8 pips as a baseline. For a less liquid cross like NZDCAD, I use 2.5 or higher. The key is to be honest about what you actually pay..

If your strategy trades frequently (more than a few times per day), spread sensitivity matters enormously. Run your backtest at your baseline spread, then at 1.5 times that spread, then at double. If the strategy dies at 1.5 times, it is too fragile for live deployment.

Slippage

Slippage is the difference between the price you expected and the price you actually got. In a backtest, your order fills at the exact price on the chart. In live trading, it fills at whatever price is available when your order reaches the server.

Slippage can work in your favour (positive slippage) or against you (negative slippage). Over a large number of trades, it tends to be negative. Market orders during fast moves will fill worse than the last quoted price. Limit orders avoid slippage but introduce a different problem: they might not fill at all, and your backtest assumed they always did.

I add a fixed slippage assumption to every backtest. For FX majors on MT5, I use 0.3 to 0.5 pips per trade. For indices and metals, I use the equivalent of 1 to 2 points depending on the instrument. These are conservative estimates based on what I see in my own execution logs.

The honest approach: pull your real execution data from your broker, compare the fill prices to the prices at the moment of order submission, and calculate your actual average slippage. Use that number in your backtests. If you do not have live data yet, err on the pessimistic side. You will thank yourself later.

Commission

Commission is the simplest cost to model and the easiest to forget. Your broker charges per lot or per trade. It is a fixed, known quantity. Put it in the backtest.

The mistake I see most often: modelling commission on entry but forgetting exit, or modelling it per trade when the broker charges per lot. Small errors, but they compound across hundreds of trades.

Check your broker's actual fee schedule. Use the exact number. This one has no ambiguity.

Execution assumptions

Beyond the three explicit costs, there are subtler assumptions baked into most backtests that do not hold up live.

Fill assumptions are the biggest one. Your backtest assumes every order fills at the requested price, at the requested time, in the requested size. In live trading, market orders fill at the available price (which may have moved). Limit orders may not fill at all if the price touches your level but does not trade through it. Stop orders in fast markets can gap past your stop level entirely.

Timing assumptions matter too. If your strategy uses a daily close to make a decision, your backtest assumes you execute at exactly the close price. In practice, you might execute a few seconds or minutes later, and the price may have moved. For strategies trading on higher timeframes (daily, weekly), this slippage is usually negligible. For strategies trading on 1-minute or 5-minute bars, it can be significant.

Liquidity assumptions are the most silent here. Your backtest assumes infinite liquidity: you can always buy or sell any size at the quoted price. For retail-sized FX positions, this is mostly true on major pairs during London and New York sessions. For less liquid instruments, wider spreads, or larger position sizes, the assumption breaks down.

Why beautiful backtests die live

The pattern is almost always the same. A strategy shows a strong equity curve in backtesting. The trader goes live. The first few trades look different from the backtest. Fills are worse. Costs are higher than modelled. A few trades that were winners in the backtest are losers live because the spread ate the edge.

Within a few weeks, the live equity curve diverges from the backtest. The trader starts doubting the strategy. Maybe they pull it, or they start tinkering with the parameters live (which is worse). The strategy never had a chance because the backtest was promising something the live market was never going to deliver.

The fix is to close the gap before you go live. Model the friction honestly. Use pessimistic cost assumptions. Run the strategy on a demo account for long enough to compare real fills against backtest fills. If the demo results track the pessimistic backtest, you have something worth sizing up. If the demo results track the optimistic backtest, your cost model was too generous and you need to re-evaluate.

The boring truth: the strategies that survive live deployment are rarely the ones with the best backtest curves. They are the ones with the most realistic backtest assumptions.

Position sizing and the maths of ruin

Most of the energy in systematic trading goes into entries. Which signal, which filter, which confirmation. I get it. Entries feel like the interesting bit. But entries are not what keep you in the game. Sizing is.

A strategy with a genuine edge and reckless sizing will blow up. A mediocre strategy with disciplined sizing will survive long enough to improve. That asymmetry is the entire lesson of this chapter.

Risk per trade

Every trade you take should risk a defined percentage of your account equity. You decide that number before you open a position, and it sets your stop distance and lot size together. The calculation is straightforward: how much of your equity are you prepared to lose if this trade hits its stop?

I target a maximum drawdown of around 1% per sub-strategy. That is not 1% per trade in isolation. It is the worst-case contribution of a single sub-strategy to the total book, accounting for the fact that a sub-strategy might have more than one position open. You will hear people talk about "risking 2% per trade" as a rule of thumb. That number is not sacred. What matters is that you pick a number, size to it, and never override it because a setup "looks good."

The moment you start adjusting position size based on conviction, you are discretionary trading with a systematic wrapper. That is a worse version of both approaches.

The maths of ruin

There is a formula that makes the sizing argument concrete. Risk of ruin:

P(ruin) = ((1 - edge) / (1 + edge)) ^ units

Three inputs. Your edge (expressed as a fraction of each unit risked), and the number of units of risk you have available. "Units of risk available" means your account size divided by your risk per trade.

Work through it. Say you have a 1% edge per trade and you risk 0.5% of your account per trade. That gives you 50 units of risk (you can lose 50 consecutive trades before you are wiped out, assuming no compounding effects). Plug those numbers in: P(ruin) = ((1 - 0.01) / (1 + 0.01)) ^ 50. That comes out at roughly 37%.

Thirty-seven percent. You have a genuine edge, you are risking half a percent per trade, and your probability of eventual ruin is still over a third. That should make you uncomfortable.

Now reduce the risk per trade to 0.2%. Your units jump to 125. Same formula: P(ruin) drops to around 8%. You did nothing to improve the strategy. You just sized smaller. The probability of ruin fell by nearly 30 percentage points.

This is the counterintuitive result that most people miss. Reducing your position size by half does roughly the same work as doubling your edge. And doubling your edge is brutally hard. Cutting your size in half takes one line of code.

Every candidate strategy in my pipeline runs through this formula at its proposed sizing before it goes anywhere near live capital. If the ruin probability is too high, I do not look for a better entry. I size smaller.

Why the ruin threshold matters

Ruin does not have to mean zero. You can define it as any drawdown level that would force you to stop trading: a margin call, a psychological breaking point, a level where you would lose confidence in the system and pull the plug. For most retail traders, ruin is somewhere between 30% and 50% drawdown. Pick your number honestly. If you know you would abandon the system at 25% down, that is your ruin threshold, and you should use it in the calculation.

Portfolio heat

Risk per trade is necessary, but it is not sufficient. The failure mode I see most often is traders who control risk at the strategy level and completely ignore what happens when multiple strategies fire at the same time.

Portfolio heat is your total open risk across all positions, measured as the sum of (distance to stop multiplied by position size) for every open trade. If you are running five strategies and each has two positions open, you might have ten live trades. Each one is within its individual risk limit. But added together, they could represent 8% or 10% of your equity at risk simultaneously.

I run a portfolio-level heat cap. When total open risk across all positions reaches the ceiling (I use a range of 3% to 5% of book equity, depending on conditions), new entries are blocked. The strategy might be screaming to open a position. The heat cap says no. That is a hard override, not a suggestion.

The deeper point: per-trade risk discipline breaks down at the portfolio level if you do not measure aggregate exposure. You can be perfectly disciplined on every individual trade and still blow up because you never looked at the total.

Sequencing and drawdown

The maths of ruin assumes independent, identically distributed bets. Real trading is messier. Losses cluster. Correlated strategies draw down together (more on that in the next chapter). Volatility regimes shift, and a sizing scheme calibrated for one regime can be dangerously wrong in another.

Something I think every systematic trader should model is something as follows: Position sizes adjust based on recent realised volatility and current drawdown. When the book is in drawdown, sizes shrink. When volatility expands, sizes shrink. Design the system to get smaller when things go wrong, which is the opposite of what most people do instinctively.

The maths of ruin tells you the minimum sizing discipline required. Real-world sequencing tells you that the minimum is probably not enough. Build the margin of safety into your sizing from the start. You will not regret having room to breathe during a losing streak. You will absolutely regret being too large when one arrives.

Correlation

You build five strategies. They trade different instruments. They use different logic. The correlation matrix on raw returns looks green: low numbers, lots of diversification. You feel clever.

Then the market moves hard in one direction, and all five draw down at the same time. The diversification you thought you had was an illusion. This chapter is about why that happens and what to do about it.

Hidden correlation across "different" strategies

I run a EUR mean-reversion strategy and a GBP mean-reversion strategy in XAQP. Different instruments. Different entry parameters. But their daily P&L correlation sits in the 0.4 to 0.7 range, depending on the window. Why? Because they share structural exposure. Both are short-vol, both profit from range-bound conditions in European FX, and both get hurt by the same macro catalyst: a strong directional move in the dollar.

Different instruments, similar underlying bet. This is the pattern that catches people. You look at the labels (EUR vs GBP, trend vs mean-reversion, FX vs indices) and assume diversity. But diversity lives in the P&L, not the labels.

Why it spikes when it hurts

Correlation is not static. It rises in stress. The strategies that looked independent during calm markets start moving together when volatility expands, because the factor exposures they share become the dominant driver of returns. A green correlation matrix computed on two years of data can turn red in a single week.

There is a subtler version of this trap. Most correlation matrices are computed on raw returns, which embed volatility. A manager shows you a matrix full of low correlations. An allocator strips out the vol component, adjusts for regime, and the matrix turns red. The "diversified" book was really one factor exposure expressed through multiple instruments. Either the factor model was wrong, or the strategies were less diverse than they appeared.

Correlation budgeting

I use a simple framework for thinking about correlation across strategies in the portfolio. Measure it on daily P&L (not returns, P&L), using a minimum of six months of data. Twelve months is better for stability.

Three buckets:

Below 0.3: treat the strategies as independent for sizing purposes. They are genuinely adding diversification.

0.3 to 0.6: apply a position-size haircut. These strategies have meaningful shared exposure. If you size them as though they are independent, you are overstating your diversification and understating your aggregate risk.

Above 0.6: you do not have two strategies. You have one strategy in two arrangements. Size accordingly, or drop one.

This is not a perfect system. Correlation shifts, and the buckets are guidelines rather than hard boundaries. But it forces you to ask the right question: how much of my book is really the same bet?

Portfolio thinking

The previous chapter covered portfolio heat as a total-risk cap. Correlation is the reason that cap exists. If your strategies were truly independent, aggregate risk would scale with the square root of the number of positions (basic portfolio theory). But they are not truly independent. When correlation is present, aggregate risk scales faster, and in a stress event it can scale almost linearly.

This is why I run a dual-layer risk system in XAQP. The first layer is at the sub-strategy level: each strategy has its own risk budget and drawdown target. The second layer is a portfolio overlay that looks at the aggregate. If the portfolio-level metrics breach their limits, the overlay reduces exposure across the board, regardless of what any individual strategy is doing.

You need both layers. The sub-strategy layer handles normal conditions. The portfolio overlay handles the correlated drawdowns that the sub-strategy layer cannot see.

A note on keeping the books separate

I run a trading book (XAQP, systematic, CFDs, active) and an investing book (equities, ETFs, crypto, long-term holds). They serve different purposes and they fail in different ways when you confuse them.

The trading book is sized for turnover and drawdown. The investing book is sized for compounding over years. If I start applying systematic-trading risk rules to my long-term equity holdings, I will overtrade them. If I start applying buy-and-hold patience to a systematic strategy in drawdown, I will hold losers too long.

The flywheel works like this: the job pays the bills, the trading book generates performance fees, and those fees compound into the long-term portfolio. Each book has its own rules, its own risk framework, and its own mental model. Mixing them is a reliable way to get the worst of both.

The practical takeaway

Before you add a new strategy to your book, measure its P&L correlation against everything already running. If it is above 0.6 with an existing strategy, you are adding concentration, not diversification. If it is in the 0.3 to 0.6 range, haircut the sizing to reflect the shared exposure.

Diversification is not about counting strategies. It is about measuring how differently they behave when things go wrong.

Regime filters and their traps

The pitch for regime filters sounds reasonable. Markets move between states: trending, choppy, volatile, quiet. A trend system bleeds through chop. A mean-reversion system gets steamrolled in a breakout. If you could identify the current regime and only run the strategy suited to it, you would avoid the ugly stretches and keep the good ones.

That is the theory. In practice, regime filters are one of the easiest ways to add complexity that looks smart in a backtest and costs you money live.

The appeal

The cost of running unfiltered is real. I have seen it in my own testing. A trend strategy that makes its money in three or four strong moves per year will give back a meaningful chunk of that during the flat months in between. A mean-reversion strategy that prints steady returns in range-bound conditions can take a single large loss in a breakout that wipes out weeks of gains.

A filter that correctly identifies the regime before the strategy enters would solve this. You would trade the trend system only when the market is trending, and switch it off when it is not. Your equity curve would be smoother, your drawdowns shallower, your Sharpe ratio higher.

In a backtest, this works beautifully. The filter has the benefit of hindsight: it knows when the regime changed because it can see the data that came after the change. Live, you do not have that luxury.

How they quietly overfit

A regime filter is an extra layer of parameters. You are defining what constitutes a "trending" market versus a "choppy" one, choosing a lookback window, setting thresholds. Each of those choices is a degree of freedom, and each degree of freedom is an opportunity to fit to noise.

The deeper problem is that regime classification is inherently laggy. Regimes do not announce themselves. By the time your filter has enough evidence to call a regime change, the regime is already underway. And by the time it recognises the regime has ended, the strategy has already missed the turn.

A filter that misreads the regime hurts you twice. It pulls you out of good conditions (you miss the continuation of a trend because the filter flagged chop too early) and it puts you back in late (the trend resumes, the filter does not clear until the move is half done, and you enter at a worse price with less room to run).

Those two costs are invisible in a standard backtest because the filter's definitions were tuned on the same data. The misclassification losses are baked into the optimisation and minimised away. Live, they come back.

Testing whether a filter earns its place

I do not reject regime filters outright. Some strategies genuinely perform better in identifiable conditions, and a well-built filter can improve risk-adjusted returns. The question is how to tell the difference between a filter that captures real structure and one that is just another optimisation artefact.

Here is the exercise I run.

Step one: label your backtest history with your regime definition. Whatever classification you are using (volatility percentile, ADX threshold, slope of a moving average), apply it across the full dataset and tag every bar.

Step two: split expectancy by label. Calculate your strategy's performance separately for each regime. If the strategy's edge concentrates in one regime and losses concentrate in another, you have a candidate for filtering.

Step three: price the misclassification. This is the step most people skip. Degrade your regime switch dates. Add lag: shift the transition point forward by a few bars, simulating the delay you will experience live. Then flip some of the calls entirely: randomly reclassify a percentage of regime transitions as the wrong regime. Run the strategy with these degraded labels.

If the filtered strategy still outperforms the unfiltered version after you have added realistic lag and random misclassification, the filter is capturing something real. Build it.

If the edge disappears when you degrade the labels, the filter was fitting to the precision of your historical classification. Live, that precision will not exist, and the filter becomes a complexity tax: more code to maintain, more parameters to monitor, more ways to break, and no improvement in returns.

In my experience, most regime filters fail step three. The ones that survive tend to be simple (a single volatility measure with a wide threshold band, for example) rather than elaborate multi-indicator classifiers. Complexity in filters is almost always a sign of overfitting. If the regime distinction is real and tradeable, a blunt tool will capture it. If you need a sharp tool, the distinction probably is not there.

Demo to live

You have a strategy that passed your backtesting battery. It survived walk-forward analysis, Monte Carlo stress tests, and a period of forward testing on a demo account. Now you need to put it on a live server and let it trade real money. This chapter covers the infrastructure, the deployment process, and the psychological shift that no amount of demo trading prepares you for.

The VPS

A VPS (virtual private server) is a remote computer that runs your strategies 24/7. It sits in a data centre with redundant power and internet, which means your system keeps trading even when your home broadband drops, your laptop goes to sleep, or your power goes out.

You can run a strategy from your home computer. I would not recommend it. FX and index markets run nearly around the clock. If your strategy needs to manage an open position at 3am and your PC has restarted for a Windows update, you have an unmanaged trade. That is an unforced error, and systematic trading is specifically about eliminating unforced errors.

For MT5, which is what I use for XAQP, a basic Windows VPS with 2GB of RAM is enough for most setups. You want the VPS located close to your broker's server to minimise latency, though for strategies operating on timeframes of 15 minutes or longer, a few milliseconds of latency is irrelevant. What matters is uptime. Pick a provider with a strong uptime record and automatic failover.

Cost is modest. A decent VPS runs between $15 and $50 per month depending on specs and location. That is a rounding error compared to the cost of a missed exit or an unmonitored position.

Deployment

Deployment means getting your strategy onto the VPS and running it in a state where it can execute trades on a live account. Here is the process I follow.

First, install your platform on the VPS. For MT5, this means a standard installation, logging into your broker account, and loading the relevant charts and timeframes. Second, deploy your strategy code (Expert Advisors in MT5 terminology) to the correct directory. Third, attach the strategy to the appropriate chart with the correct parameters.

Before you enable live trading, run the strategy on the VPS in a visual mode or with logging enabled. Confirm it is generating the same signals you saw in your backtest and demo testing. Check that the spread and commission assumptions in your backtest match what your broker is actually charging. If your backtest assumed a 1-pip spread on EURUSD and your live account is showing 1.8 pips during Asian hours, your edge may be thinner than you think.

Once you are satisfied the strategy is behaving as expected, enable auto-trading. Start with minimum position sizes. You can scale up later. The first objective is to confirm the system runs correctly in a live environment, not to maximise returns from day one.

Monitoring week one

The first week of live trading is a diagnostic window. You are not watching to see if the strategy makes money. You are watching to see if it behaves the way your testing said it would.

Check these things daily during week one:

Trade execution: are orders filling at the expected prices, or is slippage (the difference between your intended price and the actual fill price) eating into your edge? Some slippage is normal. Consistent slippage that exceeds your backtest assumptions is a problem.

Position sizing: is the strategy sizing positions correctly? A decimal error in lot sizing can turn a 1% risk trade into a 10% risk trade. Confirm the maths on every trade during this first week.

VPS stability: is the platform staying connected? Check for disconnections, restarts, or memory issues. Set up email or push alerts for connection drops if your platform supports them.

Order management: are stops and take profits being placed correctly? Are trailing stops adjusting as expected? This is where bugs hide. A strategy can look perfect in a backtest and still mishandle order management in live conditions because of differences in how your platform processes orders in real-time versus in testing.

Keep a log of every trade during week one, including timestamps, fill prices, spread at time of entry, and any anomalies. Compare each trade against what your backtest would have generated for the same signal. You are looking for consistency between tested and live behaviour.

Scaling up

If week one is clean, begin scaling toward your intended position size. I do this in steps: 25% of target size, then 50%, then full size, with a few days at each level. This is not about the money. It is about giving yourself time to catch any issues that only appear at larger sizes, such as partial fills or liquidity constraints.

If something looks wrong at any stage, stop and diagnose before scaling further. The cost of going slowly is trivial. The cost of deploying at full size with a bug in your order logic is not.

The emotional shift

Here is the part no one can fully prepare you for: real money feels different.

On demo, a drawdown is data. On live, a drawdown is your money disappearing. The strategy is the same. The signals are the same. The maths has not changed. Your emotional response has. Trades you would have ignored on demo will keep you awake at 2am on live. You will feel the urge to intervene, to override a signal, to tighten a stop, to skip a trade that "feels" wrong.

This is normal. It is also the single biggest risk to your system's performance. Every intervention you make is a deviation from the tested process. Some of those deviations will work out, which makes them dangerous, because they teach you that overriding the system is acceptable. It is not. If the system needs changing, change it in research, test the change, and redeploy. Do not change it mid-trade because your stomach is churning.

I still feel the pull to intervene on XAQP, and it has been live since April 2025. The difference is I have built a process that makes intervention difficult. Auto-trading is on. Alerts notify me of issues. I review performance weekly, not tick by tick. The system runs. I review. That separation is the whole point of systematic trading.

Start small. Follow the process. Trust the testing you have already done. The goal of week one is not profit. It is proof that your system, your infrastructure, and your temperament can coexist.

Capacity and how to manage it

Capacity is the ceiling you do not see until you hit it. Every strategy has one. It is the maximum amount of capital a strategy can manage before its own activity starts degrading its returns. Once you cross that line, you are literally trading against yourself.

Here is the mechanism. Your strategy generates a signal, say a breakout on EUR/USD. It sends a market order. That order needs to be filled, and the fill comes from available liquidity at that price level. If you are trading a $10,000 account, your order is a rounding error in the order book. The fill is clean, the slippage is negligible, and the strategy performs as backtested.

Now scale that to $2M. Same signal, same instrument, same time of day. Your order is no longer a rounding error. It moves the price. The entry you backtested at 1.0850 fills at 1.0853. Three pips of slippage on every entry. On a strategy with an average winner of 15 pips, you have just given back 20% of the edge before the trade even begins.

That is capacity. The structural ceiling beyond which market impact eats the edge faster than the strategy can generate it.

How it shows up in practice

The first place most people notice capacity is in slippage (the difference between the price your strategy intended to trade at and the price it actually received). In liquid pairs during London hours, slippage on a small account is negligible. But thin order books tell a different story.

Sunday opens are a classic example. Liquidity is sparse. Spreads are wide. If your strategy happens to trigger entries on a Sunday evening, the fills can be dramatically worse than anything your backtest assumed. And backtests, unless you have modelled variable spread and slippage explicitly, assume perfect fills at the historical close price. They do not know that the order book at 10pm on a Sunday is a fraction of what it is at 2pm on a Tuesday.

The same problem applies to exotic crosses, to metals during Asian hours, to indices outside their home session. Thin order books mean your order has outsized impact, and that impact compounds as the account grows. The strategy does not change. The market's ability to absorb your orders does.

The number that shocked me

I want to share a real example because I think it illustrates the point better than any theory.

When XAQP was scaling through its first year of live trading, I was monitoring capacity utilisation (Cp), a metric that measures what percentage of available capacity the portfolio is currently using. At peak, it hit around 47%. That stopped me in my tracks.

The maths was simple. If 47% utilisation corresponded to the AuM I was running at that point, then full capacity was somewhere around $3.5M to $4M. That is the total. The hard ceiling. Beyond that, the strategies would be degrading their own fills faster than they could generate returns.

For context, $3.5M to $4M is a respectable amount of capital. It is not generational wealth. It is not a number that lets you compound indefinitely into something life-changing. It was a wake-up call: the strategies were good, the edge was real, and the ceiling was far lower than I had assumed.

That realisation forced me to think seriously about execution. Specifically, about how the orders themselves were being sent.

Order splitting: the fix

The core idea behind order splitting is simple. Instead of sending one large order, you split it into N smaller orders with a configurable delay between each one. Each smaller slice has less market impact. The order book has time to replenish between fills. The average entry price across all slices is closer to the price your strategy intended to trade at.

I built my own order-splitter code for this. It takes a single entry signal and breaks it into a defined number of positions, firing each one after a set delay. The delay is configurable: for liquid pairs during London session, a few seconds is enough. For thinner markets, I space it wider.

A few important clarifications. My order splitter is a slicer. It splits a block into tranches and fires them sequentially with a delay. It does not calculate time-weighted average price (TWAP) or optimise the execution schedule dynamically. TWAP is a separate and more sophisticated approach. Marti at Darwinex Labs has built an open-source TWAP library that does exactly that. The two tools solve related problems from different angles. Mine is simpler and solves the immediate capacity constraint at my current scale. If you are running significantly larger capital, TWAP and other algorithmic execution methods become more relevant.

The result

After implementing order splitting across the portfolio, capacity utilisation dropped from around 47% to around 1%. Same strategies, same signals, same instruments. The only change was how the orders were being sent to the broker.

That single change moved the capacity ceiling from roughly $3.5M to $4M up to a level where it was no longer the binding constraint on scaling. The edge that was being eaten by market impact came back.

I have made the order-splitter code available as a free download on this site at /Resources/order-splitting.html. If you want to see the logic and adapt it for your own setup, it is there. Marti's TWAP library from Darwinex Labs is also worth reading as a companion piece if you want to understand the more sophisticated end of algorithmic execution.

Why beginners should care about this now

You might be reading this with a $5,000 account thinking capacity is a problem for future you. Fair enough. At $5,000, it probably is not your binding constraint.

Here is why it matters anyway. You do not know how fast you will scale. If you build a strategy with a genuine, durable edge and you start publishing a verified track record, capital can arrive faster than you expect. An allocator who likes your numbers might want to put $5M behind you. If your strategy caps out at $500K of capacity, you cannot take that capital. The opportunity arrives, and you are structurally unable to accept it.

Worse, if you have never thought about execution quality and order sizing, you might take the capital, watch slippage eat your edge, and hand back a drawdown to an investor who trusted your track record. That is a career problem.

The time to think about capacity is during strategy design. Build your strategies on instruments with enough liquidity to scale. Model realistic slippage in your backtests. And when the account grows, have the execution tools ready to manage the transition. Order splitting is not complicated to implement. The code is straightforward. The hard part is knowing you need it before the damage is done.

Trading on Darwinex Zero

Disclosure: I work for Darwinex as Head of UK Growth and Business Development. Weigh everything in this chapter accordingly. I have done my best to present a balanced view, but I am not a neutral party, and you should factor that in. If you read this chapter and think "of course he's going to say that," you are right to think it. Read critically.

This chapter covers one specific route to external capital: structured allocation platforms. I use Darwinex Zero because I work there and because it solved a set of problems I had. That does not make it the only route, or the right one for you. I will walk through the problems it solves, the alternatives, and the trade-offs as honestly as I can.

The portfolio-margin problem

When you trade a multi-strategy portfolio on a personal account, you run into a structural issue fairly quickly. Each strategy needs its own margin allocation. As you add strategies across FX, indices, and metals, the total margin requirement climbs. On a personal account, you are constrained by the capital you have deposited. If your portfolio requires more margin than you have in the account to run all its strategies simultaneously, something has to give. On Darwinex Zero, the virtual balance is $100K (or $1M on Futures), which sets the ceiling for how many strategies you can run concurrently. You either run fewer strategies, reduce position sizes, or accept that some signals will not fire because the margin is not there.

Structured platforms solve this by separating the strategy execution from the capital. On Darwinex Zero, for example, your strategies run on a simulated account with a notional allocation. The platform independently tracks every trade, verifies every fill, and builds a performance record from the execution data. If investor capital subsequently backs your strategy, the platform handles the capital management and margin. Your job is to generate signals and manage the portfolio. The capital infrastructure sits on the platform side.

This is one solution to the margin problem. Others exist. Self-managed fund structures let you pool investor capital under your own entity, though the legal, compliance, and operational overhead is substantial. Signal-provider agreements let you sell execution signals to a third party who manages the capital. Personal accounts with larger deposits solve the margin problem directly, though they concentrate your own capital risk. Each has trade-offs in cost, complexity, and scalability.

Building a record investors can verify

If you want external capital, you need a track record that someone other than you can vouch for. That sounds obvious. In practice, most retail systematic traders have nothing of the sort.

A screenshot of your MetaTrader equity curve is not a verifiable track record. A broker statement is closer, but it still relies on the investor trusting your account reporting. The question an allocator is actually asking is: can I independently confirm that these trades happened, on this timeline, with this drawdown profile, and that nobody cherry-picked the reporting window?

Structured platforms provide this by design. Every trade is logged independently. The performance metrics are calculated by the platform. An allocator can pull up the track record without needing to trust the trader's own reporting. The verification is built into the infrastructure.

Other prop firms and allocation platforms offer similar verification (I am not going to name competitors here, but they exist and you should research them). The specific platform matters less than the principle: a third-party-verified track record, on real or tracked capital, through a real drawdown, is the one credential that is extremely difficult to fabricate. Everything else, the pitch deck, the backtest, the educational content, is downstream of that.

As I have written elsewhere: verifiable track record first, everything else second.

The path to capital

Most successful allocations do not start with outreach. In my experience, investors discover managers through three surfaces, roughly in this order.

First, allocation programmes that independently audit trading. Performance-based allocations, where capital is awarded based on verified metrics. On Darwinex, this takes the form of DarwinIA (a monthly allocation programme) and INDX (a curated index of strategies that meet specific quality thresholds). Part of my capital came through this route. The strategies performed, the metrics were public, and the allocations followed from the numbers. I also have boutique fund agreements outside of my Darwinex allocation, so the platform is one channel, not the whole picture.

Second, practitioner networks and boutique allocations. Once you have a verified track record, people in the space notice. Referrals from other traders, introductions through industry contacts, conversations at events. This is the second layer. It requires the track record to exist before it produces anything.

Third, inbound from publishing your work with real numbers. Writing publicly about your process, your results, your mistakes, with actual figures attached, attracts a specific kind of reader. Some of those readers manage capital. This is the slowest channel but it compounds over time.

One thing worth emphasising: not every deal is a good deal. If an allocator wants to back you but the terms undervalue your capacity, you are better off waiting. Do not sell capacity for less than it is worth just to say you have external capital. The track record is the leverage. Protect it.

When allocators do engage, they are typically defending you to a committee. They need material they can quote: verified performance, risk metrics, drawdown recovery, strategy descriptions. Hand them something concrete. A verified track record on a structured platform gives them exactly that.

The alternatives, honestly

Structured allocation platforms are one path. Here are the others, because you should know about them.

Other allocation platforms and prop firms. Several exist beyond Darwinex. Some are well-structured with genuine verification. Others are closer to the online prop firm model, which has its own set of problems (I have written about that elsewhere). Research them. Look at the fee structure, the verification standard, and whether real capital actually gets allocated or whether the "allocation" is a marketing claim.

Self-managed fund structures. You set up your own fund entity, raise capital, manage it. This gives you full control and full economics. The cost is significant: legal setup, compliance infrastructure, administration, auditing, reporting. For a systematic trader running $500K to $5M, the overhead can consume a meaningful portion of returns. It becomes more viable at larger scale.

Track record on personal accounts. You trade your own money, build a record on your broker statements, and present it to allocators directly. This works, but the trust threshold is higher. Allocators have less independent verification, and they know it. Your record is as credible as your broker's reporting and the allocator's willingness to trust it.

Signal-provider agreements. You generate the signals, a third party executes and manages the capital. This separates your trading skill from the operational burden of capital management. The trade-off is that you give up control of execution and typically earn a smaller share of the economics.

None of these is categorically better. The right choice depends on where you are, how much capital you manage, what operational infrastructure you can support, and what trade-offs you are willing to accept.

The conflict disclosure, once more

I want to close by restating the obvious. I work for Darwinex. I traded on Darwinex Zero. Part of my capital came through Darwinex's allocation programmes, though I also have agreements with boutique funds outside the platform. I am, by any reasonable standard, the least objective person to write this chapter.

I have included it anyway because structured platforms are a real part of how systematic traders access capital, and leaving the chapter out would be a bigger distortion than including it with full disclosure. The mechanism is real. The alternatives are real. The trade-offs are real. You have my bias statement at the top of the chapter and again here at the bottom. Do your own research.

When to trust it, when to pull it

Every strategy you deploy will, at some point, lose money for long enough that you question whether it still works. This is the hardest problem in systematic trading. The drawdown is real. The question is whether the edge behind the strategy is still real too.

Strategy decay does not announce itself. It arrives dressed as an ordinary drawdown. Your job is to build a framework, before you go live, that tells you the difference between a normal rough patch and a dead edge. If you wait until you are deep in a drawdown to start thinking about this, you will make the decision emotionally. Emotional decisions in systematic trading are almost always wrong.

The kill switch

A kill switch is a pre-defined rule that takes a strategy off the book when its behaviour leaves the envelope you built it for. You design it during research, before the strategy goes live, and you do not negotiate with it afterwards.

I use three thresholds for every strategy in XAQP, and all three are written in before the strategy touches live capital. The trigger is automated.

Drawdown threshold. Run a Monte Carlo simulation (a process that randomises the order and characteristics of your backtested trades to generate thousands of possible equity paths) on your backtest results. Find the 95th-percentile maximum drawdown. That is your line. If the live strategy's drawdown exceeds that level, the kill switch fires.

Recovery-time threshold. Drawdown depth alone is not enough. A strategy can stay within its drawdown limit but take far longer to recover than its history suggests it should. I use a combined rule: if drawdown exceeds the 95th-percentile maximum AND recovery time exceeds 1.5 times the 90th-percentile backtested recovery period, the strategy comes off.

Regime-mismatch flag. This one is more nuanced. I run a rolling factor decomposition (breaking the strategy's returns down into the market factors driving them) to check whether the strategy's return drivers have drifted from what the backtest period showed. If the decomposition shows the strategy is now being driven by factors it was never designed to capture, that is a structural change, not a drawdown.

When any of these rules fires, the strategy comes off. Not paused. Off. "Paused" is a word people use when they want to leave the door open to re-enable the strategy without doing the work to understand why it failed. It is not. Off means the strategy goes back to research. If it can be fixed, tested, and redeployed, fine. If it cannot, it stays dead.

Noise versus signal in live-vs-backtest divergence

Some divergence between live and backtested performance is guaranteed. Slippage, spread variation, data differences, timing of fills: these all introduce small discrepancies that accumulate over time. The question is whether the divergence you are seeing fits within the range your testing predicted.

This is where your Monte Carlo simulation earns its keep. If you ran 10,000 simulated equity paths during testing, you have a distribution of possible outcomes. Your live performance is one more path through that distribution. If it falls within the middle 90% of simulated outcomes, the divergence is likely noise. If it is tracking the bottom 5%, you have a strategy that is underperforming relative to its own tested range, and your kill switch should be getting close to firing.

Track the comparison quantitatively. A spreadsheet or dashboard that overlays live equity against the simulated confidence bands makes this trivial. Eyeballing the equity curve is not a process. Numbers are.

Deciding to pull a system

The kill switch handles the clear-cut cases. The harder decisions are the ones where the strategy is underperforming but has not triggered a threshold. It is limping along, making less than you expected, drawing down more often, recovering more slowly.

Here is my framework for those situations. I ask three questions:

Has the market regime changed in a way that structurally undermines the strategy's logic? If I run a breakout strategy and the instrument has shifted into a sustained low-volatility range, the strategy's edge (capturing large directional moves after periods of compression) may no longer apply. That is a structural reason, not a statistical one.

Is the strategy's behaviour consistent with its worst backtested periods? Every strategy has bad stretches in its history. If the current performance looks similar to those stretches, and the strategy recovered from them in testing, patience is probably the right call.

Am I rationalising? This is the honest question. If I find myself inventing reasons to keep a strategy running because I spent months building it, or because pulling it feels like failure, I am no longer making a systematic decision. The strategies I have killed are the ones that have funded the strategies that have compounded.

Journaling and iterating

Every strategy, running or retired, gets a journal entry at least monthly. The entry covers: current performance versus expected range, any kill-switch metrics approaching thresholds, regime notes, and a forward view (do I expect conditions to favour or penalise this strategy over the coming weeks?).

This journal is not a diary. It is an audit trail. When a strategy eventually does get pulled, the journal tells me whether I saw the deterioration early or whether I was blindsided. If I was blindsided, that is a gap in my monitoring framework, and I fix the framework before deploying the next strategy.

The journal also feeds the research loop. Patterns emerge over time. You notice that your trend-following strategies struggle in the same month each year. You notice that your mean reversion systems decay faster on instruments where microstructure has changed. These observations become hypotheses, and hypotheses become new filters, new sizing rules, or new strategies entirely.

The loop

Systematic trading is not "build a strategy and let it run forever." It is a cycle: research, build, test, deploy, monitor, review, and feed what you learn back into the next round of research.

The traders who survive long-term are the ones who treat every retired strategy as a lesson and every running strategy as provisional. Nothing is permanent. Edges erode. Markets shift. Your own understanding deepens. The process accounts for all of this, as long as you actually run the process.

For XAQP, every strategy has its thresholds written in before it goes live. The monitoring runs continuously. The journal updates monthly. When a strategy dies, I document why, archive the research, and move on. The portfolio improves because I keep removing what does not work and replacing it with what does.

That is the loop. It is not glamorous. It is the thing that compounds.

Thank you for reading

If you have made it this far, you have just worked through 24 chapters covering everything from what systematic trading actually is to deploying live strategies, managing capacity, and knowing when to pull the plug. That is a serious commitment of your time, and I appreciate it.

I wrote this handbook because I wish it had existed when I started. The information is out there, scattered across forums, textbooks, and YouTube channels of varying quality. Pulling it together into a single, honest walkthrough was the project I kept putting off until I realised nobody else was going to do it for me.

If even one chapter saved you from a mistake I made, or gave you a framework you can actually use, then the time I spent writing this was worth it.

A few things worth repeating as you go from here.

The process matters more than any single strategy. Strategies decay. The pipeline that produces them is what compounds. Build the loop, trust the loop, keep improving the loop.

Start small, stay honest. Demo first. Minimum size when you go live. Scale up only when the evidence supports it. The market will still be there next month.

The numbers do not care about your feelings. If a strategy fails the tests, it fails the tests. If a drawdown exceeds your thresholds, pull it. The discipline to act on what the data says, especially when it says something you do not want to hear, is the whole game.

I am still learning. XAQP is a live portfolio, and every month teaches me something I did not know the month before. If you want to follow the journey, the letters on this site are where I share what I am working on, what is going well, and what is not.

Good luck. Build something real.

Author: Kieran Duff

Last update: 15.06.2026