Přejít k obsahu | Přejít k hlavnímu menu | Přejít k vyhledávání
trading system validation
StrategyQuant X can generate a beautiful backtest in minutes. That’s the easy part. The harder part is figuring out whether the strategy discovered a real, exploitable pattern or a lucky fluke.
Then you have to account for spreads, slippage, broker settings, tick precision, execution differences, portfolio risk, and all the other boring details that tend to ruin beautiful backtests.
Brendan Anderson, founder of Trivium Systems Trading, has spent the past several years building a research process designed to tell those two apart. He currently manages a portfolio of more than 30 systematic strategies and maintains a public track record spanning more than two years and more than 10,000+ trades.
Here is how he approaches strategy development, validation, risk, and live deployment.
I’m a Vancouver-based systematic trader and the founder of Trivium Systems Trading.
I use StrategyQuant X to build intraday breakout systems and manage a portfolio of more than 30 strategies. I trade CFD markets: U.S., German, and Japanese indices, plus Bitcoin, gold, oil, and selected forex pairs. If something is liquid, produces useful breakout moves, and supports strategies that survive my testing process, I’m willing to trade it.
I also run Trivium SQX Academy, where I teach the same research and validation workflow I use for my own portfolio.
Most importantly, I maintain a public track record because I believe anyone teaching trading should be willing to show evidence that they’re actually successful.
I got interested in trading during the pandemic. Like a lot of people, I suddenly had way too much free time and found myself Googling how to make money online. That eventually led me to trading YouTube.
At the time, I knew absolutely nothing. That made me the ideal customer for someone who sounded confident, so I bought a course from a trader with no public track record. The course revolved around a giant Discord group where dozens of people would pile into whatever stock had been selected for the day. I opened a Webull demo account and started waking up at 6:00 a.m. to trade the U.S. market open from Vancouver.
My process was highly sophisticated:
During the meme-stock period, I shorted one of the stocks that was exploding upward. The position moved heavily against me, so I closed the app and went back to sleep, hoping the market would fix the problem while I was unconscious. Unfortunately, the trade wiped out the account and forced me to admit that I had no idea what I was doing. So I left the group and started looking for a process that gave me more confidence that I knew what I was doing.
I soon discovered TradingView and began backtesting strategies manually. This was better than blindly following Discord alerts, but it came with its own problems. For starters, a manual one-year backtest would take days. The process was full of manual bias, and it was impossible to account for spreads, commissions, slippage, and execution costs.
Eventually, I learned Pine Script and began coding strategies. Learning to code did not magically teach me how to conduct proper research, though. I would adjust parameters over and over until the equity curve looked almost perfect. I remember I created a moving-average strategy that looked incredible after enough fiddling. Then I ran it on unseen data, and the performance immediately fell apart.
That failure introduced me to overfitting, in-sample testing, out-of-sample testing, and the many ways a trader can accidentally produce something that looks great on paper.
After testing more than 100 ideas, I found a night-scalping strategy that placed limit orders around a defined range during the forex rollover period. I traded it successfully for a few years and grew the account considerably. The problem was that I still had little understanding of what I was actually risking, of diversification, or of what I would do when the strategy stopped working. Which eventually happened, and suddenly I was back at square one.
The lesson was pretty clear: relying on one strategy was a terrible long-term plan. I needed a way to generate, test, and combine many independent systems. That led me back to StrategyQuant X.
I first downloaded StrategyQuant X in 2021, while I was still coding strategies manually.
I opened the software, clicked Generate without setting up a proper workflow, received a bunch of mediocre results, and dismissed the platform. In hindsight, this was like opening Photoshop, clicking three random buttons, producing an ugly image, and deciding graphic design must be a scam.
I returned to SQX in 2023 after learning much more about systematic research. By then I understood overfitting, validation, and the difference between finding a backtest and building a process. That changed everything.
I came to appreciate the main reason SQX is so powerful: the genetic builder can test hundreds of thousands of strategy combinations, including ideas I would never have considered manually. On top of that, it lets you create an automated research pipeline where strategies can be generated, filtered, pushed through robustness tests, and then exported as complete trading code.
So I invested in a course produced by a well-known StrategyQuant X fund at the time (they’re not around anymore) and spent hundreds of hours learning how to use the software properly.
StrategyQuant X gives you an absurd number of settings, indicators, filters, tests, and possible workflows. That flexibility is powerful once you know what you’re doing, but before that, it mostly gives you more ways to make mistakes.
My first major technical problem was setting up the data correctly. CFD brokers differ in contract specifications, spreads, commissions, time zones, point values, and position-sizing rules. A strategy built using the default Dukascopy configuration may behave very differently when deployed through a specific broker.
After much trial and error, I learned I had to pull the CFD contract specifications directly from my MetaTrader terminal, which includes:
In hindsight, yes, these things seem obvious. But this just goes to show how little I knew, and how eager I was to start cranking out strategies before I set the foundation properly. Garbage in, garbage out.
On markets with a strong upward bias, such as U.S. indices, I begin with long-only strategies. Sailing in the direction of the wind is far easier than fighting it. Later, I’ll generate symmetrical long-short systems.
My default timeframe is M30. Lower timeframes are more vulnerable to spreads, slippage, broker differences, and intrabar price sequencing. Higher timeframes usually produce fewer trades than I want, and the risk-to-reward profile is less attractive for my approach. M30 sits in the middle of both problems.
My strategies are all intraday breakout systems that enter via stop orders at defined price levels and close before the end of the trading day.
Once generated, candidates move through three separate out-of-sample stages. The first is the out-of-sample segment inside the Builder, which the genetic algorithm does see during selection. The remaining two stages are what I deem “true out-of-sample” data, which do not influence the optimization process (the strategies either pass or fail here). These stages feature blocks of history withheld from the Builder entirely, so nothing about it influences which strategies survive.
After that comes multimarket testing. Here, I test each strategy across a broad group of instruments, and I only accept strategies above a certain median performance threshold across all markets. To me, a strategy that performs decently across several markets is more likely to reflect a general price pattern, and it’s harder for that result to have come from random chance. A strategy that works only on one symbol, during one period, with one exact set of parameters may simply have gotten lucky. Multimarket testing also expands the sample size. I have far more confidence in a strategy with 50,000 trades (the vast majority of which are out-of-sample) across multiple markets than one with 500 trades in a single market.
Next, I run Monte Carlo tests, including:
I also retest on tick data to make sure performance holds up, because my original builds use one-minute resolution.
Once I have roughly 100 to 200 viable strategies for a market, I use the portfolio builder to remove highly correlated systems. The goal is to build a collection of strategies whose return streams behave differently enough to improve the portfolio’s return for a given level of risk.
Finally, I export the portfolio trades to Excel, estimate drawdown through Monte Carlo analysis, determine the risk per trade, export the code, and compare the strategy in MetaTrader against broker-specific data.
A parameter is any value that can be adjusted. Many popular trading indicators feature a variety of parameters. The RSI, for example, has three: the lookback period plus the overbought and oversold levels.
I’ve disabled most of the heavily parameterized signal blocks in StrategyQuant X, which accounts for the majority of them. Through repeated testing, I found that these indicators struggled to survive my validation process, so rather than keep spending compute on them, I removed them from the builder phase entirely.
The reason comes down to search space: the total number of possible signal configurations StrategyQuant X can test. Two things contribute to this:
The larger the search space, the more opportunities the builder has to find combinations that happen to look good by sheer chance rather than finding a genuine, exploitable pattern.
An indicator with three parameters may look simple, but if each parameter has 100 possible values, that’s 100³, or 1,000,000 possible combinations. This is why I prefer simple conditions with few or no optimized values, the so-called low-parameter or zero-parameter signals.
People ask me for examples all the time, but they really are just this braindead simple:
These are mostly binary conditions, true or false, and the values are fixed. There is nothing to optimize, so if a given signal doesn’t yield a tradeable edge, it gets discarded. In my testing, these signals survive robustness filters more frequently and generalize better across markets. I’ve now developed close to 100 custom price-pattern blocks around this philosophy.
For breakout and trend-following research, I consider the NASDAQ and other stock indices easier starting points than major forex pairs.
They offer:
Bitcoin and gold are strong candidates for the same reasons. The only FX pair I recommend trading breakouts on, and the only one I’ve had success with, is USDJPY. The other majors spend more of their time ranging, and the breakouts that do occur tend not to follow through far enough to justify the costs.
All my systems use:
Profit targets are set to “optional” in the Builder, meaning the algorithm can include one or leave it out, and in practice most of my strategies end up without one. This lets large intraday moves keep running instead of getting cut off at an arbitrary level.
When you set up the data in SQX, you have to specify the spread and slippage. Unfortunately, it applies that same value across the entire data range.
Because of this, a common mistake is applying today’s spread to an entire historical build period. Gold is a good example—its nominal price in 2003, the earliest data you can get from Dukascopy, was far lower than it is today. Applying the current absolute spread to older price history makes the cost unrealistically large in percentage terms.
This can make viable historical strategies appear unprofitable simply because the cost assumptions don’t match the period being tested. To address this, I compare the current market price with the price at the start of the build window, then use that ratio to scale the historical spread backward. This gives me a lower spread estimate for the older portion of the data.
Later, I test the strategy using modern spread assumptions and reasonable slippage on the past few years of data to confirm the strategy doesn’t collapse once current costs are taken into account.
At the end of the day, out-of-sample testing is king. Every additional out-of-sample trade is a vote of confidence that you may have an edge. Ten out-of-sample trades could be a fluke—ten thousand starts to paint a statistically meaningful picture.
People often ask how much data to reserve for out-of-sample testing. I frequently set aside half, and sometimes more, across the entire workflow. Genetic evolution searches through an enormous number of strategy combinations and repeatedly rewards whatever performs best on the development data. That makes it highly effective at discovering strategies, but equally effective at fitting to historical noise. A large untouched sample counterbalances that selection pressure and forces the final strategy to prove itself on data that played no role in its creation.
Which brings me to the most common error I see. In StrategyQuant X, marking part of the Builder data as out-of-sample does not leave it untouched when genetic evolution is enabled.
Strategies are created on the in-sample period, then evaluated on the out-of-sample segment. The problem is that this evaluation isn’t passive. The genetic algorithm uses performance on both segments to decide which strategies are kept, modified, or discarded. Over many generations, the strategies that happen to perform well on the out-of-sample portion are the ones that survive and pass on their characteristics to the next generation. The algorithm is learning from that data indirectly, using it as a selection filter rather than as a set of parameters to optimize, but the effect is similar. That segment becomes a secondary optimization target, and the more generations you run, the more it compounds.
The data still has value. It reduces overfitting compared with using in-sample data alone. But it isn’t a final, unbiased test of robustness.
That’s why I reserve an additional block of history that the Builder never sees at any stage for true out-of-sample testing. Because it stays untouched, it works as a genuinely independent benchmark. Testing there once the entire generation and selection process is finished gives a much more reliable indication of how a strategy might perform live. If it holds up on truly unseen data, the edge is more likely to generalize beyond the specific patterns present during evolution.
Many of my best signals begin with simple observations about price behavior.
For example: did the previous day close higher or lower? Did price break above yesterday’s range? Did the market reverse after making an unusually large move? These observations are easy to describe, easy to code, and contain fewer adjustable values than traditional indicators.
I also study ideas from other systematic traders, StrategyQuant community articles, academic research, and established trading literature. Larry Williams’s work, for example, introduced me to price patterns such as the Smash Day and the Kangaroo Tail, which feature in a lot of my systems.
My goal is not to find a few extraordinary strategies. It’s to build a portfolio of relatively “mediocre” strategies that produce modest returns, behave differently from one another, and combine into a much smoother equity curve.
Many profitable systems that pass all my robustness tests experience long stagnation periods—sometimes several years of flat performance. That can make an individual strategy extremely difficult to trade, even when its results remain within the range suggested by its historical backtest.
The solution is diversification across uncorrelated return streams. When one group of strategies is flat or losing, another group may be generating profits. Each strategy contributes a small and imperfect piece, but together they can produce a more stable and dependable equity path.
I measure correlation using each strategy’s monthly profit and loss. You can’t assume that two strategies are correlated simply because they trade related instruments. Two systems trading the same U.S. index could still produce very different return streams, because their entry conditions, exits, trade direction, timing, and holding periods differ. Correlation has to be measured from the actual returns.
Even with a strong development and validation process, some strategies will disappoint after deployment. No amount of historical testing lets you know in advance which strategies will become the future winners. A broad, low-correlation portfolio reduces dependence on any single outcome, since the strategies that keep working can offset those that flatten out or fail.
I set risk at the portfolio level rather than sizing each strategy in isolation.
A common mistake is to base position sizing on the single maximum drawdown shown in a historical backtest. This is the core problem: a backtest gives you one realization of many possible outcomes. It doesn’t tell you how bad things could get if the same distribution of returns unfolds in a less favorable order. Markets don’t guarantee that the future will resemble the past sequence of trades; they only suggest that the statistical properties of that distribution may persist.
To address this, I export the complete portfolio trade list to Excel and run Monte Carlo simulations using block bootstrapping. I use block bootstrapping instead of simple random resampling because trades aren’t independent. This is because strategies often exhibit clustering: periods where they perform well and periods where they struggle. Standard resampling breaks this structure and can underestimate risk by smoothing out the streaks. Block bootstrapping preserves the clusters, producing more realistic sequences that better reflect how drawdowns develop in practice.
The simulations generate thousands of plausible equity curves. Instead of a single drawdown number, I get a distribution of drawdowns. That shows me not just what happened, but what could reasonably happen under adverse conditions, and it lets me estimate how severe a drawdown might become under an unusually poor but still statistically plausible sequence of returns.
Your first task should be to identify where the drawdown is coming from.
The portfolio may simply be experiencing ordinary variance. Just because your portfolio or certain strategies are in a drawdown doesn’t mean they’re “broken”. As long as it’s within your predictions, you just need to wait it out.
That said, if you notice an unusual pattern of steep drawdowns, that’s cause for deeper investigation. Say the portfolio has drawn down 10% three times in the past six months, but your Monte Carlo simulations suggest that should only happen once or twice a year. Something is worth looking into.
A backtest may show that a strategy should be up 2% while the live version is down 5%. That kind of mismatch suggests an execution problem. Compare your trades immediately and find where the issue is coming from. Are there:
Backtests, done right, are the best tool we have for predicting future performance. When they’re no longer reliable, your foundation is gone.
The live equity curve may have a similar shape to the backtest but perform worse because spreads, commissions, or slippage are higher than expected. In that case, the historical cost assumptions need updating, and you’ll have to rerun everything through your workflow again.
Don’t panic and remove strategies simply because the portfolio enters a drawdown. Identify the source of the drawdown and take the appropriate steps.
I learned this through live experience. For a while, I only tested on M1-resolution data, because the average trade duration for my strategies was a few hours. I didn’t think tick data was necessary. Then I ran into execution discrepancies, and when I retested using tick data, the performance for some strategies deteriorated sharply.
The difference is as follows:
Crucially, M1 data doesn’t tell you which price occurred first. That could matter because:
Sometimes the performance between M1 vs. tick data is almost identical, and sometimes it’s dramatically different. I haven’t yet found a way to predict this.
At the end of the day, I may not always know exactly why a strategy’s performance degrades so much on tick data compared with M1, but I don’t always need to know. When the degradation is large, I throw the strategy away without a second thought. Since SQX makes strategy generation trivial, I can always find hundreds of replacement candidates ready to swap in.
I don’t have a fixed cutoff for individual strategies, because I manage the portfolio as a single unit. I set an extremely pessimistic max drawdown threshold for the entire portfolio, and I monitor individual strategies mainly to confirm they’re behaving the way their backtests said they would. Whether a given strategy is up or down matters less to me than whether its results still fall inside the range my simulations predicted.
To answer the question more directly: some degradation from in-sample to out-of-sample performance is inevitable and expected. On my YouTube channel, I ran a public experiment where I generated random strategies without applying robustness tests. Tested on out-of-sample data, they showed a substantial drop in average performance as measured by the Sharpe ratio—around 40% to 50% from in-sample to out-of-sample.
With proper robustness testing, the degradation improved significantly, though it was never eliminated completely. Multimarket testing, which is itself a form of out-of-sample testing, was one of the strongest filters.
That’s the best we can hope for: reducing the potential for degradation across the portfolio and improving the odds that enough strategies keep performing.
This is where my approach diverges from a lot of the advice you’ll hear from trading educators.
To repeat myself, you have to accept that a strategy not performing doesn’t mean it’s “broken”. If you constantly eliminate strategies that look broken, you may be eliminating them right before they start to rebound. Losing periods cluster, and so do winning ones. The problem is that you don’t know when one will turn into the other. So the best thing you can do is avoid putting your eggs in one basket and spread risk across a portfolio of strategies.
At the risk of sounding like a broken record: because the portfolio was built and sized as a group, portfolio drawdown remains my main risk metric. I monitor individual systems only for execution integrity, checking whether the trades match the backtests.
Every three to four months I refresh the portfolio. I rerun the existing strategy databanks through the same filters and treat the newest data as additional out-of-sample evidence. Then I keep the survivors and rebuild the portfolio from the updated pool. This tests both whether the strategies hold up and whether my workflow itself is robust.
SQX’s genetic evolution is itself a form of machine learning, so in that sense AI has been central to my process from the start. Beyond that, I use LLMs for fixing code and analyzing exported trade data.
I want to caution that most of what people do with AI in trading is overrated. One key mistake is using various machine learning techniques to generate buy and sell signals by training it on whatever features you feed it. Another is going to ChatGPT and asking it “give me a profitable trading strategy”. The problem here is that an LLM is built to satisfy you. Ask it for a strategy that looks good on paper and it will hand you a strategy that looks good on paper, because that’s what you asked for. It’s only as good as the operator.
There’s no shortcut around building a process and learning enough to evaluate what comes out of it. AI can speed up the mechanical parts of that work. It can’t do the judgment for you.
Systematic traders should understand basic statistics and data science concepts. Some examples include but aren’t limited to:
Without these foundations, it’s difficult to judge the strength of your evidence or decide which research choices make sense. A basic statistical foundation also lets you conduct your own research to see what works, which SQX makes incredibly easy. That’s far more useful than asking someone for the “best settings”. There is no collection of magic settings hidden in a private Discord.
Trivium SQX Academy is designed for traders who already understand the basics of StrategyQuant X and want to take it seriously without spending thousands of hours assembling a complete process through trial and error.
Inside, I share:
There is also a private community of like-minded SQX algorithmic traders.
If I had to summarize my approach:
With SQX, generating strategies is the easy part. Building a process that knows which ones to reject is where most of the work happens.
A smooth equity curve can be deceptive. Your portfolio may look stable, but if all your strategies enter trades, lose money, and recover at the same time, you’re not truly …
Tomas Vanek3. 8. 2026
The SQX Authoring Toolkit from the July article is now an installable Claude Code plugin. Four AI skills — custom blocks, random groups, strategy templates, build projects — each derived from your own StrategyQuant install and validated before import. Free in the Codebase, with one-command setup and a built-in health check.
clonex / Ivan Hudec3. 8. 2026
Every trader has experienced it. You tweak one parameter, run a backtest, make another change, and after ten iterations you can no longer remember which modification actually improved your strategy. …
Tomas Vanek27. 7. 2026
Spanish
Portuguese
French
Italian
German