TradehouseBuyer guides & toolsPricingPart of TradeHouseTradeHouse Fidelity Lab · Buyer resources
What is walk forward validation?
Walk-forward validation is an out-of-sample testing method for models and trading rules built on time-ordered data. You fit on an earlier segment, test on the segment that immediately follows, then slide the boundary forward and repeat. Every test result comes from data that did not exist when the rule was fitted, which is the property a live deployment will also have.
How it differs from other validation schemes
| Scheme | How data is split | Main weakness for time series |
|---|---|---|
| Single holdout | One train period, one later test period | One test period is one draw; a lucky or unlucky stretch decides the verdict |
| Random k-fold | Rows shuffled into folds | Training on the future and testing on the past; leaks through autocorrelation |
| Blocked k-fold | Contiguous blocks, each held out in turn | Still trains on data after the test block |
| Walk-forward | Train on the past, test on the next block, slide forward | Uses less history for the first fold; needs enough independent trades per fold |
Two common variants
Rolling (fixed-length) windows keep the training length constant and drop the oldest data as the window slides. They suit markets where relationships drift. Anchored (expanding) windows keep the start date fixed and train on everything up to the test block. They suit relationships believed to be stable and give the optimiser more data later in the run.
Purging and embargo
If a label looks forward, for example the return over the next five days, then the last few training rows overlap with the first test rows. Purging deletes the overlapping training rows. An embargo adds a buffer after the test block. Both prevent training outcomes from silently containing test-period information.
Why quants prefer it
- It mirrors live use: you always trade with a rule fitted on the past.
- It produces many out-of-sample blocks, so you can see variation, not a single number.
- It exposes parameter instability, because re-fitting each fold shows whether the chosen values wander.
Pitfalls
- Peeking when choosing the design. If you picked window lengths after seeing which gave the best result, you have optimised the validation itself.
- Too little data per fold. A test block with a handful of trades is noise.
- Ignoring costs. A walk-forward that scores gross returns can pass a strategy that fees would erase.
- Ignoring selection. Walk-forward applied to the winner of many variants does not account for the other variants.
When it is the wrong tool
If the process is not time-dependent, for instance classifying images, random cross-validation is fine. If you have very short history, walk-forward leaves too little for the first fold, and you may need simulation or a longer sample rather than a cleverer split. And if the strategy trades rarely, you may not have enough independent trades in any block to say anything.
Fidelity Lab's version
Fidelity Lab runs a point-in-time walk-forward on the trade file you upload, with the threshold frozen on the training split, and reports test net return and a t-statistic alongside the number of effective independent days. If that number is too small for the effect size, it returns UNTESTABLE and names the binding constraint. The step-by-step schedule is on how walk-forward validation works.
Reporting a walk-forward honestly
State the window lengths, the gap, whether windows were anchored or rolling, the fee model, and how many designs you tried before choosing this one. Show every fold, not just the stitched curve. If you changed the design after seeing results, say so and treat the final design as one more trial. A walk-forward with these details can be checked by someone else; one without them is closer to marketing than to evidence.
Frequently asked questions
Is walk-forward the same as out-of-sample testing?
It is a repeated form of it. A single out-of-sample test is one fold; walk-forward chains many.
Do I need to re-fit in every fold?
Yes, if you intend to re-fit in live use. Otherwise you are testing a fixed rule, which is a different question.