How Many Trades Do You Need to Test a Strategy?

There's no universal number of trades that proves a strategy works. How many you need depends on how big the edge is compared with how much single trades vary, whether trades are independent of each other, and what question you're asking: a code error can show up on the first trade, while telling a small edge from zero can take hundreds. What you can do is measure how uncertain your numbers still are, and decide before you start when you'll review and what would make you stop.

This page gives you the arithmetic for both, and the review plan we'd write before trading anything.

Is there a minimum number of trades to test a strategy?

Not one that holds for every strategy. You'll see round numbers quoted as rules of thumb, but the trade count is only one input. Our backtest vs live comparison puts it this way: use the amount and quality of evidence, not a single calendar or trade-count threshold. How much uncertainty remains depends on the outcome distribution, dependence between trades and the size of the effect you're trying to see.

The finance literature says the same thing more formally. Bailey and López de Prado's Sharpe ratio efficient frontier (Journal of Risk, 2012; checked 2026-10-11) derives the track-record length needed to reject the idea that a measured Sharpe ratio is below a threshold. The answer moves with the threshold, the confidence you want and the shape of the returns: negative skew and fat tails demand a longer record.

Three questions decide the count in practice:

1. What are you trying to detect? A broken order routine shows itself immediately. An edge of a fifth of a risk unit per trade does not.
2. How much do single trades vary? A system that wins and loses similar amounts settles faster than one carried by a few big winners.
3. Are the trades independent? Five trades on correlated pairs in the same hour are closer to one observation than five.

How uncertain is a win rate after 15, 30, 50, 100, 200 or 300 trades?

Take an illustrative system that wins 50% of its trades. This is how much that number can still be off after each sample size.

Method: binomial standard error at a 50% win rate, and the 95% Wilson score interval for an observed 50% win rate, using the formula in the NIST/SEMATECH e-Handbook of Statistical Methods (checked 2026-10-11).

How to read it: if you've seen a 50% win rate over 30 trades, the true win rate could reasonably be anywhere from about a third to about two thirds. Over 300 trades the range narrows to 44.4% to 55.6%, still more than eleven points wide.

The width shrinks with the square root of the sample, so halving it takes four times the trades. The same script finds that a 50% win rate needs 93 trades before its 95% interval is within ±10 points, and 381 trades for ±5 points.

Why Wilson and not the textbook "p ± 1.96 standard errors"? Brown, Cai and DasGupta's review of binomial intervals (Statistical Science, 2001; checked 2026-10-11) found the simple version's coverage erratic, and recommends "the Wilson interval or the equal-tailed Jeffreys prior interval for small n", and NIST cites the same recommendation.

One detail at N = 15: a 50% win rate isn't a whole number of wins (7.5), so that row applies the formula at exactly 50% to keep the rows comparable. With real counts, 7 wins of 15 gives 24.8% to 69.9%, and 8 of 15 gives 30.1% to 75.2%.

These intervals assume every trade is independent and the true win rate never changes. Real trades cluster in streaks and markets change, which usually makes the real uncertainty larger, not smaller.

Why isn't win rate enough to judge a strategy?

Because a win rate says how often you win, not how much. What pays is expectancy: the average result per trade in R, after costs. And expectancy is harder to pin down, because it moves with the size of every win and loss.

Take the default inputs of our trading expectancy calculator: 45% wins, winners of 1.8R, losers of 1R and costs of 0.05R a trade. That's an expectancy of +0.21R a trade. Model it as two outcomes, every win netting +1.75R and every loss −1.05R, with independent trades. Each trade then has a standard deviation of 1.39R, more than six times the edge.

Method: 95% interval for expectancy = mean ± 1.96 × standard deviation ÷ √N, computed by the same script before rounding.

For this illustrative system, the interval first excludes zero at 170 trades. Keep the same +0.21R edge but double the spread of outcomes to 2.79R a trade, as a system with rarer, larger winners might have, and it takes 677 trades.

That's the core of the answer. The trade count you need grows with (spread ÷ edge)². A thin edge with lumpy outcomes needs far more trades than a fat edge with steady ones, and no single number covers both. Put your own numbers into the calculator, then ask how much they could move.

What else changes how many trades you need?

Market coverage. Three hundred trades from one quiet month test the strategy in one kind of market. The same count spread across trending, ranging and volatile periods says more. Plan reviews on both trade count and calendar time.

Correlation. If the strategy opens several positions on related markets at once, count the decisions, not the tickets.

Costs. A cost model that's 0.1R a trade too optimistic would cut an edge of +0.21R roughly in half. Compare live costs per trade with the backtest's model early.

Where the trades come from. Backtest trades are cheap and plentiful, but they carry the test's own assumptions and can carry its leaks. Before counting them, check the test for look-ahead bias, and keep a later stretch of data out of development, as walk-forward testing does.

How do you set review points before you start?

Write them down before the first trade, while you have no results to argue with. A review point is a date or trade count at which you'll compare results with what you expected. It isn't a moment to react to a feeling.

Separate two kinds of check:

• Operational checks, from day one. Are orders, stops and sizes what the rules say? Are costs per trade close to the model? These don't need a large sample, and a failure means stop and fix.
• Performance reviews, at fixed points. Is expectancy, with its uncertainty, consistent with the backtest? These need the sample you chose from the tables above.

A one-page plan is enough:

Strategy and version: ________   Start date: ________
Full performance review at: ___ trades AND at least ___ months,
  whichever comes later
Operational checks every ___ trades:
  - orders, stops and sizes match the rules
  - cost per trade vs the backtest's model
  - risk per trade within the limit
Compare against: backtest expectancy ___R, with its interval
Kill criteria (any one stops new trades and starts a review):
  1. A risk limit breached, a wrong order or a code error: stop now
  2. Drawdown beyond ___% (set from the backtest and a simulation)
  3. Live cost per trade above ___R
  4. At the full review, the expectancy interval lies wholly below ___R

What should your kill criteria be?

Kill criteria are the conditions that stop new trades and trigger a review. Set them before the drawdown, from evidence, so the decision doesn't get made in the middle of one.

Operational failures stop trading at once. Don't wait for a sample to investigate a breached risk limit, a wrong order or an implementation error. One is enough.

A drawdown limit. Look at the backtest's worst drawdown and longest flat stretch, then run your win rate, payoff and risk through the Monte Carlo simulator to see how much deeper paths on the same assumptions can go. A backtest is one path, so a deeper live drawdown isn't proof that something broke. But a limit you set in advance turns "this feels bad" into "the line was crossed, so we review". The simulator generates synthetic paths from your inputs; it doesn't reshuffle your real trades, and no percentile is a ceiling on losses. Our drawdown recovery guide covers what a deep drawdown costs to climb out of.

A cost limit. If live costs per trade run well above what the backtest charged, the tested edge may not exist at your broker.

A performance floor at the full review. If, at the review point you chose, the expectancy interval sits wholly below the level you needed, the evidence has spoken. Above zero but below the backtest is a different case: compare rules, costs and market conditions before deciding.

A review can end three ways: continue, fix and restart the count, or retire the system. Write down which result leads to which.

Is strategy hopping just a sample-size problem?

Mostly, yes. Trading a strategy for 15 trades and quitting after a bad run judges it on a sample where an observed 50% win rate fits anything from 27.4% to 72.6%. A good system and a bad one look alike at that size, and every switch resets the count to zero.

The usual timing makes it worse. When a strategy gets adopted after a strong run and dropped during a drawdown, the hopper keeps sampling the worst stretch of each one and never reaches the sample where the edge, if there is one, shows.

The opposite mistake is holding a broken system because "it needs more time". Pre-committed review points and kill criteria fix both: you stay through drawdowns inside the limits you set, and you leave when a criterion is met, not when a feeling is.

Disclosure

We sell TradeLens, a trading journal that computes expectancy in R from your trade history, and other trading tools. Every number on this page is arithmetic about hypothetical systems, not a result of any strategy, ours included. A large sample reduces the chance that luck fooled you; it doesn't remove it, and past results don't predict future ones. Nothing here is financial advice.