Why do machine-learning models use returns instead of raw prices?

Raw prices are nonstationary: their level drifts over time, so patterns learned at one price region do not transfer to another. Returns, ratios, and normalized distances have distributions that are far more stable across history and across symbols, which lets a model trained on the past generalize. Most trading features are therefore built from returns or other scale-free transformations rather than price itself.

What is lookahead bias in feature engineering?

Lookahead bias is any feature that uses information unavailable at the moment of prediction, such as the current bar's close before the bar completes or a value from a repainting calculation. It inflates backtest results that live trading cannot match. The fix is strict: compute every feature from completed, historical data only, and confirm the pipeline behaves identically in simulation and in real time.

How many features should a trading model use?

Fewer than enthusiasm suggests. Financial data is noisy and effective sample sizes are small, so models with many features find spurious structure easily. Practitioners commonly work with a handful to a few dozen carefully chosen inputs, prune aggressively, and prefer features with an economic rationale. If performance depends on feature count rather than feature quality, that is usually overfitting speaking.

What makes a good trading feature?

Rough stationarity, so its meaning holds across history; availability at prediction time, so it survives live; economic interpretability, so its predictive claim can be argued rather than merely observed; and low redundancy with the rest of the set. Robustness across symbols and regimes is the practical test: a feature that only works on one instrument's history is usually a coincidence with a name.

Should features be normalized, and how?

For distance- and gradient-based learners, yes: unscaled features let the largest-ranged input dominate. Z-scoring and min-max scaling are the standard choices, with the non-negotiable detail that scaler parameters are fitted on training data only and reused unchanged thereafter. Tree-based models are scale-indifferent, but normalized features still help with interpretation and cross-symbol pooling.

Can the same features work across different markets?

Scale-free features often do transfer usefully, returns, volatility-normalized distances, and regime flags mean roughly the same thing on an index future and a currency pair. Session-structure features transfer worst, since market hours and participation rhythms differ. Pooled training across symbols works best when every feature is explicitly normalized per instrument, so the model learns patterns rather than symbol identities.

Concept

Feature Engineering

Feature Engineering is a Machine Learning concept. The Library holds 1 implementation, a working definition you can pull into Quant.

lags. vol-normalized returns

Top Feature Engineering indicator

The top custom implementation, built on the original standard Feature Engineering formula.

1 total

The Feature Engineering implementation below can become a backtested trading strategy — describe your rules and Quant writes the code.

Feature Engineering

Indicator

What is Feature Engineering?

Feature engineering is the step in a machine-learning pipeline where raw market data is turned into the input variables a model actually learns from. Raw prices are a poor input: they trend, drift, and sit on a different scale for every symbol, so a model fitted on them rarely transfers. Practical features are transformations that make bars comparable, such as lagged returns, volatility-normalized returns, oscillator readings, distances from a moving average expressed in ATR units or as a z-score, and time-of-day or session flags.

Two constraints do most of the work. First, features should be roughly stationary: their distribution should not depend on where in history they were computed, which is why returns and ratios are preferred over raw levels. Second, every feature must be computable strictly from data available at prediction time; a feature that peeks even one bar ahead produces backtests that live trading cannot reproduce. Feature quality typically matters more than the choice of model sitting on top of it.

The step sits in the middle of a pipeline whose ends discipline it. Upstream, the label definition and prediction horizon decide what the features are supposed to explain, and features built without a fixed target tend to be decorative. Downstream, the model's geometry decides what preparation matters: distance-based learners like kNN are hostage to feature scaling, tree ensembles tolerate raw ranges but waste capacity on redundant inputs, and correlated features can be compressed with PCA before they reach the learner.

Beyond leakage, the standing hazards are abundance and drift. Every added feature enlarges the space in which a model can memorize noise, so small feature sets with clear economic logic tend to survive out-of-sample where kitchen-sink sets do not. And features themselves drift: a normalization fitted on training data ages as volatility regimes change, which is why regime tags, from k-means state labels to Markov-switching models, often join the feature set to let the model condition on the market's current mode.

How to build a feature set for a trading model

Feature work is pipeline design rather than chart reading; these are the steps that keep it honest.

1Fix the label and horizon first: what outcome, measured over how many bars, the features are supposed to predict.
2Draft candidate features as scale-free transforms: lagged and normalized returns, oscillator states, level distances in ATR or z-score units, session and regime flags.
3Enforce information timing: every value must come from completed bars only, with any smoothing or normalization computed strictly on past data.
4Fit scalers on training data alone, then apply them unchanged to validation and live data; refitting on the full sample is quiet leakage.
5Prune redundancy: drop near-duplicates or compress correlated groups (with PCA or simple selection) so distance-based learners are not dominated by one theme.
6Verify train-live parity: the live pipeline must reproduce the training features bit for bit before any result is trusted.

How traders use it

As model inputs: lagged and volatility-normalized returns, oscillator values, and level distances form the feature vector that classifiers such as kNN or logistic regression consume.
As a scaling step: min-max scaling or z-scoring puts features on a common range so distance-based learners do not let the largest-scaled input dominate.
As leakage control: features are built only from completed bars and past data, so the model sees in training exactly what it would see live.
As regime awareness: adding state labels from k-means regime clustering or a Markov-switching model lets one model behave differently across market modes instead of averaging them.
As dimensionality control: compressing correlated indicator families through PCA or explicit selection keeps the feature count small relative to the sample, which is a first-order defense against memorized noise.

Feature Engineering vs neighboring pipeline steps

PCA: PCA transforms an existing feature set, rotating correlated inputs into fewer uncorrelated components. Feature engineering creates the inputs in the first place; PCA is one of its cleanup tools, not a substitute for choosing informative transforms.

Label Definition & Prediction Horizon: Labels define what the model must predict; features define what it may look at. The two are designed together, since a feature set that cannot plausibly explain the chosen horizon produces models that fit noise by default.

kNN Analog Forecasting: kNN is a consumer of features: it measures distances in whatever space the engineer built, so scaling choices and redundant inputs change its neighborhoods directly. The pairing illustrates the rule that preparation, not the learner, usually decides the outcome.

Concept family

Machine Learning

32 concepts mapped · 32 in the Library

Feature Engineering FAQ

Turn Feature Engineering into a trading strategy.

Take the implementation from this page into Quant, then build on it, backtest it on real data, and keep refining it in conversation.

Previous conceptEnsemble Voting of Signals Next conceptFeature Selection