AI portfolio risk management: why manual rules don't hold
Manual risk management rests on policies and limits in spreadsheets: constraints by instruments, sectors and currencies live in separate files, and the consolidated picture is assembled once a day — less often if someone on the team is busy.
By the time the numbers align into a single report, the composition of positions has already changed.
The delay in reacting to risk is not about how fast a button is pressed, but about the time from an event to the person authorized to act.
The gap between price, volume and position correlation is discovered after the fact, when portfolio drawdown has already exceeded the agreed corridor. In a volatile market, such a gap costs several percentage points of return that cannot be recovered.
The human factor in risk assessment accumulates unnoticed: a tired analyst explains a move by temporary volatility, and realizing a loss requires a decision that one wants to postpone until morning. Formally, the rules are still complied with — the limit was checked against yesterday's snapshot.
A separate problem is inconsistency among constraints: for one instrument the limit is fully used, while the aggregate load on the portfolio is not checked at all. Locally everything is fine; at the portfolio level there is overload.
An automated loop calculates risk for each position at the moment of change, aggregates correlations and volume simultaneously, and triggers before drawdown becomes irreversible. We break down how this is addressed in practice.
What changes: reaction speed, drawdown depth, reporting
Previously, the path from signal to action took hours: an analyst manually collected positions and quotes, checked them against limits, and made a decision closer to the close.
While the data was aligning, the market had time to work through the move, and loss limitation turned into recording a loss that had already occurred.
The system shortens this gap: deviation from the threshold is recorded at the moment it appears, limit checks happen before an order is placed, and the action is executed automatically or sent for confirmation to the responsible person. Risk reaction speed no longer depends on whether a specific employee is free at that minute.
Drawdown reduction is delivered not by a single stop but by a set of constraints: by instrument, by group of related positions, and by the portfolio as a whole.
When a metric approaches the boundary, the system reduces volume, opens a protective position or withdraws part of the capital — the depth of losses is limited by a predefined threshold, not by a decision made under pressure.
Transparency of decisions rests on a journal: for each trigger you can see which metric crossed the boundary, on what data, which version of the rule was active, and who confirmed the action.
The same journal closes risk reporting — period snapshots are assembled automatically, without manual reconciliation, and the reviewer sees not only the result but also the logic.
The result: portfolio risk management becomes reproducible: identical conditions lead to identical actions regardless of shift changes and the team's current workload.
Three approaches to risk control: rules, models, hybrid
The choice between rules and a model is not a debate about complexity, but a question of which decisions the system makes on its own and which it hands to a human.
Industry reviews, for example GARP materials, agree on one thing: statistics without hard guardrails rarely survives in production.
Declarative rules describe risk as a set of verifiable conditions: a limit on the share in an instrument or sector, maximum drawdown, a ban on increasing leverage when liquidity falls. A trigger is reproducible and can be explained to the investment committee in a minute. But individually the positions look fine, while together they create hidden concentration.
| Approach | When it fits | Limitations |
|---|---|---|
| Declarative rules | Transparent mandate, few trades | Do not see correlations, trigger after the fact |
| Statistical risk model | Many related instruments, long history available | Sensitive to market regime changes, requires drift control |
| Hybrid approach | Portfolio is growing, cost of error is high | Need to delineate the rights of model and rules |
In a hybrid, rules act as hard guardrails with the right to stop a trade, while the model assesses risk and proposes a reduction one or two steps before a limit breach. This reduces the share of false alarms but does not hand critical decisions to statistics.
The choice is set by data and the reporting regime: where explainability is needed and there are few trades, rules suffice; where there are hundreds of positions and they move together, rules without a model produce either false alarms or delayed reaction.
Implementation stages: from data audit to handover of the policy
The sequence of work almost does not depend on portfolio size — the data sources and risk horizon change. We go from raw series to a working loop where every signal has a reason and every decision has an owner. Below is the sequence the project goes through in full.
- Data audit. We look at which series are available, what the history depth is, where gaps and discrepancies between sources are, and whether corporate events are processed correctly. The output is a list of improvements: what we restore, what we exclude from calculation.
- System design. We determine which risks we calculate — market, concentration, liquidity — and which constraints we set. Separately, we fix where a human makes the decision and where the system only signals.
- Rule configuration. We set trigger thresholds, evaluation windows, reaction to market regime changes, and behavior with incomplete data. We test each rule for robustness so that it does not break from a single outlier.
- Backtesting. We run the loop over several periods, including stress periods, and compare signals with actual drawdowns. We calculate the false trigger rate and reaction delay — these are the main acceptance numbers.
- Handover to production. We hand over the policy: who does what on a trigger, how data is updated, when thresholds are reviewed. We add input series quality monitoring; otherwise quiet data degradation will kill the entire logic.
What remains in the client's loop after delivery
Delivery is not a demonstration of a working model, but the handover of everything needed to operate it without us. The entire package sits in your environment, under your rights and with a change history — the model takes on risks but does not take away control.
- Rule configuration — limits by asset classes and individual instruments, trigger thresholds, averaging windows, exclusion lists. They are edited without rebuilding; every change goes through validation and is versioned.
- Integration schemes — where positions, quotes and instrument reference data come from, how often they are updated, how the system behaves when a source is delayed or disappears. With data exchange contracts and discrepancy handling.
- Access policies — roles: who views reporting, who changes limits, who administers. The right to edit risk rules is granted separately; every action remains in the journal with author and time.
- Documentation — how the risk assessment is calculated, what input data is used, what assumptions are built in, and where the model loses reliability. A separate section: how to read a signal and what it does not mean.
- Support policy — frequency of rule reviews, procedure for reacting to triggers, who decides on a model change and within what timeframes.
- Rollback procedure — how to return to the previous version of rules and model, and what happens to already sent signals and open positions.
Separately, we hand over a change journal and a dependency map: you can see what will break if a data source or rule is replaced. Such a package allows you to run the system with your own team or hand it to another contractor without rebuilding context from scratch.
Case: portfolio drawdown and reaction time before and after
A portfolio of several dozen instruments was served by a risk loop built around nightly recalculation: correlations and the covariance matrix were calculated once a day, and the decision to reduce positions was made in the morning on a general call.
Several hours passed between signal and action, and on days of sharp moves this was enough for drawdown to exceed the limit agreed with investors. We break down what changed after the loop was rebuilt.
What was changed in the risk loop
We moved the calculation to streaming mode: volatility and correlations are recalculated over a rolling window on every quote update, threshold rules trigger automatically, and the risk manager sees not a morning report but a queue of signals with justification and a link to the calculation.
Model and parameter set versions are recorded in MLflow — any decision is reproducible, and an unsuccessful configuration can be rolled back without losing history.
| Metric | Before | After |
|---|---|---|
| Drawdown depth on a sharp move | 9-12% | 3-4% |
| Delay from signal to decision | 4-6 hours | 3-5 minutes |
| Share of decisions made manually | 100% | ~15% |
| Frequency of risk metric recalculation | once a day | on every quote update |
Only disputed cases remained manual: divergence between the market signal and mandate constraints, large positions, and exit from illiquid instruments.
The rest is closed by rules, and this fundamentally changes the load on the team — the risk manager reviews a few situations instead of the entire flow.
We separately tracked false triggers: the volatility threshold was tuned adaptively so that the loop would not jerk the portfolio on ordinary intraday noise.
The share of rollbacks after automatic decisions dropped to isolated cases per quarter, and each deviation is analyzed as a model discrepancy, not as an on-duty error.
How does a risk model differ from a set of manual limits?
A manual limit is a deterministic rule: the share of a single issuer is not above a given level, sector exposure is within a threshold, and exceeding it blocks the trade. The logic is transparent, easy to explain to the board of directors and check with an auditor.
There is one weak spot: the limit looks at a position individually and does not see the portfolio as a whole when correlations converge to one.
A risk model assesses not an individual security but the joint distribution of returns. It calculates portfolio volatility, tail scenarios and the contribution of each position to overall risk — concentration is detected where nominal shares do not reveal it.
Hence the working scheme: hard constraints on structure remain deterministic; bypassing them is not allowed.
Within these boundaries, the model redistributes weight among instruments taking into account correlations and market regime, and the result is checked with stress scenarios on historical data.
So that adaptive assessment does not become a black box, the calculation must be reproducible: input data, model version and the contribution of each factor to the final number are recorded.
The approach from Basel III is built on the same principle — hard boundaries plus an internal model under constant control.
We configure both loops together: limits as insurance against gross errors, the model as a fine-tuning tool. We determine the boundary between them based on your portfolio structure and holding horizon.
Common technical doubts before starting
Technical doubts usually surface not at the model selection stage, but when it comes to data and operations: what to do with holes in history, how to catch that the model has “drifted,” and whether the system will start issuing warnings every day.
Below is an analysis of four nodes that determine whether the solution will work six months after launch.
We have heterogeneous data and manual edits in our accounting system. Can a model even be built?
We start not with training but with profiling the extract: completeness for each instrument and period, frequency of gaps, discrepancies between price sources, share of manual adjustments.
Based on the result — a data suitability report and a list of positions that will not enter the calculation until reliable series appear. We do not fill gaps with the “portfolio average”: we mark the feature as unavailable, otherwise the risk assessment becomes quietly incorrect.
How do you track model drift and what happens when it occurs?
We calculate distributions of input features and forecast quality on a holdout period — not only on the training set. Separately, we look at robustness under market regime changes: rising volatility, correlation breaks, liquidity collapse.
When metrics leave the acceptable corridor, retraining on the current window is launched, and the new version first runs in shadow mode alongside the current one — we compare their assessments on the same positions and switch when the divergence is explainable.
How will the system integrate into the accounting loop without breaking it?
The first loop is read-only: we take positions and trades, and write nothing back. Loading is idempotent, a repeated run does not create duplicates, and discrepancies between our calculations and accounting balances are analyzed in a separate reconciliation report.
Writing recommendations back is the second stage, a separate service with an action journal and the ability to disable it with one setting.
Will the system start warning us about every fluctuation?
We calibrate the trigger threshold on historical episodes: we run the model over past periods and look at how many warnings fell on real drawdowns and how many on noise. Then we build levels: observation, attention, action — with different notification frequency.
Each trigger has an explanation: which metric crossed the boundary and by how much. If the share of false signals grows, the sensitivity regulator changes without retraining the entire model.
Let's discuss the task: what we need from you and what happens next
To discuss the task substantively, full access to your systems is not required. An extract of trades and positions for an available period, instrument and asset class reference data, current risk constraints, and several examples of decisions you made manually are enough.
From this set, the data structure, history quality, and which checks can be built immediately and which will require accounting improvements are already visible.
The minimum data from which the analysis starts:
- history of positions and trades — its depth and frequency determine which risk models are applicable;
- reference data for instruments, asset classes and currencies;
- current limits, standards and escalation rules together with policies;
- description of market data sources and their loading procedure;
- examples of risk reduction decisions from past periods — they become a validation set;
- infrastructure constraints: where data is stored and who has access to it.
After the analysis, we return with an estimate and a plan: what we do first, which data requirements we close on your side, how implementation timelines are distributed, and at what point you will see the first working result.
If there is less data than needed, we will say so directly and suggest what to collect first. Describe the task — we'll come back with an estimate and a plan.
