On identical replayed jobs, FastBT posted a 486× peak speedup and a 3.7× median improvement across 306 real user backtests.
Validation methodology before cutover
Before the cutover, Tradetron replayed 306 real user jobs on the production fleet and checked every outcome. None would have been lost in the transition. In that same sample, one in five prior-engine runs had silently produced nothing — no fills, no report. FastBT's contract is fail-closed: every run either delivers a deterministic report or surfaces the error and refunds the compute cost.
- Median runtime improvement: 3.7×
- Slowest-decile runtime improvement: 42×
- Silent-failure rate under the prior engine: 20%
The failure profile is the more relevant number. A backtest that returns empty is operationally indistinguishable from one that completed unless the engine states otherwise.
Execution fidelity as the structural change
Raw throughput matters less than the model that consumes it. FastBT ships with audit layers that address documented sources of backtest overstatement:
- Data audit: NIFTY and BANKNIFTY option bars from 2020 through 2025 OHLC-validated bar-by-bar, ghost expiries removed, per-date lot sizes sourced from exchange circulars, weekly sweeps guarding against regression.
- Fill scoring: simulated fills replayed against real executed trades from live auto-trading deployments. Real money, real slippage.
- Statistical guardrails: walk-forward verdicts on every run, Probabilistic Sharpe ratios, Monte-Carlo ranges — shipped as default output.
- Report surface: 60+ metrics across 20+ sections — equity curves, drawdown decomposition, VIX-regime splits, leg and exit attribution, trades overlaid on real charts, a live cost lab.
Parameter sweeps rerun the full backtest once per value and present the results as a sensitivity grid. One constant changes, the entire result surface shifts. This is the workflow that disciplines curve-fitting.
MCP server: chat interface, not a parallel engine
FastBT exposes an MCP server permitting AI assistants — Claude cited by name — to trigger backtests through chat. The integration is a frontend layer on the same engine: same data, same fill model, same audit contract. Detailed latency and concurrency characteristics for MCP-mediated sessions are not in the release material.
What to verify before re-baselining strategies
- Re-run archived strategies on FastBT and diff fill sequences against any retained old-engine output. Material deltas indicate model changes, not infrastructure drift.
- Strategies approved under the prior engine should be re-validated. The old system's silent-failure rate means a fraction of historical runs produced neither fills nor reports, removing those data points from the record.
- For Indian options multi-leg structures, confirm lot-size handling across the 2020–2025 expiry series.
- Compute budgeting: the 486× figure describes specific job shapes. The 3.7× median describes actual workloads. Plan capacity around the median.
Risk-adjusted verdict: the headline speedup is throughput, not alpha. The structural change is the fail-closed contract, the fill-scoring layer, and the default statistical guardrails. Use the latency delta as capacity for parameter sweeps and walk-forward partitions — test more parameter surfaces, do not deploy faster.