Machine Learning for Trading, Part 2: Random Forest Without Fooling Yourself

A random forest is a useful model for tabular data. That makes it a natural candidate for systematic trading research, where each observation may contain returns, volatility, volume, valuation, macroeconomic variables, or other features.

It is not automatically a good trading model.

A random forest can fit noise just as enthusiastically as any other flexible model. In markets, the hard part remains the experiment: what are you predicting, what information was actually available at the time, how do you separate past from future, and does the signal survive costs outside the data used to design it?

Part 1 built that research framework. Here we add the model.

What a random forest does

A decision tree repeatedly splits observations into groups. A simple trading tree might learn rules such as:

1if 20-day volatility > threshold:
2    go left
3else:
4    go right

It keeps splitting until it reaches terminal leaves that contain a prediction.

One tree is unstable. Small changes in the training data can produce a very different tree.

A random forest reduces that instability by training many trees on randomized versions of the data and combining their predictions. Two forms of randomization are especially important:

1. Bootstrap sampling: each tree sees a resampled version of the training observations.
2. Random feature selection: each split considers only a subset of available features.

For classification, the forest aggregates class predictions. For regression, it generally averages numerical predictions.

The result can capture nonlinear relationships and interactions without requiring the researcher to specify every interaction in advance.

Why random forests are attractive for trading research

They have several practical strengths:

• they work naturally with tabular numerical features;
• they can model nonlinear relationships;
• they can capture feature interactions;
• they require less preprocessing than many distance-based or neural-network methods;
• they can provide useful diagnostics about which variables affect splits; and
• they are strong enough to test whether a simple nonlinear model adds value beyond a linear baseline.

That last point is how we prefer to think about them.

A random forest is a useful research benchmark. If an elaborate deep-learning architecture cannot outperform a carefully validated random forest, the extra complexity may not be buying much.

Define the label before touching the model

Suppose we have daily observations for an index future and want to classify whether the next session's return is positive.

For observation t:

1forwardReturn[t] = close[t + 1] / close[t] - 1
2label[t] = 1 if forwardReturn[t] > 0 else 0

A more realistic system might require the predicted return to clear expected trading costs before assigning a positive trading label.

For example:

1label[t] = 1 if forwardReturn[t] > estimatedRoundTripCost else 0

The exact target is a research decision. What matters is that it is defined before looking at the model's results.

Build features using past information only

Consider a small feature set:

1r1      = 1-day return
2r5      = 5-day return
3vol20   = 20-day realized volatility
4maGap   = close / 50-day moving average - 1
5volRel  = volume / 20-day average volume - 1

For row t, every input must be computable using information available no later than the decision time for row t.

A surprisingly common mistake is to calculate rolling features with centered windows or to normalize all rows using statistics from the full dataset. Both leak future information.

The same problem appears with economic data. A historical database may contain revised values rather than the value market participants saw on the original release date.

Garbage from the future is still garbage, even if the model calls it feature importance.

Keep the split chronological

Assume we have data from 2010 through 2024.

A simple research split could be:

12010-2018  training
22019-2021  validation
32022-2024  final test

Train trees only on the training period.

Use validation data to choose things such as:

• number of trees;
• maximum tree depth;
• number of features considered at each split;
• minimum observations per leaf;
• feature set; and
• the probability threshold required to trade.

Do not keep tuning until the final test period looks good. Once you do that, it has become part of the development data.

A small JavaScript example

The ml-random-forest package provides a straightforward JavaScript implementation of random-forest classifiers and regressors.

Install it with:

1npm install ml-random-forest

The package documentation exposes RandomForestClassifier, with train() and predict() methods. The following example uses synthetic feature rows so the code demonstrates the model API without pretending the numbers are real market observations.

1const {
2  RandomForestClassifier,
3} = require('ml-random-forest');
4
5// Synthetic features: [r1, r5, vol20, maGap, volRel]
6const trainingSet = [
7  [0.004, 0.012, 0.011, 0.018, 0.15],
8  [-0.006, -0.010, 0.018, -0.022, 0.40],
9  [0.002, -0.003, 0.014, 0.004, -0.08],
10  [0.008, 0.019, 0.010, 0.026, 0.21],
11  [-0.003, 0.004, 0.016, -0.007, 0.05],
12  [-0.009, -0.015, 0.022, -0.031, 0.55],
13];
14
15// Synthetic next-period direction labels.
16const labels = [1, 0, 0, 1, 1, 0];
17
18const classifier = new RandomForestClassifier({
19  nEstimators: 100,
20  seed: 42,
21  maxFeatures: 0.8,
22  replacement: true,
23});
24
25classifier.train(trainingSet, labels);
26
27const testSet = [
28  [0.001, 0.006, 0.013, 0.009, 0.02],
29  [-0.004, -0.008, 0.019, -0.015, 0.31],
30];
31
32console.log(classifier.predict(testSet));

Six rows cannot validate anything. In real research, trainingSet should contain chronologically constructed observations, and the test rows should come strictly later.

Package APIs also change. Pin and test any dependency used in a real trading system instead of assuming a tutorial snippet will remain valid forever.

The project's source is available at mljs/random-forest.

Do not optimize for accuracy alone

Suppose the market is positive on 54% of days in your sample.

A classifier that always predicts "up" gets 54% accuracy without looking at a single feature.

Now suppose your random forest gets 55%.

That one percentage point may be meaningful, noise, or economically useless after costs. Accuracy alone cannot tell you which.

For classification research, inspect:

• the majority-class baseline;
• precision and recall;
• ROC AUC where appropriate;
• confusion matrices;
• calibration of predicted probabilities;
• performance by time period and market regime; and
• economic results after converting predictions into positions.

A small statistical improvement can be valuable if it is stable and concentrated in economically useful forecasts. A higher accuracy score can be worthless if it requires excessive turnover.

Probability thresholds can matter more than the predicted class

A model that estimates a 50.1% chance of an up move is making a very different statement from one estimating 70%.

If the implementation provides reliable class probabilities, a trading rule can require confidence above a threshold before taking risk.

Conceptually:

1if P(up) >= 0.60:
2    long
3else if P(up) <= 0.40:
4    short
5else:
6    flat

Those thresholds are illustrative, not recommendations.

The point is to allow a model to say "I do not know." That can reduce turnover and make transaction costs part of the model-selection problem.

The threshold must be selected on training/validation data, not chosen after seeing the final test.

Feature importance is easy to overinterpret

Random forests are popular partly because they can rank features. That output is useful, but it is not a causal explanation of the market.

Several problems can distort importance measures:

• highly correlated features can split importance among themselves;
• impurity-based measures can favor variables with more possible split points;
• a feature can be useful only because it proxies for another variable;
• importance can change across regimes; and
• a variable can improve in-sample prediction without improving tradable out-of-sample performance.

Permutation importance on held-out data can be more informative because it asks how prediction quality changes when a feature's information is disrupted. Even then, correlation among features complicates interpretation.

Treat importance as a research clue, not proof that you discovered a market mechanism.

Random forests do not automatically adapt to changing markets

An old version of this article claimed random forests were well suited to dynamic markets because they could "adapt quickly."

A trained random forest does not adapt at all unless you retrain it.

You need to define that process:

• How much history should each training window use?
• How often should the model retrain?
• Should old regimes receive the same weight as recent ones?
• What happens when a feature distribution shifts?
• When should a live model be disabled because behavior has moved outside its research assumptions?

A rolling or expanding walk-forward scheme can answer some of these questions, but every added research choice creates another opportunity to overfit.

Costs turn predictions into a strategy

The model produces predictions. The trading system determines whether those predictions are worth acting on.

A backtest should specify:

1position[t]
2entry/exit timing
3spread assumption
4commission and fees
5slippage assumption
6position size
7risk limits

Then compute returns based on the information and prices that would actually have been available.

If a strategy trades at the next bar's open, do not credit it with the previous close unless that execution was genuinely possible.

Small details like this often determine whether a machine-learning backtest describes a strategy or a fantasy.

Test stability, not just the best parameter set

Imagine maxFeatures = 0.7 produces a great validation result while 0.6 and 0.8 are poor.

That is less reassuring than a broad region of parameter values producing similar results.

A robust research result should not depend on one exact tree count, one exact probability threshold, or one narrow feature window unless there is a strong reason for that sensitivity.

Try perturbing:

• feature windows;
• tree counts;
• depth constraints;
• training periods;
• trading thresholds;
• cost assumptions; and
• market subperiods.

If the edge disappears whenever you touch a parameter, assume fragility until proven otherwise.

Compare the forest with simpler models

Before celebrating a random forest, run the same features through a simple model such as logistic regression.

If both produce similar out-of-sample results, the simpler model may be preferable. It is easier to inspect, cheaper to maintain, and less likely to hide a research mistake.

If the forest materially improves performance, investigate why. Is it capturing nonlinear thresholds? Feature interactions? A specific regime?

That comparison teaches you more than declaring one algorithm "powerful."

The untouched test period still gets the final vote

After feature selection, hyperparameter tuning, threshold selection, cost assumptions, and trading rules are settled using training and validation data, evaluate the untouched test period once.

The result may be disappointing.

That is not a failed research process. It is exactly what a credible test is supposed to reveal.

A strategy that survives should then face additional scrutiny: alternate periods, instruments where the hypothesis should transfer, realistic execution tests, and paper trading before meaningful capital is exposed.

Machine learning does not lower the evidence bar for a trading strategy. It raises it because flexible models give researchers more ways to fool themselves.

Where to go next

Random forests are a sensible second model because they add nonlinear capacity without requiring a massive modeling stack.

But the durable workflow is still the one from Part 1:

1. define a tradable target;
2. build features from past information only;
3. establish a simple baseline;
4. split data chronologically;
5. tune only on development data;
6. model trading costs and execution;
7. test parameter and regime stability; and
8. preserve a genuinely untouched final test.

The model is one component of that process, not the process itself.

Sources and further reading

• ml-random-forest on npm
• mljs/random-forest source
• Grizzly Bulls: Machine Learning for Trading, Part 1
• Grizzly Bulls: Overfitting in Algorithmic Trading

Code and thresholds in this article are educational illustrations. They are not trading recommendations or evidence of predictive performance.