Why portfolio stress testing breaks on data
Portfolio stress testing starts not with a scenario but with the quality of position data. Exports from venues arrive through different channels: some via an API, some manually from an account dashboard, some from a spreadsheet that someone maintains in parallel.
Positions in derivatives, loans, and locked funds, meanwhile, settle outside the perimeter where risk is calculated, and the model receives a truncated picture.
A single unaccounted-for leg is enough for the total exposure to be understated, even though all calculations formally reconcile.
The second point of failure is the assumption that assets are independent.
The correlation matrix is calculated over a calm historical window, where instruments genuinely behave differently; at the moment of a shock, hidden correlation emerges, relationships converge to one, and diversification stops working.
An asset that looked defensive in the report falls along with the rest, while the calculation shows a comfortable margin of safety.
Third is illiquidity, which simply is not in the model. In a calm market, slippage is unnoticeable, but during cascading liquidations the order book empties, and the execution price differs from the one in the valuation by multiples.
The loss limit calculated from the quote proves unexecutable: a position of the required size cannot be closed at that price.
Together, manual exports and discrepancies produce a systematic underestimation of risk: the calculated drawdown is lower than the actual one, limits trigger late, and the hedging decision is made based on numbers that no longer describe reality. Below, we break down how we close each of these gaps.
Measurable effects: time, accuracy, eliminated class of failures
Risk assessment preparation time: minutes instead of days
Scenario runs are based on historical series and generated shocks, so risk assessment is prepared within minutes after the portfolio changes.
Previously, the same work took days of manual reconciliation: positions were exported from venues separately, prices were consolidated manually, and any portfolio update invalidated the calculation.
CoinGecko is used as a source of normalized series, and correlations between assets are calculated jointly — otherwise diversification looks like protection that does not exist.
Drawdown estimation accuracy: coverage of all positions
Drawdown is calculated across the full set of instruments, including illiquid positions, staking, and locked funds, not only major coins.
For thin markets, the model accounts for slippage and order book depth: during a shock, exiting a position costs more than the last trade shows. This removes the familiar error where the calculated drawdown differs from the actual one by multiples at execution.
Unified limits across all venues and an eliminated class of failures
Limit rules are described once and applied to all venues and accounts, so discrepancies between them are visible at the calculation stage rather than afterward.
An entire class of failures related to delayed reaction to market movement has been eliminated: scenarios run on schedule and when volatility crosses a threshold, and the signal goes to monitoring before limits are breached.
Scenario run modes: comparison of approaches
Run modes do not replace one another — they answer different questions: reproducibility of the report, finding the boundary of resilience, checking the chain of events.
The choice of mode determines what you get at the output: a drawdown estimate or an answer as to at what market movement the portfolio stops holding its limits.
We check the methodology against IOSCO recommendations on fund stress testing — scenario composition, frequency, documentation of assumptions.
In practice, modes are combined: historical shocks provide a basis for comparison, reverse calculation provides boundaries, and random trajectories provide the distribution of outcomes.
| Mode | When it fits | Limitations |
|---|---|---|
| Run on historical shocks | Reproducibility and a common basis for comparing reports are needed | Past crashes do not describe new risk classes |
| Specified market shock | Testing a specific hypothesis: drawdown of the underlying asset, volatility spike | The result depends on the choice of shock depth and timing |
| Reverse calculation from the limit | Need to know at what market movement the risk limit is breached | Gives a boundary but not the probability of the event |
| Random market trajectories | Assessment of the distribution of outcomes and tail losses | Requires model calibration and a large number of runs |
| Cascade of scenarios | Checking the chain: price → volatility → liquidity → margin | Takes longer to calculate and is harder to configure |
Separate runs do not see how one failure pulls the next along, so the cascade is assembled on top of the other modes. It shows where execution slippage turns into a margin call on leveraged positions — and what exactly breaks first in such a chain.
How we build portfolio stress testing: stages of work
Stress testing starts not with code but with an inventory of data and calculation rules. If quotes and portfolio composition diverge between systems, the run produces beautiful but useless numbers. Therefore, sources and logic come first, calculations after.
-
Data source audit. We consolidate quotes, trades, balances, and instrument reference data, and check update frequency, gaps, and discrepancies between venues. The output is a source map with a reference value for each metric.
-
Calculation and limit schema. We fix the portfolio composition at the cut-off time, the rules for recalculating positions, and the reporting currency. Separately, we define limits by instrument, asset class, and concentration — and what constitutes their breach.
-
Run configuration. We implement the calculation module, set launch parameters, and log every step: from the portfolio cut-off to the final loss by position.
-
Validation on known shocks. We run scenarios that the market has already experienced and compare the result with the actual outcome. A discrepancy above the threshold means an error in data or formula, not a model feature.
At the same time, we cover edge cases — an empty portfolio, a single position, missing prices for some instruments.
-
Approval of the scenario set. We submit to the risk committee a list of shocks — liquidity crash, correlation breakdown, sharp rate increase — with the amplitude of each. The committee approves the mandatory set and the review frequency.
-
Handover of the regulation to the team. We provide the document: mandatory scenarios, critical thresholds, the procedure for running and reading the report, and the rule for updating scenarios when the market changes.
A stage is considered delivered when your analysts run the stress test themselves: a regulation that cannot be reproduced without its author is not considered handed over by us.
Project artifacts: configurations, schemas, regulations
The result of the project is not only a working environment but also a kit with which the client's team continues to work independently: adding scenarios, analyzing reports, changing thresholds without contacting us. Below is what is handed over upon completion of the work.
- Run configurations. Portfolio stress testing scenarios — liquidity crash, stablecoin peg divergence, cascade of forced closures — are described declaratively: horizon, step, asset composition. A new scenario is added by editing a file, without code changes.
- Data flow schemas. The path from quote sources and blockchain data to the calculation core and report, with failure points and described behavior when a source disappears.
- Access policies and roles. Analyst, risk manager, and administrator are separated by permissions: editing configurations, running scenarios, viewing portfolio composition. Actions are logged — you can see who changed parameters and when.
- Limit response regulation. Thresholds at which a run stops, escalation procedure, notification templates, and incident recording format.
- Guide for analysts. How to assemble a scenario, read the report, which metrics to treat as threshold, and where interpretation mistakes most often occur.
- Metric catalog and benchmark runs — a comparison base for each new result.
- Deployment and recovery instructions — how to bring up the environment from scratch and roll back to the previous set of configurations.
At acceptance, we run a scenario using the handed-over documentation by your team: the result must be reproducible without our involvement.
Case study: metrics before and after implementing the risk perimeter
The client's portfolio consisted of spot balances on several exchanges, leveraged derivatives, collateralized lending, and staking.
Portfolio stress testing was performed manually, and the risk summary appeared with a delay — after the market had already moved against the position.
Initial setup and its weaknesses
The analyst exported balances, consolidated them into a spreadsheet, and manually checked them against limits by instrument and counterparty.
Only spot positions were covered: derivatives, collateral, and accrued income remained outside the scope, so the real position in the asset was higher than the calculated one. Limits were checked the next day — the breach was recorded when the trade had already gone through.
What we changed and what the result was
We built a unified risk perimeter: a single source of positions across all accounts and networks, recalculation on schedule and by trigger during sharp movement, and a scenario matrix — a 30–40% market crash within a session, liquidity gap, stablecoin peg loss, cascade of forced closures.
We calculate scenarios through the portfolio's expected shortfall, following the logic of the Basel Committee on Banking Supervision, rather than through a single price deviation. Early warnings were set as the limit approaches 80% — they trigger before a breach, not after.
| Metric | Before | After |
|---|---|---|
| Risk summary preparation time | two business days of manual assembly | 15–20 minutes of automated calculation |
| Share of covered positions | 45–60% | 98% |
| Missed limit breach warnings | 7 per quarter | none |
| Early warnings received before a breach | 3 out of 10 | 9 out of 10 |
How does scenario analysis differ from reverse stress testing?
The methods answer different questions: scenario analysis goes from cause, reverse stress testing from the limit — from effect. One shows what will happen to the portfolio under a given shock, the other shows which conditions will breach the allowable loss.
In scenario analysis, the input is explicit shocks: a drop of a major asset by a given percentage, loss of a stablecoin peg, volatility spike, funding rate increase.
The output is portfolio revaluation, drawdown by each leg, the moment a margin top-up is required, and its remaining amount.
Reverse stress testing reverses the logic: the input is the allowable loss and holding horizon, and the output is combinations of conditions that breach the limit, with the frequency and depth of the breach.
Running across historical windows and generated trajectories shows how often the boundary would be breached again, not just that "it happened once."
The choice of method for the task is simple: scenario analysis — to validate a specific risk and justify it; reverse stress testing — to calibrate the limit, position size, and automatic reduction threshold.
In a stress testing system, both modes work together: the reverse run finds the boundary, and the scenario run explains what happens beyond it.
Technical concerns: data, liquidity, over-the-counter positions
Before acceptance, the client checks the places where portfolio stress testing usually breaks: incomplete position data, over-the-counter and collateral instruments, outdated scenarios, and post-handover support.
Position data is incomplete — what should be done?
We reconcile balances with statements and localize discrepancies down to a specific trade. We restore gaps from transaction history, and mark non-restorable ones as an estimate and show them as a range.
How are over-the-counter positions accounted for?
We maintain a separate register of confirmations and contracts: volume, entry price, exit conditions. We calculate such positions with a liquidity discount and an extended closing period, rather than as an exchange-traded asset.
What about collateral instruments?
Collateral is a bundle of "security and obligation": when the price falls, the margin requirement increases. We run the scenario as a cascade — from collateral drawdown to the threshold and forced liquidation.
How often should scenarios be reviewed?
Review is tied to events, not to the calendar: a new portfolio structure, a new instrument, a change in market regime. We calibrate parameters using fresh data so that scenarios do not become outdated along with the market.
Will we be able to maintain the system ourselves?
Yes. Scenarios are stored separately from the code, with a description and review regulation. Your analyst adds and edits scenarios without a release, and we remain available for further improvements.
Let's discuss the task: where to start with the risk assessment perimeter
For the assessment of the portfolio stress testing perimeter to be based on your reality rather than average assumptions, we need inputs. The more precise the initial data, the fewer unknowns in the work plan and the more realistic the timelines.
- Portfolio composition: asset classes, venues, shares, and limits for each area.
- Data sources: trade archives, quotes, exchange interfaces — what is available, with what history depth and frequency.
- Material scenarios: liquidity crash, liquidation cascade, price divergence between venues, counterparty failure.
- Risk management rules: limits, margin thresholds, trading halt conditions, who decides to reduce a position.
- Execution perimeter: where metrics are calculated, which systems already exist, and what needs to be integrated.
- Reporting requirements: who views the results, in what form, and whether export to internal systems is needed.
- Constraints: regulatory, access-related, and related to the load-testing window in the production environment.
Based on the review, we return with an effort estimate by stage, a work plan with sequence, control points, and the composition of deliverables — from the scenario specification and portfolio model to configurations and the regulation for repeat runs.
We work in iterations: after each stage, we demonstrate an intermediate result and refine the plan. Describe the task in free form — with the portfolio composition and the most painful scenario; that is enough for us to return with an estimate and a plan.