Feature Engineering and Backtesting for Trading

July 1, 2026 · ~1,182 words · GEX Levels · Module 18 of 18 · Feature Engineering & Backtesting track

The Feature Engineering & Backtesting module is not about a specific strategy. It is about the discipline of building and honestly testing quantitative trading ideas so that a good-looking backtest actually means something.

The problem this module actually solves

Anyone can build a strategy that looks profitable on historical data. The much harder, much less glamorous skill is building a research process where a profitable-looking backtest is trustworthy in the first place. Feature engineering and backtesting, treated properly, is a discipline of honest measurement: defining inputs (features) and outcomes (labels) with correct timestamps, simulating execution the way it actually happens rather than the way it is convenient to assume, and then stress-testing the result hard enough that a lucky pattern gets rejected before it reaches real capital. The throughline of this entire module is validation, not performance — the goal is not to find the best-looking equity curve, it is to find out whether an equity curve deserves to be believed at all.

Features and labels: getting the timestamps right

A feature is any input a strategy is allowed to see at the moment it makes a decision — a price-derived statistic, an order-flow measurement, an options-derived metric, anything computed strictly from data available up to that instant. A label is the outcome the research is trying to predict, defined over some window after that decision point. The single most common way research quietly becomes worthless is look-ahead bias: using information, even by accident, that would not actually have been available at decision time. A feature built from a bar's closing price but used as if it were known at that bar's open is a classic example, and it is easy to introduce without noticing, especially when data is resampled, joined across sources, or restated after the fact.

Labeling itself is a design choice, not an afterthought. A fixed-horizon label simply looks a set number of bars ahead; a triple-barrier label instead tracks whichever of three conditions is hit first — a profit target, a loss limit, or a time limit — which tends to better reflect how a real position would actually be managed. Event-driven labels anchor to something happening in the market (a volatility spike, a scheduled release) rather than to a fixed clock. Whichever choice is made, every feature must be frozen at the true decision timestamp and every label must only use information from strictly after that point — what practitioners call point-in-time discipline.

Building features from order flow and options data

One illustrative case worth walking through in depth is constructing a feature from options-derived dealer positioning — for example, an estimate of aggregate gamma exposure near the current price, or the distance from spot to a large concentration of open interest sometimes called a wall. These estimates are built from open interest, the underlying's spot price, and an option pricing model's outputs; they are model-derived approximations of dealer hedging behavior, not directly observed positions, since no one outside the dealers actually reports their hedges in real time. A feature like this can be genuinely informative — positive aggregate gamma is associated with dealer hedging that tends to dampen realized movement, while negative gamma is associated with hedging that can amplify it — but a feature engineer has to be careful that the inputs feeding the estimate (open interest snapshots, in particular) were actually available at the timestamp the feature claims to represent, since open interest itself typically only updates once per day after clearing.

The backtest engine: an honest simulation, not a best case

An honest backtest only uses data that would have been known at the simulated decision time, and it models the real cost of getting a trade done: the bid-ask spread, exchange and broker fees, realistic slippage on the specific order type used, and any latency between signal and execution. Assuming every order fills at the exact trigger price, or at the midpoint, is one of the most common ways a backtest overstates its own performance — a strategy with a thin theoretical edge can have that edge fully consumed by a tick or two of real-world slippage per trade. Position sizing and risk caps belong inside the backtest itself, not bolted on afterward, so that the simulated equity curve reflects constraints a live account would actually operate under.

Validation methodology matters just as much as the simulation itself. Walk-forward validation tests a strategy only on data that comes chronologically after the period it was tuned on, which respects the one-directional flow of time that a live strategy actually experiences. Purged and embargoed cross-validation goes a step further by removing training samples that overlap in time with a test window, since overlapping outcomes are not statistically independent and can otherwise let information leak between the two sets through shared data windows.

Overfitting and the deflated Sharpe ratio

Perhaps the single most dangerous failure mode in this entire discipline is overfitting through multiple testing: if enough parameter combinations, feature variants, or entry rules are tried against the same historical dataset, some combination will look excellent purely by chance, with no real edge behind it. The more tests run, the more likely a purely lucky result surfaces and gets mistaken for a discovery. The deflated Sharpe ratio is one tool built specifically to correct for this: it adjusts a strategy's apparent risk-adjusted return downward based on how many independent trials were run to find it, giving a more honest estimate of whether the result is likely to be real. Writing the hypothesis and the exact test methodology down before running the test, and refusing to iterate on the same out-of-sample data after seeing the result, are the practical disciplines that keep multiple testing from quietly poisoning a research program.

A concrete walkthrough: from promising to promoted

Consider a hypothetical order-flow feature that tests well on several years of index futures data. Before it goes anywhere near live capital, a staged promotion path applies: first a purged walk-forward test with realistic fees and slippage built in; then a Monte Carlo stress test that reshuffles trade order and adds noise to check whether the result depends on one lucky sequence of trades; then a period of paper trading where the exact live decision pipeline runs in real time without capital at risk, specifically to catch feature drift — cases where the live data distribution has quietly stopped resembling the training data. Only after a feature clears each of these gates, in order, does it get promoted to small live size, and even then it continues to be monitored for the same drift that paper trading was checking for.

What this discipline does not do

A rigorous feature-engineering and backtesting process does not guarantee that a validated strategy will keep working, and it cannot fully replicate the market impact, emotional pressure, or execution friction of trading real size live. Paper trading and Monte Carlo stress tests reduce the risk of promoting a lucky pattern, but they do not eliminate regime change: a feature can be genuinely well-validated on years of data and still stop working when the market's underlying behavior shifts. The value of this whole discipline is not certainty about future performance; it is a defensible, repeatable process for telling a real, if modest, edge apart from a statistical accident before either one reaches an actual account.