AI system for portfolio optimization: ML and RL approaches

Developing an AI portfolio optimization system: where the logic breaks

A portfolio breaks not at the moment of a trade, but at the moment when a decision is made based on yesterday's picture of the world. Data on prices, liquidity, and factors arrive at different frequencies, and some with a delay of a day or more.

A model trained on aligned series, on live data, sees not the market but a snapshot from a week ago, and signal lag turns into a systematic shift in the decision.

The second failure point is the rebalancing policy. A calendar rule once a month and a fixed weight deviation threshold are convenient and predictable, but they react to a move that has already happened.

Manual rebalancing between plans adds a human factor: decisions are made unevenly, some positions remain overweight for weeks, and no one compares transaction costs with the risk benefit.

During a sharp market shift, both problems combine. Correlations that are different in a calm regime converge to one, and all the risk ends up in a single factor instead of a diversified set.

Historical estimation of co-movements at such a moment underestimates their scale, so the drawdown during a market shift arrives faster than the rule can process it.

The essence is the gap between signal freshness and decision speed: the optimizer itself may be correct, but it receives an input that no longer exists.

We'll examine how this is closed — how an ML signal layer removes lag and why reinforcement learning moves the choice of trade timing and size from the policy document into the policy itself.

Implementation effects: reaction speed and portfolio resilience

The effect of an AI portfolio optimization system is visible not in the accuracy of an individual forecast, but in the portfolio's behavior in an unstable market. Below are the metrics by which we, together with the client, verify the implementation result.

Signal reaction speed

The model recalculates target weights and passes them for execution within a single trading cycle: between signal appearance and order, the time elapsed is set by the policy, not by the duty officer's availability.

In historical runs, reaction time compresses from hours to minutes — the signal does not have time to become stale along the way.

Portfolio resilience

Limits on concentration, sector structure, volatility, and correlations are set directly in the risk rules and in the reward function, so the model cannot drift into a single idea.

Drawdown in similar market segments becomes predictable, and the set of weights becomes stable from cycle to cycle.

Reduction of manual adjustments

The share of signals that pass without human intervention is a direct metric of trust in the system.

Input data checks and hard constraints remove routine work: only a few manual corrections remain per hundred decisions, and almost all are related to corporate events rather than model errors.

Eliminated failure classes

Separately, we maintain a list of failures closed at the architecture level: discrepancy between data and actual positions, execution at an outdated quote, bypassing a limit with a manual order, calculation stoppage when a source fails. Each class gets its own automated check — a return to previous behavior is visible immediately.

Approaches to model building: comparison of modes

The choice of loop is determined not by how modern the method is, but by how risk constraints are formalized in it and how often the statistical properties of the data change. In practice, four modes are compared — from deterministic rules to a learned policy.

The hybrid mode usually gives the best compromise: risk boundaries remain deterministic and verifiable, while the model works only where there is room for a solution.

In building an AI system for portfolio optimization, rules are not abolished — they remain a mandatory layer, and learning and optimization become an add-on above them.

Work stages: from data audit to model handover

We structure the work so that each stage ends with an artifact that can be checked, not a verbal “done.” You cannot skip a step: if you omit the data audit, the model will confidently learn patterns where history simply lacks securities, and the error will surface on the real portfolio.

1. Data audit. We check the depth and completeness of history, gaps and breaks, correctness of closing prices, corporate events, surviving and delisted issuers, and convergence of multiple sources.

   The output is a report on series quality and a list of instruments on which the model is allowed to make decisions at all.

2. Goal and constraint setting. We fix exactly what we optimize: return at a given risk level, deviation from the benchmark portfolio, or drawdown stability.

   We write constraints formally — limits on the share of a single instrument, sector quotas, liquidity requirements, a ban on short positions, and transaction costs.

3. Loop design. We describe how the system lives in production mode: where data comes from and at what frequency, where the signal is calculated, who confirms composition changes, how the trade is executed, and where the history of all decisions is stored for later review.

4. Model training. We train with market regimes and transaction costs taken into account, testing resilience to volatility changes. We separately control overfitting: the model must show results on data it has not seen.

5. Testing on historical slices. We run the strategy over rolling windows — training only on the past, testing on the next segment. We calculate costs, slippage, and behavior in stress periods, and compare with a simple baseline portfolio.

6. Model handover and team training. We hand over documentation, the update policy, and quality degradation monitoring, and conduct a walkthrough with analysts and risk management so the system can be developed without us.

What we hand over: code, diagrams, policies

After handover, the client's team is left not with a “black box” but with a working system and a complete set of descriptions.

It can be handed over to their own development team or another contractor without reverse-engineering the logic: all decisions, parameters, and control points are recorded in the artifacts.

• Model documentation — which features and data are used, what is maximized, which risk constraints are hard-coded, and how the model behaves in different market regimes.
• Decision-making loop diagram — the path from market data and forecast to the order, with control points, limits, and manual veto.
• Access policies — roles, separation of rights to data and parameters, change log, and edit approval procedure.
• Retraining policy — launch triggers, training sample window, validation procedure, and rollback to the previous version.
• Drift monitoring — control of input distribution shift and metric degradation, alert thresholds, and response procedure.
• Environment configurations — pinned dependencies and automated builds: rerunning gives the same result on the same data.
• Operating instructions — how to add an instrument, update the feature set, read the report, and run a pre-release check.

Separately, we hand over the results of tests on historical periods and on a holdout sample — with an honest description of where the approach performs worse, not only where it wins.

Case study: how reserve management changed after implementation

Before implementation, the reserve portfolio was managed manually: the composition was reviewed on a calendar basis, and decisions were assembled from several disconnected spreadsheets. Reaction took a business day or more, so part of the drawdown was closed after the fact.

The metrics below are taken from one portfolio over periods of comparable volatility before and after launch.

What exactly was changed

Replacing manual decisions with a model was a consequence, not the goal.

First, we formalized the risk profile and corridors of admissible weights, then trained the agent on the portfolio's own history — the approaches to labeling and validation were taken from Advances in Financial Machine Learning.

Rebalancing was tied to a risk trigger rather than a date, so unplanned edits became fewer despite a higher frequency of triggers.

The development of the AI portfolio optimization system included a decision log: every weight change is saved with the set of features on which it was made. This made incident review and rollback take minutes instead of reconstructing logic from correspondence.

Reaction time stopped being a constraint — the only bottleneck became the procedure for approving large shifts.

How reinforcement learning differs from classical optimization

Classical optimization works with a fixed formulation: expected returns and a covariance matrix are given, and weights must be found that maximize return under a given risk and constraints.

This is a quadratic problem solved deterministically — the same input always gives the same portfolio, the result is reproducible, explainable, and easy to verify.

The Markowitz approach Markowitz and its practical modifications remain a working foundation: clear logic, fast recalculation, and easy rollback to the previous allocation.

The scheme breaks down where a decision affects the next one. Transaction costs, slippage, and available liquidity depend on the sequence of actions: aggressive rebalancing today eats tomorrow's return.

Reinforcement learning is exactly about this — the agent interacts with an environment rather than a single static data slice, and optimizes cumulative result over a horizon rather than at one step.

This makes it possible to account for the consequences of decisions, not only their instantaneous evaluation.

The price of such flexibility is implementation complexity. An environment model is needed that realistically reproduces costs and liquidity; if the goal is specified incorrectly, the agent finds behavior that is beneficial to itself but meaningless for the business.

Training is sensitive to initial conditions, so random generators, environment versions, and metric versions are fixed, and the result is tested on data outside the training sample.

In practice, we almost always build a hybrid: a classical optimizer sets the baseline allocation and hard risk constraints, while the agent works on top — with rebalancing timing and adaptation to the market regime.

Solution resilience is ensured by safeguards: turnover limits, a cap on deviation from baseline weights, and automatic rollback to the classical calculation when metrics breach the corridor.

Technical concerns: data, resilience, control

Clients come with a similar set of concerns: whether there will be enough historical data, whether the model will turn out to be overfit to a lucky period, who is responsible for its recommendations, and how this will fit into an already operating loop. We answer substantively — without promising a “universal” model.

How do you control overfitting?

Validation proceeds in sequential windows: training on the past, testing on the next segment with a mandatory gap between them to exclude leakage of future values.

We limit model complexity through the number of features and penalties, and keep the divergence between in-sample and out-of-sample metrics under monitoring. A growing gap is a stop signal: we do not release the model until the cause is eliminated.

Who is responsible for the system's decisions?

The system issues recommendations with justification: factor contribution, expected risk, and behavior in scenarios. The final decision remains with the investment committee; there is a manual mode and hard limits, and all actions are logged. Responsibility is not transferred to the algorithm — it is fixed in the policy.

How can this be integrated into an operating loop?

We follow CRISP-DM across lifecycle stages: the pilot runs in a separate loop on a copy of the data, and access to the production environment is read-only.

Integration with accounting systems is through an API and exchange queues, with rollout to part of the portfolio and the ability to roll back the version.

Let's discuss the task: what to prepare for the first meeting

The first meeting pays off when there are facts on the table. Without them, discussion of the task drifts into generalities, and the estimate turns into a vague range — both we and you spend a second meeting on what could have been resolved immediately.

Below is the minimum that allows our engineers to move to an estimate and a work plan after one conversation.

• Current decision loop: how the portfolio is formed now — by rule, by calendar, or by deviation from target shares; who approves changes; where the portfolio version history is stored.
• Data requirements: sources of quotes and trades, history depth, accounting currency and time zone, corporate actions (dividends, splits), and how gaps and outliers are handled. Export format — CSV or Parquet, whether it is one-time or scheduled.
• Risk constraints: limits per instrument and per sector, allowable drawdown, list of prohibited assets, requirements of the policy or regulator that must not be violated under any scenario.
• Access and environment: read-only access to data, a broker test loop where the system outputs the result — a file, a table, or a call from your accounting system.
• Acceptance criteria: how we measure the result — return relative to the benchmark portfolio, maximum drawdown, share of manual interventions in recommendations.
• Team composition and roles: who is responsible for data, who for risk control, who makes the final decision on a trade.

If something from the list is not at hand — that's fine, we close part of it ourselves during the data review stage. Describe the task in free form: we will come back with an estimate, a stage plan, and which data will be needed first.