Introducing Backtest Results Analysis

Today we're launching the Finterion Backtest Results Analysis dashboard, a fundamentally new way to understand, compare, and validate algorithmic trading strategies at scale. This is not an incremental improvement on existing backtest tooling. It is a rethinking of how research results should be stored, structured, and explored.

The problem with backtest analysis today

Every quant developer knows the problem: you run dozens of algorithm variants, export result files, open a spreadsheet, and start manually tracking which Sharpe ratio belongs to which parameter set, which date window, which universe. You re-run a strategy with a small tweak and overwrite the previous result. Three weeks later nobody remembers what the "v4_final_REALLY_FINAL" file was testing. Comparisons collapse into a pile of disconnected exports.

The underlying issue is structural. Traditional backtesting systems treat each result as an independent artifact. There is no shared language between runs. No automatic recognition that two different algorithms were tested against the same walk-forward windows. No way to query "show me every algorithm that ran this study, sorted by risk-adjusted return" without rebuilding that context by hand each time.

Finterion solves this at the data layer — before any chart is drawn.

A research graph, not a results archive

At the core of Finterion's analysis infrastructure is the Bundle — a long-lived, content-addressed research graph that is the unit of analysis for every query on the platform.

When you upload a backtest result, the platform doesn't store a file. It decomposes the result into its structural parts and stores each one exactly once:

• Studies — what research question does this backtest answer?
• Windows — which time ranges were tested (train split, test split, gap days)?
• Universes — which assets and markets were in scope?

These definitions are deduplicated by content hash across the entire bundle. Upload fifty algorithm variants all sharing the same walk-forward windows and those windows are stored once — not fifty times. Every subsequent algorithm that uses the same date range automatically references the same window entity. The research structure of your project becomes a shared, queryable graph rather than a by-product of individual uploads.

This separation — between what you are testing (the definition layer) and what happened when you ran it (the execution layer) — is what makes the analysis dashboard possible.

Walk-forward analysis as a first-class concept

Walk-forward validation is the gold standard for avoiding look-ahead bias in strategy research. Yet every mainstream backtest platform treats it as a bolt-on: a convention, not a data structure.

In Finterion, each walk-forward window is an entity in the research graph. Every algorithm run is linked to the exact window it executed against, with train start, train end, test start, test end, and gap days stored precisely and queryably. The dashboard surfaces this structure directly: select a study, select a window, and instantly see every algorithm's equity curve for that specific out-of-sample period — aligned, overlaid, and comparable.

You can see exactly where an algorithm's edge degrades across time periods, which windows drive aggregate Sharpe ratios, and whether performance is consistent across regimes or concentrated in a single lucky window. This level of drill-down has previously required custom data pipelines built by each research team in isolation.

Atomic re-upload, preserved research graph

A common source of confusion in strategy research is what "re-running" a backtest means. Did the algorithm change? Did the parameters change? Was it the same strategy on new data?

Finterion handles this precisely. When you re-upload an algorithm variant to its existing bundle, the execution layer — summaries, runs, metrics — is replaced atomically in a single transaction. But the definition layer is never touched. The research graph that describes what is being tested survives every re-upload intact.

If a re-upload introduces a new study or a new walk-forward window, the new entity is added to the graph. If it references an existing window (identified by its content hash), it simply links to the existing record. There is no duplication, no drift, no stale data.

Cross-algorithm comparison at scale

Because every algorithm in a bundle is mapped onto the same shared graph of studies, windows, and universes, cross-algorithm comparison is a first-class query — not a manual join.

The dashboard lets you select any combination of algorithms within a bundle and immediately see:

• Aggregate KPIs (Sharpe, CAGR, Sortino, Calmar, max drawdown, profit factor, win rate) side by side
• Equity curves per walk-forward window, per universe, per engine type
• Per-window breakdown of train vs. test performance to surface overfitting

You can pin a champion algorithm and compare it against a set of challengers — formally modelled as comparison groups within the bundle — tracking which variant is the current best performer and maintaining a full lineage of what was tried and when.

Built for research teams

The dashboard is designed for teams running serious systematic research, not one-off backtests. Multiple team members can upload results to the same bundle. The shared graph accumulates the team's research history over time — each upload enriches the graph rather than replacing it.

Query performance does not degrade as the bundle grows. All queries are bundle-scoped, indexes lead with the bundle identifier, and the content-addressed deduplication model means the graph stays compact regardless of how many algorithm variants have been uploaded.

Available now

Backtest Results Analysis is available today on Finterion. Upload your first bundle from the Research dashboard, or visit our documentation to learn more about the bundle format and how to export results from your existing backtest framework.

We built this because we believe rigorous quantitative research deserves rigorous infrastructure — and that the gap between running a backtest and truly understanding it should be zero.