Purged Cross-Validation and Embargo: Preventing Label Leakage in Trading Models

A cross-validation score estimates how a modeling procedure performs on observations kept out of a particular fit. Ordinary K-fold randomly partitions observations, fits on some folds, and scores the rest. That setup can be useful when the sampling and dependence assumptions are suitable. Financial data often needs closer treatment: neighboring returns can be dependent, and one forward-looking label can reuse prices that appear in another label.

Suppose a model predicts a five-session return at every daily decision. The label for Monday and the label for Tuesday share most of the same future price path. If one row goes into training and the other into testing, the model may be scored on an outcome closely related to one it has already seen. That can make a validation score look more informative than it is about genuinely unseen outcomes.

The issue is not that a random split is automatically invalid for every time series. The issue is whether the split matches the question and whether the training and test examples share information through their target intervals or through incorrectly constructed features. Advances in Financial Machine Learning, Chapter 7 discusses why ordinary K-fold can fail for overlapping financial labels and introduces purged folds.

For each sample, record its decision time t, the information available at that time, its feature window, and the interval used to calculate its target. If a daily model predicts a five-session forward return using prices available at the close of day t, its outcome interval can be written (t, t+5]; the label is not known until the end of that interval.

For event-based labels, the endpoint may vary. A barrier label, for example, resolves when its event condition is reached or its time limit expires. Store the actual start and end timestamps for each sample instead of assuming that every label lasts the same number of rows. A timestamp also needs a clear convention for whether a close, publication, or execution was available before or after the prediction was made.

Past observations can legitimately appear in feature windows for adjacent decisions. Shared trailing history is not automatically target leakage: a live model can use the same historical prices on consecutive days. Leakage occurs when a feature contains information that would not have been available at its prediction time, or when the validation design lets target information cross the test boundary. Build every feature from its true as-of information set.

After selecting a test fold, compare its target intervals with the intervals of every candidate training observation. Purge a training sample if its outcome interval overlaps the test outcomes under the chosen boundary convention. The test interval can be the union of several sample-specific intervals, so the rule should use actual timestamps rather than only the row positions of the test samples.

If all targets have a fixed horizon and observations are equally spaced, a row-count gap can sometimes approximate the required exclusion. That shortcut can fail for irregular trading calendars, missing bars, variable event horizons, or labels that resolve early. For event labels, compare the recorded resolution time directly; a fixed number of rows may be too short for one event and unnecessarily long for another.

Purging answers a specific question: which training targets overlap the outcomes used for this test? It does not require that all training rows precede the test rows. A purged K-fold split may still include observations from later dates, and it may still be exposed to feature leakage, data revisions, or model-selection bias. López de Prado’s chapter on cross-validation in finance covers the purged K-fold design in this context.

In a split design that allows training samples after a test block, an embargo excludes a specified set of observations immediately after the test interval from the training set. This buffer can reduce residual dependence caused by the way events, labels, or features are constructed around the boundary. It is applied in addition to checking actual label overlap; it is not a substitute for that check.

There is no universal embargo of a fixed percentage or number of sessions. Choose and document a width that reflects the sampling frequency, label horizon, feature construction, and dependence relevant to the model. A two-session embargo in one daily-bar example is an assumption for that example, not a recommendation for every market or label.

Do not equate embargo with every chronological gap. In a forward-only split, training ends before testing, so there are no later training rows after the test block to embargo. A pre-test gap may still be appropriate to keep training labels from extending into the test outcomes. Those are related protections, but they occupy different sides of the test interval and answer different implementation questions.

Assume decisions are made once per session and each target covers (t, t+5]. A test fold contains decision dates 11 through 15. The test labels collectively use outcomes through day 20. A candidate training label (7,12] overlaps the test interval from after day 11 through day 12, so purge it. The candidate label (16,21] also overlaps the test outcomes through day 20, so purge it as well.

A candidate label (21,26] does not overlap (11,20] under these endpoint assumptions. If later training rows are allowed, a researcher could separately exclude the first two post-test decisions as an illustrative embargo because the chosen feature construction or dependence analysis calls for a buffer. That choice must be justified in the study; label non-overlap alone neither mandates nor rules out an embargo.

The figure represents these operations separately: overlapping training outcomes are removed, and a small post-test buffer is shown as another rule. It is a conceptual timeline, not a universal row-count recipe. In production research, keep the interval convention consistent at session boundaries and verify every retained sample against the test interval.

The official scikit-learn TimeSeriesSplit documentation describes splits for time-ordered data, notes that samples should be equally spaced for comparable test durations, and defines gap as the number of samples excluded from the end of each training set before the test set. Use this convenience when its row-based structure matches the data. Irregular event labels need an interval-aware rule of their own.

If the question is “What would this process have known and done at each historical date?”, use an expanding or rolling walk-forward design. At every test step, only use information that would have existed before that step, and keep the training window, refit schedule, and label delay realistic. It is a closer simulation of a deployment path, though one historical path is still only one sample of possible regimes.

If the question is about model discrimination under dependence-corrected folds, purged K-fold can use data efficiently while removing overlapping outcomes. State clearly that training may include later dates, so the score is not a strict replay of a live historical deployment. López de Prado’s Chapter 12 on backtesting through cross-validation describes walk-forward and combinatorial purged cross-validation (CPCV). CPCV can create several train/test combinations and test paths from grouped data, but its extra paths should not be mistaken for independent market histories.

For regularly spaced observations with a fixed target horizon, TimeSeriesSplit(gap=...) may supply a clear chronological baseline. For variable event horizons, construct splits with each event’s actual start and resolution timestamps. A useful report can show more than one validation design if each answers a distinct question; do not pool their scores as if they were interchangeable.

A perfectly purged split still fails if a feature was calculated with a future close, a historical universe silently omits delisted assets, or revised economic data is treated as if it had been available at the original date. Normalizing, imputing, selecting features, or choosing thresholds on the full dataset also leaks information across the fold. Fit each learned preprocessing step only on that fold’s training data, then apply it to the held-out data.

Repeatedly testing indicators, universes, horizons, hyperparameters, and exit rules can select a lucky backtest even when each fold is purged. Bailey and coauthors’ paper on the probability of backtest overfitting explains why selection across many trials creates a separate problem. Use nested time-aware selection for model choices and keep a final chronological holdout untouched until the research process is fixed.

Finally, a predictive score is not a trading result. Include fees, spread, market impact, turnover, capacity, borrow or funding where applicable, and conservative fill assumptions. Inspect fold-by-fold results and uncertainty rather than presenting only the best split or a single mean. See the guides to financial-model overfitting, multiple testing and false discovery, and serial correlation in Sharpe ratios for related research risks.

Before scoring, publish the sample decision times, feature availability rules, target interval definition, and how variable labels resolve. Describe the test blocks, training dates, whether later observations may enter training, the overlap convention, and the rationale and size of any embargo. State the number of folds and test paths, the selection procedure, and when the final holdout is opened.

Keep the data vintage, asset universe, corporate-action and delisting treatment, preprocessing boundaries, execution costs, and refit schedule with the results. Report fold-level scores, dispersion, turnover, and any failures alongside the aggregate. A validation score is evidence about the specified data and procedure, not a guarantee that the strategy will work in live markets.