Feature Engineering for Financial Time Series

Given the same dataset, two teams can build models that differ enormously in quality while using identical architectures. The difference is almost always in the features.

Start with stationarity

Raw prices trend. A model trained on an asset at one price level has no principled basis for one at a very different level. Converting to returns — ideally log returns — removes the trend and produces a series with roughly stable statistical properties.

This single transformation does more for model quality than most architecture choices.

Features that tend to carry signal

• Returns over multiple horizons. One period, five, twenty. Different horizons capture different behaviour.
• Realised volatility. Rolling standard deviation of returns. Volatility clusters, which makes it genuinely predictive of near-term volatility.
• Volume relative to its own average. Absolute volume is not comparable across assets; a ratio is.
• Range measures. High minus low, normalised. Captures intraperiod activity that close-to-close returns miss.
• Distance from a moving average. Expressed as a percentage, not an absolute figure.
• Calendar features. Day of week and proximity to known events, encoded cyclically rather than as raw integers.

The lookback window question

Every rolling feature needs a window length, and this choice is quietly one of the most consequential in the whole system. Short windows react quickly and produce noisy features. Long windows are stable but slow. Using several lengths of the same feature lets the model decide which matters, at the cost of more columns to overfit.

Scaling, done in the right order

Fit your scaler on the training window only, then apply it to validation and test. Fitting on everything is the most common leakage bug in financial machine learning. In a walk-forward setup this means refitting the scaler at each step, which is tedious and correct.

Every transformation must be computable using only information available at that moment in time. That rule resolves most feature engineering questions.

Knowing when to stop

More features are not better. Each one adds a dimension in which the model can find a coincidence. If a feature cannot be justified with a plausible mechanism — why would this contain information about future returns? — it is probably adding noise.

A model with a dozen well-reasoned features usually generalises better than one with two hundred scraped together.

Educational content only. Not financial advice.