Expanding vs Rolling Windows for Walk-Forward Model Validation

At a forecast origin, a researcher knows some historical features and outcomes, fits or updates a model, and evaluates it on a later block. Moving that origin forward creates successive out-of-sample periods. The training-window rule answers which eligible past rows are used at a given refit. The validation and test rules answer which later outcomes are used to compare choices and estimate performance. These are related decisions, but they are not the same window.

An expanding rule starts at a fixed historical boundary and grows as new outcomes become available. A rolling rule moves both ends forward while holding the training sample count fixed after its warm-up. In either case, a model cannot use a target that had not finished by the forecast origin. If labels span several sessions, the row date alone may not show when the target became knowable; store the label end time and enforce it.

Also separate the model's feature lookback from its training window. A signal may use a trailing volatility estimate to form each row while the fitted model uses many years of rows. Changing that feature lookback changes the predictors; changing the training window changes the observations used to estimate the model. Conflating them makes it hard to explain what an expanding-versus-rolling comparison actually tests.

Let the first eligible training observation be at index \(s\), and let \(t\) be the latest observation whose label is fully known at a refit. The expanding training set is \(\{s, s+1, \ldots, t\}\). At the next origin, it retains that set and appends newly eligible observations. Its size therefore grows over time unless the data itself is filtered or removed by a separate rule.

Keeping more observations can reduce the sampling noise of estimated parameters when older data still describes the process being modeled. It can preserve infrequent market conditions that a short recent sample may omit, and it avoids choosing a hard historical cutoff. It may also be practical when the fitting procedure benefits from more rows or when the model is intended to represent a stable long-run relationship.

The cost is that old observations never lose influence merely because they are old. If the relationship between predictors and returns changes, early data can pull estimates toward conditions that no longer resemble the current market. Large training sets can also make repeated refits slower. Expanding history is not automatically more representative: it is useful only to the extent that its older observations remain relevant to the stated target.

For a fixed window length \(W\), a rolling training set at origin \(t\) is \(\{t-W+1, \ldots, t\}\), after allowing for any label delay or boundary gap. At the next origin, the end advances and the oldest eligible row falls out. The window length can be expressed in observations, calendar time, or another justified unit, but those choices are not interchangeable when the data is irregular.

A rolling window gives the estimator a recency rule: every retained observation falls within the selected span, while earlier rows stop directly entering the fit. That can be useful when the research question concerns adaptation to changing conditions or when a fixed fitting size is operationally important. It does not make the model automatically adaptive. If refits are infrequent, features are stale, or the underlying change is gradual, a recent-only sample may still respond slowly.

The tradeoff is less information for estimation. A shorter span may make coefficients or feature rankings unstable, omit rare but relevant stress periods, or leave too few examples for a complex model. A longer span retains more varied history but may dilute recent patterns. Choosing \(W\) after inspecting the final test period simply transfers the selection problem into the window rule; it does not turn that period back into an independent test.

The comparison only isolates a window policy if other choices are held constant: same information cutoff, features, model class, training objective, refit dates, forecast horizon, test blocks, and execution assumptions. If the rolling model is also retrained more often, uses different predictors, or receives a different regularization setting, a score difference cannot be attributed to the window alone.

Neither method is the same thing as choosing a forecast origin. Both expanding and rolling training windows can be evaluated with rolling origins: train on eligible past data, forecast the next block, move forward, and repeat. Leonard Tashman's review of out-of-sample forecasting tests00065-0) discusses these implementation choices, including rolling origins and rolling estimation windows. The terms sound similar because both move through time, but one describes when evaluation occurs and the other describes which training observations remain.

All counts and dates in this example are hypothetical. Suppose a model is refit monthly, its target is the next month's return, and the first fit uses the 60 eligible observations ending at month 120. The label for a row is usable only after its outcome has completed. At the first forecast origin, an expanding fit uses the initial 60 rows; a rolling fit with a 60-row span uses the same rows, so the two procedures start alike.

After one new monthly outcome has become known, the expanding fit contains 61 eligible rows, while the rolling fit still contains 60: it adds the new row and drops the oldest one. After 12 such updates, the expanding fit contains 72 rows from the original start, while the rolling fit still contains the latest 60. The two models may now estimate different parameters because they saw different histories, even though every row used by either fit was available at its refit date.

Now reserve the final 24 months as an outer test period in this hypothetical design. The training-window choice, its span, feature definitions, and other model settings must be selected using earlier chronological validation periods. The outer test then evaluates the frozen selection through the predeclared refit schedule. Repeatedly changing the span after seeing outer-test results uses those results for selection and overstates what the final period can tell you.

Write down the question before comparing windows. Is the model meant to use the full history available at each refit, or is there a research reason to let older examples leave the fit? Is the target relationship expected to be stable, or could its relevant inputs change? These questions guide candidates; they do not establish in advance which will perform better in a particular market.

Use earlier development data to compare a small, prespecified set of choices: expanding history and a few plausible rolling spans, for example. Evaluate each on the same chronological validation blocks and with the same refit cadence. Choose the objective before scoring; prediction loss, calibration, turnover-aware portfolio utility, and drawdown answer different questions. If the research compares portfolio results, include realistic costs and constraints without changing them between candidates. Record failed fits and missing forecasts too; silently dropping difficult folds can make one window look easier to use than another. When targets or test blocks overlap, adjacent scores may share returns, so describe that dependence instead of counting each row as an independent experiment.

Keep a later chronological period untouched for the final check. In a nested design, the inner validation selects the window and other settings using only data available before each outer test block; the outer results estimate the full selection procedure. A single holdout repeatedly queried during tuning is no longer untouched. The purged cross-validation guide explains label-overlap boundaries, while financial model overfitting and multiple testing cover related selection risks.

At each origin, use only features and target labels that would have been known then. For a multi-session forward return, a training row near the validation boundary may still have an unfinished outcome even if its decision timestamp is earlier. Leave a gap or purge rows according to actual label intervals when required; a fixed row count is only a suitable shortcut when the observation spacing and outcome horizon justify it. No training-window rule repairs a feature that contains future information.

Fit imputation, scaling, feature selection, and other learned preprocessing using only that fold’s training period. If a signal threshold or hyperparameter must be selected, use a nested chronological split inside the training period, then freeze that choice when scoring the later validation block. Predeclare the inner-validation procedure and use the same selection rule at the final test origins.

The official scikit-learn TimeSeriesSplit documentation describes an expanding training set by default and offers max_train_size to limit the size of a training set. Its gap is a count of samples, and comparable fold durations assume equally spaced samples. These implementation details are useful checks, not a substitute for aligning timestamped financial labels or verifying the version and behavior used in a study.

Report the window rule and exact span, earliest retained date, number of eligible rows at each refit, label-availability convention, validation and final-test dates, forecast horizon, and refit schedule. Show results by test block as well as an aggregate. A mean can conceal that one market episode drives the comparison, while repeated adjacent forecasts may share outcomes and therefore are not independent evidence.

For trading applications, forecast accuracy is not net trading performance. Position construction, leverage, turnover, liquidity, fees, spread, market impact, borrow, funding, and execution timing all affect realized results. Hold these assumptions fixed when comparing window rules, and state when an evaluation omits them. Cerqueira, Torgo, and Mozetič's study of time-series performance-estimation methods reports that estimates can differ across stationary and nonstationary settings; this supports checking more than one plausible design, not a universal claim that rolling or expanding windows win.

Finally, treat each backtest as evidence about a specified history and process. An expanding window can retain data from an obsolete regime; a rolling window can discard useful evidence and become noisy. A chosen rule may fail under a different regime, instrument universe, or cost environment. Validation narrows uncertainty about the tested procedure, but it cannot promise a future return or prove that either window is optimal.