Development of a strategy parameter optimization system (genetic algorithm)

Genetic algorithm instead of manual parameter enumeration

Manual strategy re-optimization looks predictable: a specialist takes a historical series, runs a backtest, changes the entry threshold, recalculates, adjusts the position size, then the stop level.

One cycle takes from tens of minutes to hours, and several dozen combinations are checked per shift — even though the parameter space is measured in thousands of combinations.

The problem is not only speed. The search is sequential, and the resulting set is ultimately overfitted to the latest part of the history: parameters that worked in a previous volatility regime break when the trend changes.

Add dependence on one person — when they leave, no one can restore the selection logic, and optimization starts from scratch.

A genetic algorithm replaces enumeration with evolutionary search. Parameter bounds, a fitness function, and risk constraints are set, then a population of sets operates: strong combinations pass values to descendants, some mutate, weak ones are filtered out.

Thousands of combinations are evaluated in one run, and the search converges to an optimum region rather than to a random lucky point.

Robustness is checked not on a single segment: fitness is calculated across several independent windows, so the selected parameters hold under different market regimes.

The output is not one “best” number, but a range of values and the boundaries beyond which the strategy degrades.

Strategy re-optimization becomes a routine procedure: configurations and set metrics are saved, the run is repeated on schedule, and the specialist configures selection criteria instead of manually tuning.

What changes after automatic parameter selection

Manual parameter enumeration runs into the human limit: one selection cycle stretches over days, and the found set holds on a single lucky segment of history.

As soon as the market changes regime, the strategy goes into drawdown — this is the cost of overfitting, not a code error.

Automatic parameter selection turns this into a measurable cycle. A genetic algorithm maintains a population of sets, evaluates each on several independent historical windows, and penalizes those whose result holds on only one window.

Selection speed increases from a day to tens of minutes on the same pipeline — hypotheses are tested by the dozen per day, not one per week.

The key metric here is not peak return, but parameter robustness: the share of sets that retain behavior on an out-of-sample segment.

We select a “plateau” — broad regions where neighboring values give a similar result — instead of a lone peak that crumbles at the slightest shift.

Multi-criteria selection maintains return, drawdown, and stability simultaneously: in practice this is implemented by NSGA-II, a proven approach, not a homemade heuristic.

The effect of strategy optimization is visible in numbers: the share of robust sets grows from a third to two thirds, the spread of results between neighboring runs narrows, and the failure class “the strategy fell apart after a regime change” disappears from the statistics.

Parameters stop being a one-off find and become a reproducible result — the same cycle yields a comparable set.

Methods of finding the optimum: comparison of approaches

The dimensionality of the parameter space determines the search method.

For a strategy with three or four inputs and narrow ranges, brute force is enough, but as soon as entry thresholds, position holding intervals, and risk levels are added, the number of combinations grows as the product of variants along each axis.

One backtest on historical data takes seconds — enumerating thousands of combinations turns into hours of computation, while the share of checked points remains negligible.

In practice, methods are combined: grid search narrows the region, evolutionary search refines it from within.

We add a penalty for drawdown and a small number of trades to the fitness function, and verify the result across several historical periods — otherwise the found optimum will be overfitted to a single segment.

Implementation: from problem statement to genetic algorithm tuning

Strategy parameter optimization is not “run over history and pick the best row,” but an engineering process with fixed acceptance criteria.

The order of stages is the same for trading and for balancing tasks: only the set of optimized parameters and the type of objective function change.

1. Strategy breakdown. We fix what is generally subject to search (indicator periods, entry and exit thresholds, position size), and what remains a hard constraint — risk management rules are never optimized.
2. Strategy objective function. We take a metric robust to drawdowns, not maximum return: for example, the ratio of return to maximum drawdown with a constraint on the minimum number of trades in the sample.
3. Data preparation. History is divided into training, validation, and control segments; the control segment is isolated from the search and opened exactly once — before handover.
4. Genetic algorithm tuning. We set the population size, mutation and crossover rates, number of generations, elitism, penalties for excessive complexity and for parameters going beyond acceptable bounds.
5. Out-of-sample validation. The best solutions are run on the control segment and on shifted windows, plus a sensitivity check: a small parameter change should not break the result.
6. Handover. We fix two or three configurations with similar metrics, describe robustness boundaries, and prepare a report with reproducible runs — the same input data yield the same result.

At the output, the client receives not one “ideal” setting, but a set of robust configurations and an understanding of where degradation begins.

What the client receives after implementation

After the pipeline is put into operation, you receive not a set of scripts, but a package by which parameter selection is reproduced without the authors: from the search space boundaries to the rules for when re-optimization is triggered and when the strategy should be stopped.

• Selection system configuration — run files with the search space: bounds and step for each parameter, population size, number of generations, mutation and selection operators, a fixed seed for reproducibility.
• Computation pipeline scheme — where historical data comes from, where solution fitness is calculated, how results are stored, and what happens if a compute node fails in the middle of a generation.
• Set of selection metrics — objective functions and penalties: return, drawdown, turnover, robustness on a held-out window. It specifies which metric is primary and which thresholds cut off obviously fragile solutions.
• Access rules — roles for running, editing configuration, and viewing results: what is available to an analyst, what only to the pipeline owner, and how each parameter change is logged.
• Optimization documentation — description of the genetic algorithm logic, a parameter dictionary, analysis of typical selection failures, and instructions for adding new fields to the search space.
• Run schedule — frequency of repeated selection, data window, stopping conditions, and the procedure for comparing a new configuration with the one already in operation.
• System handover — training for your team on your infrastructure, an acceptance checklist, and a support period after launch.

Case study: strategy parameter selection before and after automation

The client selected strategy parameters manually: an analyst edited values, ran a backtest on historical data, compared curves, and repeated the cycle.

One pass took two to three weeks; during that time about two hundred sets were processed — a narrow band around the initial guess.

The set with the best historical return was selected, and on new data it most often fell apart: the market shifted into a different regime, while the parameters remained overfitted to the past.

This class of failures is more reliably closed with a selection rule than by dealing with the consequences in live trading.

Selection was moved into an optimizer based on a genetic algorithm: a parameter set is a chromosome, a backtest on data is a fitness evaluation, then crossover and mutation of the best individuals.

The enumeration was built on the mature evolutionary optimization library DEAP — launching it did not require writing an engine from scratch.

The main change in the selection criterion: fitness was calculated not from a single run, but across several consecutive historical segments, and a solution losing robustness on at least one was filtered out.

The selection cycle shrank from weeks to one night, the number of checked sets grew from two hundred to tens of thousands per run, and the share of configurations retaining working metrics on new data rose from about a quarter to two thirds.

Selection rules, parameter ranges, and run logs are saved, so any result is reproducible and can be recalculated on the next run.

What to do if parameter selection is already done in-house?

A working custom selection system is an asset, not a liability: it embeds the strategy logic and execution specifics.

We do not propose rewriting everything — first an audit: how the fitness function is formed, how selection, crossover, and mutation are arranged, and where the pipeline loses robustness.

The key audit point is data separation: if parameters are selected and evaluated on the same history, the best result almost always turns out to be overfitting to noise.

We check run determinism, the presence of a validation period, and whether the selection criterion accounts for drawdown, commissions, and slippage, not just return.

Migrating the computations is not always justified: when the pipeline does not scale with the number of runs, takes hours where minutes are needed, or cannot parallelize independent windows.

In other cases, it is easier to refine the existing selection — add a validation period, parameter robustness across windows, and run logging.

We compare both pipelines on the same dataset, with the same commissions, execution delays, and one quality criterion. We look not at the best run, but at the distribution across windows: profit spread, maximum drawdown, share of profitable windows, and calculation time.

With any refinement, we preserve your fitness function, parameter set, and execution rules — this is the domain value of the system. We rebuild the selection infrastructure: validation scheme, selection, logging, and run reproducibility.

Technical doubts and questions of result robustness

Any parameter optimization risks overfitting to historical data: the algorithm honestly finds a combination that is ideal on the past segment, and it falls apart on new data.

Below are the objections engineers most often raise, and how we resolve them with procedure rather than promises.

What to do about the growing number of parameters?

Each new parameter expands the search space and increases the chance of overfitting. We limit dimensionality, group related parameters, fix some according to strategy logic, and introduce a penalty for solution complexity.

Parameters that do not affect the result are removed — this is a limitation of the method, not insufficient tuning.

How does this integrate into the current computation pipeline?

The optimization module reads the same data and returns a parameter set with quality metrics; we do not touch the execution logic. Runs are scheduled or manual, the result is versioned, so it can always be compared with current settings and rolled back to them.

Let's discuss the parameter selection task for your strategy

To make the estimate and work plan rely on your data rather than general assumptions, a few inputs are enough. Below is what to send for review; we will clarify the rest in correspondence.

• Strategy description: entry and exit logic, which parameters are selected and which are hard-fixed.
• Trade or quote history in its original form — a table, terminal export, or file from a database.
• Acceptable value bounds for each parameter and the step by which they can be changed.
• The metric you consider target: risk-adjusted return, drawdown, share of profitable trades, robustness across periods.
• Validation requirements: how to split data into training and control windows, how much time is acceptable for one selection run.
• Computation constraints: where to run the search, whether parallel recalculation across several machines is needed.

In response, we will return an estimate and a work plan broken down by stages: data preparation, genetic search tuning, validation of the result outside the training window, report review, and handover.

We will separately name the parameters sensitive to overfitting and show how we will fix them before launching parameter selection. Describe the optimization task in your own words — that is enough to discuss the optimization task substantively and give timelines for each stage.