VaR System for a Crypto Portfolio: Where Risk Assessment Breaks
A crypto portfolio is almost always distributed across several venues: spot on one, derivatives on another, part of the capital in staking or OTC transactions.
A VaR system that calculates the risk of each venue separately and then adds up the numbers yields an arithmetically correct and managerially useless figure — it sees neither correlations between assets nor total capital at risk.
Portfolio risk assessment in this form answers the question "how much will we lose if one venue goes down," not "how much will we lose tomorrow."
The second failure point is consolidating positions across venues. While it is assembled through exports and recalculated in a spreadsheet, the data diverges: the price has moved, the funding rate has changed, part of the collateral has already been shifted to another trade.
Calculating maximum drawdown from such a snapshot describes the portfolio's past state, while the decision is made based on the present — and the gap between them grows along with volatility.
The third gap is most noticeable in its consequences: a limit is discovered after it has been breached.
The risk rule lives in a policy document or in the risk manager's head, not in execution, so the signal arrives when the position has already crossed the boundary and closing it costs more than the excess itself. Here risk assessment ceases to be management and becomes reporting.
Next, we break down how these gaps are closed: a unified calculation across all venues, automatic position consolidation, and limits that trigger before a breach, not after.
What Changes After Implementation: Speed and Accuracy of Assessment
Risk recalculation stops being a daily ritual.
The system keeps the assessment of the entire portfolio up to date: calculation is triggered by an event — a large position arrives, the price on a venue moves, the composition changes — and it takes minutes, not hours of manual exports.
The horizon, confidence interval, and set of factors are set in the profile configuration, so changing the methodology does not turn into editing formulas in spreadsheets.
Accuracy rests on a single price source: venue feeds are consolidated into one data mart, discrepancies between them are visible immediately and measured in fractions of a percent.
The assessment no longer depends on whose quote an analyst pulled before a meeting, and the discrepancy between venues becomes a metric visible on a chart rather than a surprise in a report.
Limit control moves from the end of the day to the moment of the trade.
The rule checks the remaining amount for each instrument and for the portfolio on every position update, and a limit breach is sent as a notification to the responsible person — the failure class "limit breached unnoticed" simply stops reproducing.
The assessment history in a ClickHouse data mart allows an incident to be investigated by any slice after the fact.
The share of manual operations falls along with this: reconciliations, manual recalculations, and consolidation of exports move into the calculation loop, while the analyst is left with interpreting the result. Next, we break down what makes such speed possible at the level of the calculation and data loop.
VaR Calculation Methods: When Each Approach Works
No single method provides a correct assessment on its own — the choice is determined by portfolio composition, history depth, and limit recalculation frequency.
For a crypto portfolio this is critical: the market operates around the clock, liquidity is fragmented, and a crash on one venue is not repeated in another venue's history.
VaR calculation methods are compared along three axes: how they handle rare events, how many computational resources they require, and how robust they are to nonlinear positions. Below is the selection matrix we use in design.
| Approach | When It Fits | Limitations |
|---|---|---|
| Historical simulation | Liquid instruments with a long price series, an explainable assessment is needed | Sees only what has already happened: a new class of events will not enter the window until it occurs; the weight of an old crash persists until it exits the window boundary |
| Parametric method | Mass recalculation across many portfolios, frequent limit control | Relies on the distribution shape: fat tails and rising correlations under stress are underestimated, and it produces bias on nonlinear positions |
| Simulation-based calculation | Nonlinear positions, scenario analysis, rare-event assessment | Demanding in resources and in calibration of distributions and relationships between assets: an error in them is not visible in the figure itself |
Model limitations are not removed by choosing a single method — they are addressed at the architecture level: parallel calculation with two approaches, reconciliation against actual drawdowns, and a separate layer of stress scenarios for events absent from the statistics.
This combination, rather than the formula, determines whether a VaR system for a crypto portfolio will survive the next sharp reversal.
Implementation Stages: From Data Audit to Handover of Policies
The work sequence is structured so that the model cannot be handed over without testing on data that was not used in its calibration. Each stage is closed with an artifact — a description, diagram, or quality report — and the next does not begin until the client has accepted it. This way, implementing a risk system does not turn into a black box.
- Data audit. We inventory the sources: exchange accounts, wallets, OTC positions, staking accruals. We look for gaps, duplicates, time zone discrepancies, and "stuck" quotes on illiquid pairs, and fix the rejection rules and minimum acceptable history.
- Aggregation schema. We bring trades, balances, and funding rates onto a single timeline, agree on which price is used to value the portfolio at interval close, and where the history of portfolio snapshots is stored.
- Calculation setup. We choose the method — historical simulation, parametric, or Monte Carlo — set the confidence level, holding horizon, and window depth, and separately describe how volatility clustering is accounted for; otherwise risk in a calm market will be understated.
- Model validation. Backtesting on periods excluded from calibration: we calculate the VaR exceedance rate, examine behavior during sharp crashes and in sideways markets, and compare against expected tail losses. If the model fails, we return to the parameters rather than "tweaking" the result.
- Parallel run. Calculation runs alongside live trading in observation mode, results are reconciled with the risk manager's assessments, and discrepancies are investigated until resolved.
- Policies and handover. We provide rules for revising parameters, limits, and the escalation procedure, a snapshot backup scheme, train the team, and support the first calculation cycles.
Documentation Package: Configurations, Schemas, Limit Policies
Documentation is part of the delivery, not an appendix to it. A VaR system remains manageable without us only when its parameters, boundaries, and responses are described so that a new risk manager can understand the calculation without calling the team.
That is why the package is assembled in parallel with the calculation loop and versioned: every change to a limit or confidence level leaves a trace — who, when, and on what basis.
- Calculation configurations — confidence levels, horizons, assessment windows, recalculation frequency, list of quote sources, and rules for selecting among them when prices diverge.
- Data flow schema — the path from market data and account balances to the data mart and report: where normalization happens, where reconciliation happens, and at what point portfolio state is recorded.
- Limit matrix — breakdown by instrument, account, strategy, and division: who approves, who is authorized to temporarily expand, and for how long.
- Limit policies — what counts as a breach, after how many observations escalation is triggered, and which steps become mandatory.
- Instructions for the duty shift — a step-by-step shift walkthrough: where to view the calculation, how to check a discrepancy, what to record in the log, and when to involve a manager.
- Failure policy — behavior when a quote source is unavailable or there is anomalous dispersion: last reliable point, data quality flag, pause in calculation.
- Model description and its boundaries — assumptions, on which class of market scenarios the assessment understates tail risk, and how to read the historical backtesting report.
- Change log — history of limit and parameter edits with justification for each.
The package is handed over in editable form together with an acceptance checklist. As long as even one artifact is missing, the work is not considered complete.
Case Study: How Portfolio Risk Assessment Latency Was Reduced
A team managing a crypto portfolio came to us: value-at-risk calculation ran as an overnight batch job and took 40-50 minutes.
Venue data was collected from different sources and was not aligned in time — for the same pair, the discrepancy reached 10%, so limits were checked against an outdated picture.
We implemented a unified normalization layer: venue quotes are brought to a common snapshot time, duplicates and outliers are cut off, and the source is recorded in the calculation itself.
On top — event-driven recalculation: when a position or price moves, only the affected part of the portfolio is updated, not the entire instrument set.
We calculate portfolio VaR using historical simulation and Monte Carlo on a single scenario set so that assessments remain comparable across periods.
CoinGecko remained a source of reference prices for reconciliation, but limit decisions are made on the portfolio's own data.
What Changed in the Numbers
Recalculation now takes under a minute instead of 40-50 minutes, and cross-venue discrepancies dropped from 8-10% to fractions of a percent.
A limit breach is visible within minutes, not the next morning, and the signal arrives automatically — the decision is made based on data at the moment of triggering, not yesterday's slice.
How Does Stress Testing Differ from Scenario Analysis?
Stress testing answers the question "what happens if," while scenario analysis answers "how it will unfold." In the first case, we deterministically set a shock by factors and instantly recalculate the portfolio; in the second, we build a consistent trajectory of several factors over time while preserving correlations between them.
That is why stress captures an instantaneous rupture, while a scenario captures the accumulation of losses step by step.
They cover different risk classes. Stress testing takes the tail: a break in historical correlations, a volatility spike, a liquidity drawdown in the order book, a cascade of forced liquidations on leveraged exchanges.
A statistical VaR model barely sees such events — they lie outside its sample. Scenario analysis is responsible for sequence risk: how the rate, liquidity inflow and outflow, and collateral revaluation add up to a margin drawdown.
Reverse stress testing flips the logic: we fix an acceptable drawdown and search for a combination of factors that produces it.
The output is not a probability but a list of vulnerabilities: which position and which relationship between instruments must break for the portfolio to breach a limit. Then we either cut concentration or hedge the specific factor.
The limitations are mutual. A stress test depends on the choice of shocks: one can run comfortable values for a long time and fail to see a real vulnerability.
Scenario analysis depends on history completeness — for new instruments the series is short, and correlations are estimated unstably.
Therefore, in a VaR system, both tools sit alongside statistical assessment: stress as daily limit control, scenarios as a basis for revising portfolio and hedge structure.
Technical Concerns: Data Quality and Calculation Robustness
Data from different venues arrives with different precision, different aggregation lag, and different history depth — if it is consolidated "as is," the model starts calculating noise.
That is why normalization is the first layer: a unified time grid, outlier cutoff by median and median deviation, marking gaps instead of filling the series, and a quality label on each point.
A saved quote slice allows the calculation to be replayed — it is clear what produced a specific VaR figure.
What should be done with illiquid instruments?
For thin markets, the assessment is built differently: instead of the last trade, a conservative exit scenario with a slippage buffer.
Such an instrument gets a loss range rather than a single number, and a separate note "model-based valuation, not market-based." Then you decide: limit the position weight or keep it as a separate risk line.
How does the model behave during sharp moves?
Historical simulation is blind to a scenario that was not in the sample. That is why we calculate in combination: history, stress scenarios for sharp ruptures, and parametric tail assessment.
Historical backtesting shows the number of exceedances versus the expected number — if the actual result breaches the boundary more often, calibration changes, not the report.
What happens after launch?
We hand over the policy: recalculation schedule, quote quality checks, procedure for connecting a new venue, and the reaction window for a failure.
When the set of exchanges or the data source changes, the calculation is rebuilt — without this, risk assessment quietly diverges from portfolio reality.
Let's Discuss the Task: Where to Start with Portfolio Risk Calculation
To come back with a work plan and project estimate rather than general thoughts, we need inputs on the portfolio: from them we will determine the calculation model, the volume of historical data, and the recalculation architecture.
Send what you already have — a trade export, a list of venues, or simply a description of how capital is currently allocated. That is enough to discuss the task substantively.
- Asset composition and weights, including staking, loans, and leveraged positions — they create nonlinear risk that a standard covariance model does not capture.
- Custody venues: exchanges, custodial services, non-custodial wallets — this determines how capital availability and liquidity gaps are calculated.
- History depth: trades, quotes, periods of venue downtime. The longer the series, the more robust the tail distribution estimate.
- Risk horizon and confidence level, as well as the recalculation policy — on a schedule or before every trade.
- Price sources and the selection rule when venues diverge: weighted average, median, outlier cutoff.
- Reporting and access requirements: which roles see summary metrics and which see position-level detail.
- Integration points for the result: risk dashboard, trading bot, regular exports for management.
Describe the task in your own words and attach the inputs — we will come back with a work plan, calculation schema, and estimate. If there is little data so far, we will start by reviewing what exists and separately identify what is missing.