Iterative Backtesting

Iterative backtesting runs your strategy across multiple independent data segments rather than a single continuous pass. This approach produces statistically robust results, reveals how your strategy performs across different market conditions, and helps detect overfitting before you deploy real capital.

What Is Iterative Backtesting?

In a standard single-pass backtest, your strategy runs once across the entire selected date range. The result is a single set of performance metrics: one net profit figure, one win rate, one maximum drawdown. While useful, a single pass can obscure important nuances. A strategy might look profitable overall while performing terribly during specific market regimes.

Iterative backtesting addresses this by dividing your date range into multiple slices and running the strategy independently on each slice. Each iteration starts with a fresh portfolio state — the same initial balance, no open positions, and no carryover from previous slices. The engine then aggregates the results across all iterations to produce both individual slice metrics and overall statistical summaries.

How It Differs from Single-Pass

Aspect	Single-Pass	Iterative
Data handling	One continuous run	Multiple independent segments
Portfolio state	Carries through entire period	Resets at each iteration
Results	One set of metrics	Per-slice metrics + aggregate statistics
Overfitting detection	Limited	Strong (variance across slices)
Market regime analysis	Requires manual inspection	Built into the output
Computation time	Faster	Proportional to iteration count

Configuring Iteration Count and Slice Parameters

When setting up an iterative backtest, you configure two primary parameters:

Iteration Count

The number of independent runs to perform. Each iteration receives its own data segment. A higher iteration count produces more data points for statistical analysis but takes longer to compute.

// Example configuration
{
  "iterations": 50,
  "slice_mode": "rolling",
  "slice_duration": "3M",
  "overlap": "1M"
}

Slice Parameters

You can control how the date range is divided into segments:

• Slice duration — The length of each data segment (e.g., 1 month, 3 months, 6 months). Shorter slices produce more iterations from the same date range but each slice contains fewer trades.
• Slice mode — How slices are generated from the date range:
  • Sequential — Non-overlapping slices placed end to end. A 2-year range with 3-month slices produces 8 iterations.
  • Rolling — Overlapping slices that advance by a configurable step size. Produces more iterations from the same data range.
  • Random — Slices are sampled randomly from the date range, providing a Monte Carlo-style analysis of strategy performance.
• Overlap — For rolling mode, the amount of overlap between consecutive slices. More overlap produces more iterations but increases computation time.

When to Use More vs Fewer Iterations

The right number of iterations depends on what you are trying to accomplish:

Fewer Iterations (5-20)

Use fewer iterations during the early stages of strategy development when you are making frequent changes and need fast feedback. Fewer iterations process quickly, letting you iterate on your strategy design without waiting for long computation cycles.

• Rapid prototyping and rule testing
• Initial parameter exploration
• Quick sanity checks on strategy logic

Moderate Iterations (20-100)

Use a moderate count when your strategy design is mostly stable and you want to evaluate its statistical properties. This range provides enough data points to calculate meaningful averages, standard deviations, and confidence intervals.

• Evaluating strategy robustness
• Comparing strategy variants
• Assessing performance across market regimes

Many Iterations (100+)

Use a high iteration count for final validation before deployment. Large iteration counts provide tight confidence intervals and expose edge cases that might be missed with fewer runs.

• Final pre-deployment validation
• Monte Carlo risk analysis
• Regulatory or compliance reporting

Performance Implications and Plan Limits

Each iteration is an independent backtest run, so computation time scales linearly with the iteration count. A 50-iteration backtest takes roughly 50 times as long as a single-pass backtest on the same data.

To balance accessibility with computational demands, Arconomy applies iteration limits based on your plan:

Plan	Max Iterations per Backtest	Monthly Iteration Budget
Free	10	1,000
Paper	100	10,000
Live	500	50,000
Professional	Unlimited	Unlimited

Your current iteration usage is displayed on your dashboard. When you approach your monthly budget, you will receive a notification. If you hit the limit, backtests are restricted to single-pass mode until the budget resets at the start of the next billing cycle.

Interpreting Iterative Results

When an iterative backtest completes, the results panel displays both per-slice metrics and aggregate statistics:

• Per-slice breakdown — A table or chart showing key metrics (net profit, win rate, drawdown) for each individual iteration. Look for consistency across slices.
• Aggregate mean — The average of each metric across all iterations. This is your best estimate of expected performance.
• Standard deviation — How much each metric varies across iterations. High standard deviation indicates inconsistent performance.
• Worst slice — The iteration with the lowest net profit. This represents a realistic worst-case scenario for a single period.
• Best slice — The iteration with the highest net profit. Compare this to the average — if the best slice is dramatically better than the mean, the strategy may be inconsistent.

A robust strategy will show positive average metrics with low variance across slices. If most slices are profitable but a few are deeply negative, investigate what market conditions caused the losses and whether your risk management rules can handle them. For more on evaluating results, see Interpreting Results.