Developing a Sortino Ratio calculation system for crypto strategies

Why Sortino Ratio distorts crypto strategy evaluation

Sortino Ratio divides a strategy's average return by downside deviation only. On a stream of hundreds of similar trades, the formula works.

In crypto strategies, the result is often driven by 3-5 large positions per month, while the remaining intervals are closed at zero: averaging over calendar windows dilutes the outlier, and deviation is calculated from the noise of empty periods.

The second source of distortion in the risk metric is the minimum acceptable return threshold. If it is set as the strategy's own average return, the metric becomes a tautology: the stronger the strategy, the higher the threshold and the more of its trades are counted as risk. The ranking flips—first place goes to a smooth stream of small trades.

The formula does not see the order of trades or the depth of a strategy's drawdown.

Two portfolios with the same set of returns but a different sequence produce different drawdowns: a series of consecutive losses leads to margin requirements and forced liquidation of positions, yet the metric is the same for both. Recovery time after a drawdown is not included in the calculation at all.

The outcome is predictable: a strategy with rare large trades and controlled risk loses in the ranking to a strategy with frequent small noise that draws down deeper and recovers longer.

We explain how we address this in strategy return evaluation: we calculate by trades, not by calendar windows, and add drawdown and recovery time.

What a correct Sortino Ratio calculation provides

A correct calculation starts with one convention: only returns below the target level go into the deviation, not the entire dispersion.

If one team calculates semivariance from zero and another from the risk-free rate, two strategies with the same risk profile get different coefficients, and comparability of strategies is lost.

We separately fix the series frequency and rules for annualization: daily and hourly data produce different values if aggregation is not specified.

On short samples the coefficient is unstable, so we calculate the confidence interval using a permutation test and discard strategies where the lower bound does not exceed one—this way drawdown-based risk assessment is not broken by a single outlier.

We calculate drawdown by a single rule: depth from peak to trough, recovery time to a new peak, and time under water.

Then crypto strategy metrics become a reproducible number rather than the result of manual edits in a spreadsheet, and the rationale for strategy selection relies on methodology disclosure in the spirit of GIPS, not on a convenient sample period.

Calculation formats: historical, trade-based, hybrid

Sortino Ratio calculation is not limited by the formula but by the source of returns. We support three modes for calculating the metric: calculation on historical data, calculation by trade flow, and hybrid, where a long history is supplemented with actual executions. The chosen mode sets data requirements and the metric's stability over short windows.

How to choose a mode

With historical data, the result is comparable across strategies but smooths out rare drawdowns. Trade flow reflects actual returns more accurately, but on a short sample the metric is noisy.

The hybrid covers the lack of depth but requires an explicit boundary: where history ends and the execution journal begins. We fix this rule in the calculation configuration so that a repeated recalculation on new data gives the same result.

How the coefficient calculation system is built

The Sortino Ratio formula fits in one line, but the outcome is largely determined not by it, but by what went into the return series and how the downside deviation was agreed to be calculated.

We break down the sequence of work by which the calculation is brought from raw exports to a procedure that can be trusted over a long history.

1. Audit of data sources and completeness. We reconcile exports from trading systems and exchange reports, looking for missing periods, duplicate trades, time zone discrepancies, and operations that did not make it into any report.
2. Normalization of trade data. We bring everything to a single time scale and one accounting currency, unwind partial fills, allocate commissions and position rollover fees across trades, and mark restored and estimated records with a separate flag.
3. Agreement on the calculation scheme. We fix the target return, window length, recalculation step, method of aggregating returns, and the rule for handling incomplete periods so that the result does not change when the person doing the work changes.
4. Implementation of the calculation system. We assemble the calculation core, version the methodology together with the code, run it across all available history, and compare against control examples calculated manually.
5. Checking the stability of the result. We shift the window, change the step, remove individual outliers, and examine crisis periods separately: the coefficient should not jump from cosmetic edits in the data.
6. Recalculation procedure. We describe the triggers—new data arrival, history refinement, methodology change—the version approval procedure, and how to return to a previous calculation.
7. Handover and acceptance. Methodology documentation, a monitoring dashboard, alerts about discrepancies with the previous calculation, and training for your team.

Each stage is closed out with an artifact: a source map, a field specification, test windows, and a signed methodology version. This way the result is reproducible months later and does not depend on who exactly launched the recalculation.

Configurations, schemes, and recalculation procedure

After implementation, the client's team retains not only a working service but also a set of artifacts by which the calculation can be checked, developed, and handed off between engineers without us. Below is the minimum set that we fix at acceptance; each item has an owner and a storage location.

• Calculation configurations — evaluation window, minimum acceptable return, recalculation frequency, annualization rules, handling of gaps in quotes; with a description of each parameter and default values.
• Calculation pipeline scheme — the path from receiving quotes and trades to publishing the metric: where data is normalized, where downside deviation is isolated, where results are aggregated by strategy and period.
• Calculation documentation — Sortino formulas, outlier trimming rules, behavior when downside deviation is zero or close to zero, choice of base return, and walkthrough on historical series.
• Reference examples — short return series with pre-calculated values: running them shows whether the metric has shifted after code changes.
• Data access policies — roles, read-only connections to sources, segregation of historical series, and an access log for sensitive fields.
• Recalculation procedure — run schedule, reproducibility of results for the same input, versioning of calculations, procedure for loading additional history and recalculating closed periods.
• Incident instructions — typical source failures, discrepancy with the control value, rollback to a previous calculation version, and the notification procedure for responsible parties.
• Handover to the team — code walkthrough with the client's engineers, session recordings, responsibility matrix, and a list of initial improvements.

Case study: strategy evaluation in a volatile market

A portfolio manager of crypto strategies came with a specific problem: ranking by Sortino Ratio did not match how the strategies behaved after launch.

The metric was calculated using the standard deviation of all returns, without a minimum acceptable return or horizon normalization. In a volatile market, the conclusion came out inverted: a strategy with rare failures looked more stable than one that grew with short pullbacks.

Where the methodology broke

The review showed three sources of discrepancy. Price series from CoinGecko and from exchange exports arrived at different frequencies; gaps were filled by carrying forward the last price—rare crashes were lost.

Returns were not annualized, so strategies with different history lengths could not be compared. And the denominator used total volatility, although Sortino penalizes only negative deviations.

What we changed

We rewrote the calculation: downside deviation was calculated relative to a specified minimum acceptable return, the horizon was annualized, and gaps in the series were restored by a single rule.

Before the transition, out of forty strategies, eleven entered the portfolio and after launch did not confirm their risk profile, while two strong ones were filtered out as insufficiently profitable.

The spread of estimates between analysts reached 0.8 points, and the report took two days to assemble.

After the transition, erroneous exclusions dropped to two cases, the spread of estimates fell below 0.05, the report is generated automatically, and portfolio composition decisions are made on comparable numbers.

How drawdown-based evaluation differs from volatility-based evaluation

Volatility-based evaluation is symmetric: return deviations both up and down enter the calculation equally. Therefore, a strategy with rare large profitable trades receives an inflated risk estimate—growth inflates the standard deviation even though there were no losses.

Drawdown-based evaluation takes into account only deviations below the minimum acceptable return.

The denominator of such a metric is the mean square of negative deviations, not the full dispersion; this is exactly the logic laid down by Sortino, separating the penalty for loss from the reward for profit.

The difference shows up in asymmetric distributions. For trend-following, option, and event-driven strategies, volatility systematically understates risk, and comparing risk metrics by it produces the wrong order.

For market-neutral arbitrage, the distribution is close to symmetric, and both metrics rank strategies almost identically.

The choice depends on the question: "how widely does the result swing" or "how much do I lose when I am wrong." For strategy selection and drawdown control, the second is closer; volatility remains useful for estimating position size and capital load.

Metrics can be compared correctly only with the same calculation window, the same recalculation frequency, and the same return threshold. Moving from daily to weekly frequency changes both numbers so much that the conclusion about a strategy's superiority can flip.

Technical concerns: data, recalculation, stability

Any doubt about Sortino calculation comes down to three questions: where the return history comes from, what exactly happens during recalculation, and whether the result repeats.

The metric is built on downside deviations relative to the target return, so it is sensitive to gaps in the series, isolated sharp drops, and changes in strategy composition. Below is an analysis of the objections that most often surface before the start.

The strategy changed composition—does the metric remain comparable?

Rebalances are stored as separate events with dates and weights. A continuous segment is calculated only between adjacent changes, and when comparing periods you can see what each one relies on. A figure for a long interval without this markup hides a change in logic, so we do not publish it.

How stable is the result to a single severe drop?

Each value is accompanied by a stability assessment: the same metric is recalculated on a truncated series and with the worst day excluded. If the spread of versions is large, it is visible in the report, and such a strategy should not be relied on when selecting. Additionally, the share of days that fell into the downside part is output.

Can the figure be reproduced months later?

The calculation code version, a snapshot of input data, and window parameters are fixed together with the result.

The same input gives the same value, and any change to calculation rules is logged with a date—otherwise the dispute "why was it different in the previous report" is unresolvable.

Let's discuss the task and come back with a work plan

To make the evaluation substantive rather than market-average, let's discuss the calculation task on your data. Describe the return sources and your set of strategies—this is enough for us to come back with an implementation plan, timelines by stage, and scope of work.

What helps us calculate accurately:

• data sources: exchange exports and quote archives, history depth, snapshot frequency, handling of gaps and weekends;
• strategy composition: how returns are calculated, when rebalancing occurs, how idle periods and cash inflows/outflows are accounted for;
• the base rate against which you calculate excess return—the entire Sortino Ratio logic and interpretation of the result depend on it;
• calculation window and frequency: scheduled or event-driven recalculation, whether a history of values and comparison of strategies with each other are needed;
• result format: a report for the manager, an export to your accounting system, or calculation within your environment;
• reproducibility requirements: a log of methodology versions and weight changes so the calculation can be defended before an investor;
• deployment environment and access: where data is stored, who sees the results and at what level.

After the review, we will come back with a timeline estimate and a step-by-step plan. Next—a pilot on one strategy direction, reconciliation of the calculation with your current methodology, and rollout to the entire portfolio.