Development of a Cryptocurrency Volatility Forecasting Model

Volatility forecasting: where manual risk assessment breaks down

Manual market risk assessment relies on the latest notable move: an analyst takes the daily range, compares it with the previous week, and carries the scale over to the future horizon.

This approach breaks down when the regime changes — cryptocurrency volatility clusters, and the transition from calm to a spike happens faster than the estimate updates.

A lagging signal here is not an executor's mistake but a property of the method: it averages what has already happened.

The second failure point is a single averaged model for all market states.

Trained on all available history, it outputs "average" volatility and systematically underestimates the tails: in a sideways market it overstates risk and slows down the logic, while in a cascade of forced liquidations it understates risk and misses the moment when the position needs to be reduced.

A calm trend, a sideways market, and a liquidation spike are described by different features and require different trigger sensitivity.

A working risk model is built on features that change earlier than price: realized volatility across several horizons, spread and order book depth, funding rates, open interest, share of forced liquidations, and the behavior of the leading asset.

Volatility forecasting here is not price prediction but dispersion estimation: how wide the move will be over a horizon from an hour to a week and with what probability it will exceed a given threshold.

Next we break down how this is covered: what data we collect, how we separate market regimes, and how we validate forecast quality on historical windows.

What the model delivers: accuracy, robustness, reaction speed

We evaluate volatility forecasting by four measurable properties: estimation error on a holdout period, robustness to market regime changes, reaction time to an anomaly, and the horizon over which the forecast retains its power.

Baseline models of the GARCH family provide a decent starting point, but during liquidity gaps and news shocks their error grows many times over — exactly where the forecast is needed most.

We measure model accuracy as the share of periods where actual volatility fell within the predicted corridor: average error smooths out the spikes for which the model is built.

We fix the evaluation horizon in advance and calculate metrics separately for each one — a model confident on a short window often loses quality on the adjacent one.

We test model robustness on historical stress scenarios: crash, sideways market, sharp rally, liquidity gap. The one that passes selection is the one whose estimation error remains within the working corridor instead of increasing many times over.

Separately, we look at degradation — how much quality drops if the model is not retrained on fresh data for a long time.

Reaction time to an anomaly most often determines the outcome. The system compares realized volatility with forecast volatility and raises a signal when the divergence crosses the threshold; on streaming data this takes seconds instead of waiting for the candle to close.

This eliminates a whole class of failures: decisions made based on a model that no longer describes the current market regime.

Calculation modes: statistics, machine learning, ensembles

The calculation mode determines over what horizon the volatility estimate remains workable: hours, days, or weeks.

It makes sense to compare approaches not by accuracy on a single lucky historical segment but by robustness to market regime changes, interpretability of the result, and maintenance cost.

In practice, we work with three classes: a statistical model, machine learning on features, and an ensemble of models. Statistics are transparent and behave predictably on a short series, but they smooth out nonlinearities.

Learning from data captures complex relationships, but it requires a long history and protection against overfitting. An ensemble of models smooths out the failures of individual components — at the cost of more complex control.

We fix the choice based on the task: for margin requirement calculation, robustness and interpretability matter more; for short-term liquidation risk assessment, reaction to changes matters more. Next we show how this connects with the rest of the system.

Implementation stages: from data audit to model handover

The work stages are arranged so that each next phase relies on the verified result of the previous one: we move forward only when quality metrics are fixed and reproducible.

This lengthens the start, but it removes the need to rework the model at the moment when it is already embedded in the trading or risk loop.

1. Data audit. We collect the history of quotes and volumes, check the continuity of series, gaps during trading halts, and the correctness of missing-value imputation, and separately look for future value leakage in historical features.
2. Feature preparation. From raw series we assemble volatility and liquidity features, bring them to a single time step, and calculate them on rolling windows — the model should see the market regime, not a single candle.
3. Model design. We choose the model class for the forecast horizon and data frequency, agree on error metrics and on what result we consider acceptable in a calm and in a sharp market.
4. Assembly and training. We train on one segment of history, tune parameters on the second, and perform the final evaluation on the third — one the model has never seen.
5. Validation. We run the forecast on a holdout period and on stress segments, compare it with a simple baseline forecast, and look at where the model consistently underperforms — such scenarios go into refinement, not into a presentation.
6. Model deployment. We wrap the calculation in a service, configure the recalculation schedule, monitoring of forecast-versus-actual divergence, and rollback to the previous version without stopping operations.
7. Handover and team training. We hand over the code, configurations, and decision rationale, and train your engineers and analysts so that you can retrain the model and edit features yourselves.

Each stage is closed by an artifact: a data report, a feature set, a specification, validation results, a working service, and documentation. No item is considered done "in words" — you retain a reproducible result and a team that understands how to maintain it.

Handover package: model code, reports, recalculation procedure

We assemble the package so that the model can be rerun and revalidated without us: from raw data to artifact, using a fixed launch command and pinned dependencies. Below is what exactly remains with your team and in what form it is applicable in work.

• Model code — training and evaluation in a single run, fixed random seeds so that a repeated run on the same data yields the same result.
• Environment configuration — pinned dependencies, image, and launch variables: deployed on your hardware, without "it only works on the author's machine."
• Model documentation — what features are at the input, what the forecast horizon is, on what window the error is calculated, and where the model must not be applied.
• Quality report — error metric on the holdout segment, comparison with a simple baseline estimate, breakdown by calm and volatile market.
• Data checks — rules for missing values, outliers, and quote gaps, a log of triggered checks indicating source and time.
• Recalculation procedure — by calendar or by input data shift, the order of retraining and acceptance of a new version before it is used.
• Divergence monitoring — a "forecast versus actual" dashboard, alert thresholds, and the procedure for rolling back to the previous model version.

Case study: how risk assessment accuracy changed during sharp moves

Before: error diverged in a stormy market

The model was trained on the history of calm periods, and trigger thresholds were set by the absolute magnitude of deviation.

In a calm market, forecast error stayed within 4-6%, and the risk service considered the estimate adequate; during sharp moves, the error spread diverged to 30-40%, and the share of missed anomalies reached 38%. Limit decisions were made after the fact — when the move had already happened.

What was changed

The scheme was split into two components: a stochastic volatility model for the baseline level and regime switching, which is trained separately on compression and expansion periods.

Alert thresholds were tied to quantiles of the residual distribution instead of absolute deviation, so that the signal would not depend on the current price scale.

Calibration was checked against Deribit implied estimates: the divergence between model and market expected volatility was analyzed separately rather than averaged.

What the result was

The share of missed anomalies decreased from 38% to 9%. In a stormy market, the error spread was reduced by about half — from 30-40% to 14-18% — and remained manageable during events when the price moves several percent in minutes.

In a calm market, accuracy did not degrade: the error remained within 3-5%, meaning the improvement was not bought at the cost of false triggers.

The forecast interval began to widen 15-40 minutes before the spread increased — such a leading signal did not exist before. Limits were reduced in advance, not urgently after the fact.

How volatility forecasting differs from price monitoring

Price monitoring answers the question "how much the asset is worth right now" and updates upon a trade. Volatility forecasting answers a different question: how wide the return dispersion will be in the next window — an hour, a day, a week.

This is not a refinement of the first loop but a separate task with different input data, a different recalculation frequency, and a different cost of error.

Monitoring is a stream of recent trades and threshold alerts, that is, a reaction to what has already happened.

Dispersion estimation is built on leading features: range compression before an impulse, order book imbalance, a spike in forced liquidations, a jump in funding rates on perpetual contracts.

A separate layer is implied option volatility: on a major options venue such as Deribit, it is quoted directly, meaning the market itself pays for the right to lock in future dispersion.

This leads to a difference in application.

Risk indicators built on dispersion forecasting provide a time buffer: maximum leverage is reduced before the impulse, not after it, position size is recalculated in advance, and automatic hedging turns on when expected dispersion widens.

Risk limits tied only to the current price trigger at the moment of the move — when a decision can no longer be made at an acceptable price.

In practice, the loops are separated as follows: price monitoring catches execution failures and liquidity anomalies, while volatility forecasting protects against losses during a sharp widening of dispersion.

They cannot be mixed into one — otherwise thresholds either lag or suppress normal operation in a calm market: a model trained on daily data will not see an intraday spike, and hourly estimates overstate risk on a trending segment without pullbacks.

We separate these loops at the level of data, horizon, and thresholds, not at the level of reports — below we show how this is structured in our work.

Technical concerns: data, overfitting, support

Before work starts, the client's technical team asks almost the same set of questions: where the data comes from, how we make sure the model has not memorized history, what happens when the market regime changes, and who is responsible for the model's operation after handover. Below are direct answers, without promising that "the forecast is always accurate."

We close these questions during design, not after launch: the answers determine the data collection scheme, the set of checks, and which quality metrics go into the report. If we cannot agree on some point, that is a reason not to start, not to "tune it along the way."

What about data quality and missing values?

Missing values are the norm, not a failure: venues go down for maintenance, and some sources provide history with gaps. We do not fill them with the mean; instead, we mark them, move them to a separate layer, and record them in the report indicating source and period.

We check data quality by formal rules — duplicates, outliers, price divergence between sources — and every dataset passes this check before training.

How do you track data drift?

Drift is a change in the statistical properties of a series: a calm market and a sharp transition behave differently, and a model tuned for one regime loses accuracy in another.

We maintain control over the distributions of input indicators and forecast quality, and retrain the model on a schedule or when a threshold is triggered.

When boundaries are exceeded, the forecast weight is automatically reduced so that decisions do not rely on an outdated configuration.

What does model support include?

The retraining procedure, quality monitoring, degradation alerts, a run log with reproducible results, and the procedure for rolling back to the previous working version. Separately, we define who launches retraining and based on what signal.

Without this, the model survives only until the first market change — that is why we describe support before the start, not as an addition to handover.

Let's discuss the task: data, access, work plan

Before naming timelines, we need the data composition and access to it — this determines which volatility forecasting models are applicable and how long their validation on history will take.

Below is the minimum set after which we will return with an estimate and work plan, not with clarifying questions.

• Instruments and horizon. Which assets and pairs we build the forecast for, at what time step, how much history you provide — candles or individual trades, whether the order book and derivatives market data are needed.
• Data composition. Exports from your storage or exchange archives: record structure, frequency, known gaps and breaks, how trading halts and delistings were handled.
• Data access. Read-only keys, a test environment, an archival storage; who on your side issues and renews access, and what the requests depend on.
• Target risk metric. What we consider the forecast: next-step volatility, probability of exceeding a threshold, or the trigger moment of a protective rule. This determines the method of quality validation.
• Usage mode. Scheduled report, alert, or automatic position management; acceptable false trigger rate and required response delay.
• Launch and acceptance loop. Where we compute, where we write the result, how often we retrain the model, who accepts the work, and by which numbers we compare forecast with actual.

After that, we fix the work plan: preparation of series and features, model selection, validation on historical periods, launch, and monitoring of forecast-versus-actual divergence.

Describe the task within these boundaries — we will return with an estimate, timelines, and team composition; work starts with agreement on the metric and data, not with environment setup.