How raw financial observations become model inputs: define economic meaning, preserve availability times and fit learned transformations inside each training fold.
Feature Engineering
Feature engineering is the design and construction of the inputs a model uses from raw observations. In quantitative finance, it determines whether a model sees a useful economic quantity, such as a trailing return or a liquidity measure, and whether that quantity could actually have been known when the trade was decided. A sophisticated learning algorithm cannot repair an input that already contains the future.
A feature is distinct from the target. A trailing return might be an input; the subsequent return being predicted is an outcome used for training and evaluation. Putting that subsequent return into the input columns would reveal the answer.
Choose what the model should see
Feature engineering can combine measurements, change their scale, encode categories, summarise a history or select existing inputs. The choice should express a hypothesis about the task. More columns can also introduce redundant measurements, unstable estimates and more opportunities for overfitting.
Raw observations
Possible feature
Design decision that matters
A history of prices
Trailing price return
Lookback, adjustment convention and when the last price becomes usable
A history of returns
Trailing realised volatility estimate
Window, estimator and treatment of missing sessions
Bid and ask quotes
Relative bid–ask spread
Quote synchronisation, denominator and stale-quote policy
Company accounts
A valuation or profitability ratio
Publication availability, statement version and comparable units
These are candidate representations, not established sources of trading profit. A return window or ratio denominator changes the economic question. A feature that helps forecast direction may still fail to support profitable trades after costs and position constraints.
Two transforms with different dependencies
Suppose two already observed prices in a common quote currency are 100 and 110. Assume no distributions or corporate actions between them. The trailing simple price return is
rt=100110−1=0.10=10%.
This fixed rule needs those prices, rather than an estimated mean or scale. It measures past price change; it is neither a forecast nor a total-return calculation with reinvested distributions. If 110 is the closing price, it is usable only after that close is observed and processed. A signal calculated from it cannot justify an earlier execution.
Now consider a separate raw feature whose value is 100 in its own units. A standardisation transform has already been fitted on the eligible training observations, giving a mean of 90 and a standard deviation of 5 in those same units. Applying the stored transform gives
zt=σtrainxt−μtrain=5100−90=2.
The input is two fitted training standard deviations above the training mean. This dimensionless score does not establish a normal distribution or a trading edge. The figure keeps this example separate from the price-return calculation.
Separate synthetic transforms: known past prices 100 and 110 give a trailing price return of 10 percent. A raw feature of 100 becomes 2 after subtracting a training-only mean of 90 and dividing by a training-only standard deviation of 5. The fitted state is frozen before later validation or test observations.
Original synthetic examples. The return and standard score use separate inputs; the fitted mean and scale belong only to the training fold.
The StandardScaler documentation describes this stored-statistics pattern. State the standard-deviation convention when estimating the scale. If the fitted scale is zero, the formula above is undefined; choose an explicit constant-feature policy. Standardisation can remain sensitive to outliers.
The fitted state is part of the model
A raw row can be correctly dated while its transformation leaks future information. Computing the mean and standard deviation over the entire history makes later validation or test observations influence the earlier representation. The same issue applies to fitted missing-value replacements, dimensionality reduction and feature selection. The official data-leakage guidance puts these steps inside the training boundary.
For each fold in a chronological research design, fit all learned transformations on that fold’s eligible training data. Apply the stored transformations to its validation or test block without fitting on that later block. Fit fresh state for the next fold under the declared refitting schedule. Choosing the lookback or transformation family is also a research choice: compare candidates within development data and preserve a final assessment period.
A backward-looking window may legitimately use observations from before the training/test boundary: those observations are already in the past. A centred window that reaches into the future, a later revision assigned to its earlier reporting period, or a mean fitted using future test rows creates look-ahead bias. The relevant boundary is the information available at the decision, not merely the row’s date.
A reproducible feature definition records the raw fields and versions, availability rule, units, lookback, missing-data treatment, fitted state and update schedule. Replaying that definition on the same historical information should reproduce the same input. Only then can out-of-sample forecasting and economic evaluation test whether the representation was useful.
Sources
Aurélien Géron, Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow, second edition (O’Reilly, 2019), Chapter 1, “Irrelevant Features,” and Chapter 2, “Feature Scaling” and “Transformation Pipelines.” Local text checked; the financial examples and diagram above are original.
