Walk-forward analysis explained

How it works

1. 01Fit and refine the strategy on an initial window — say months one to six.
2. 02Test it, unchanged, on the window immediately following — month seven.
3. 03Roll both windows forward by one period and repeat.
4. 04Concatenate every test period into a single equity curve.

Because every point on that curve came from a period the strategy had not seen when its parameters were set, the whole curve is out-of-sample. That is a far stronger claim than a single held-out period, and much stronger than an optimised backtest.

What it reveals that a single split does not

It answers whether the strategy needs reoptimising to keep working and how quickly its parameters go stale. A system that performs well only when refitted every month is describing a moving target, and that is a warning regardless of how good the concatenated curve looks.

It also exposes parameter instability. If the optimal setting jumps around between windows, the strategy is fitting noise even when the aggregate result is positive — which is the most common way overfitting survives a naive test.

The limitation nobody mentions

Walk-forward is data-hungry. Each window consumes history, and a low-frequency strategy produces very few trades per window. A system averaging ten trades a month generates roughly ten observations per monthly test window, which is far too few for the individual results to mean anything.

This is a real constraint for our own strategy rather than a hypothetical one, and pretending otherwise would misrepresent what the method can deliver here. It is why our published figures lean on a single large out-of-sample period alongside walk-forward rather than on walk-forward alone — see sample size.

How we run it

Our replay engine feeds real broker bars through the same signal code the live engine runs, with the real performance tracker driving strategy selection. There is no separate backtest implementation, which removes an entire category of invisible divergence between test and live behaviour.

Persistence is hard-disabled during replay so a test cannot contaminate live state, and the full gate chain — session, spread, bias, concurrency — is applied exactly as it is live. See backtest does not match live results for the gaps that remain.