Purged Cross Validation

Purged cross validation is a time-aware validation method that removes training observations whose information intervals overlap the test observations. It is used mainly in financial machine learning, where a label created at one timestamp may depend on prices observed minutes, days, or weeks later. By separating events rather than merely separating rows, the method gives a cleaner estimate of how a trading model may behave on unseen data.

That distinction matters. A normal train-test split can look separate on a spreadsheet while still sharing market information underneath. The result is leakage: the model appears sharper than it really is, and the error often shows up only after deployment.

Why Ordinary K-Fold Validation Can Leak

Standard K-fold cross-validation assumes observations are independent enough to move between folds. Financial samples often break that assumption. Suppose a signal is recorded at time t0, but its label is decided at time t1 after a stop, profit target, or fixed holding period is reached. Any training event spanning the same market interval as a test event can contain part of the answer.

Serial correlation makes the boundary even fuzzier. Adjacent bars may share volatility, order-flow conditions, rolling indicators, and overlapping return horizons. Random shuffling is therefore especially risky, but blocked chronological folds can still leak when label windows cross the fold edge.

How Purging Removes Overlapping Events

Purging compares each training event's information interval with the test interval. If the intervals intersect, that training event is excluded for that fold. The check should use event start and end times, not a fixed count of rows.

1. Store an event start time, usually when the feature vector or trade signal becomes valid.
2. Store an event end time, such as the barrier touch, position close, or label horizon.
3. Build a test fold from a contiguous time block.
4. Remove every training event whose interval overlaps any test event interval.
5. Fit preprocessing, feature selection, and the model only on the remaining training data.

A common implementation mistake is to purge a fixed number of bars. That fails when event horizons vary. Ten rows may represent ten minutes in one sample and several hours in another, so a row gap can remove too little data or waste far too much.

What the Embargo Adds

An embargo removes an additional slice of training data immediately after a test period. This is meant to weaken leakage caused by nearby observations, overlapping feature windows, or persistent market states that survive the direct interval-overlap check. The phrase Lopez de Prado purged cross validation embargo financial machine learning usually refers to this paired method: purge direct overlap first, then apply a time-based or sample-based buffer.

The embargo length is not universal. It should reflect the longest relevant information horizon, feature lookback, execution delay, and sampling design. A tiny buffer may leave dependence intact; an oversized one reduces training data and can make fold scores noisy. Operators usually inspect fold boundaries and plot retained versus removed events before trusting the split.

Building the Validation Pipeline Correctly

The splitter is only one part of the pipeline. Leakage can still enter through global normalization, target-aware feature selection, resampling, or feature engineering performed before the folds exist. Each transformation that learns from data must be fitted inside the training fold and then applied to the test fold.

• Use a pipeline so scalers, encoders, imputers, and selectors are refitted per fold.
• Keep label construction deterministic and preserve each sample's true end time.
• Pass sample weights only after matching them with the purged training index.
• Log train ranges, test ranges, purged counts, embargoed counts, and class balance for every fold.
• Evaluate trading outputs such as turnover, drawdown, hit rate, calibration, and net returns after fees—not model accuracy alone.

Libraries inspired by scikit-learn often expose a PurgedKFold-style splitter, but APIs differ. Some expect a series of event end times; others accept explicit purge and embargo gaps. The implementation should be reviewed against the label semantics rather than trusted because the class name sounds right.

Combinatorial Purged Cross Validation

Combinatorial purged cross validation extends the idea by dividing the timeline into several contiguous groups and testing multiple combinations of those groups. Each combination is purged and embargoed before training. Instead of producing one sequence of fold scores, it produces a broader distribution of out-of-sample paths.

For example, dividing data into six groups and choosing two as test groups creates fifteen possible test combinations before any path assembly. That wider view can reveal whether performance depends on one lucky regime. The trade-off is compute: more combinations mean more model fits, more stored predictions, and more care when aggregating paths without double-counting observations.

Diagnostics and Common Failure Modes

A suspiciously strong validation result is not proof of leakage, but it deserves inspection. Compare purged results with naive K-fold and walk-forward testing. A large collapse after purging suggests that overlapping information was carrying part of the score, though regime change or reduced sample size may also contribute.

Where It Helps—and Where It Does Not

Purged cross validation is useful for event-driven labels, overlapping holding periods, rolling features, meta-labeling, and strategies whose samples share future price paths. It is less necessary when observations are truly independent and labels do not span time, though that condition is uncommon in trading research.

It also does not recreate live deployment by itself. Because purged K-fold may train on data that occurs after a test block, it can estimate model stability without matching the one-way flow of production. Walk-forward validation is often better for answering, “What could the model have known at that date?” Purged methods answer a different question: “How well does the model generalize once overlapping information is removed?” Mature research often uses both.