Basic Prerequisites: 01 · Event-Driven Backtesting from Zero. No live-trading experience needed.


1. Intuition & Practical Objective

This page builds the why of production trading systems with no live-trading background needed. The objective is one idea: a profitable backtest is evidence about a strategy, not evidence about a system - and the gap between the two is where every trading disaster lives.

Start with the dumbest question: I have a strategy that made 40% in the backtest. Why is that not enough to trade it? Because the backtest is a statement about a number, and going live requires a statement about a machine. The machine has to receive market data, decide, place orders, track its own position, pay for its trades, recover from a dropped connection at 09:31 on a volatile open, and - crucially - stop itself when it turns out to be wrong. None of that is in the backtest, and all of it can lose more money in an afternoon than the strategy makes in a year.

Three steps:

  1. The backtest is a conditional statement. “Given perfect data, instant and complete fills, zero operational risk, and a strategy that never misfires, this earns 40%.” Production removes every one of those conditions at once. The realistic question is not “does the edge exist?” but “is the edge larger than the sum of everything that will go wrong?”

  2. Costs are a turnover tax, and the strategy is the thing that pays it. Each unit of turnover costs you the spread plus impact; a strategy that turns over 200× per year at 6 bps one-way hands back its entire 12% gross edge. High-frequency strategies are not more profitable per trade - they are the ones for which the tax is the dominant term.

  3. Production risk is asymmetric and event-driven. A strategy’s P&L is roughly symmetric around its mean; a production incident is a one-sided jump - it only ever loses. A single −30% incident erases five years of a 6%/yr edge. So the correct posture is not “maximise expected return” but “bound the worst case at every layer, then worry about return.”

The reframe. A backtest is a search (see Backtesting Hygiene); a production system is a control system. The control system’s quality is measured in the tails: how fast can it detect a malfunction, how much can it lose before it does, and how surely can it go flat?


2. Mathematical Ground Truth & Derivations

2.1 The turnover tax and the break-even condition

Let be the gross annualised return, the annualised volatility, the one-way cost in basis points (half-spread + impact + fees) paid on each unit of traded notional, and the turnover in units of NAV traded per year. The net return is

The strategy is tradable only while , i.e. while

is the break-even turnover. At and bps, - a strategy that trades more than 200× NAV per year has no edge it can keep. This single inequality kills more high-Sharpe backtests than any overfitting concern.

2.2 Why the worst case dominates: the multiplicative incident model

Suppose a year produces a gross return but with probability suffers a production incident that destroys a fraction of capital. The expected log-growth (the quantity that actually compounds, per the Kelly framing) is

The lesson is in the sign structure: the strategy term grows with (linear-ish), the incident term grows with and is independent of the strategy. You cannot out-return a production incident - you can only lower (testing, canaries) or lower (risk limits, kill switches). That is exactly what the rest of this folder builds.

2.3 Years-of-edge destroyed

A cleaner expression of the same fact, used in the runnable example below:

A single 30% loss against a 6%/yr net edge erases 5.0 years of careful work. Production is therefore best understood as capital preservation with a P&L side effect.


3. Computational Implementation - backtest vs live book

Stdlib only. Part 1 is the cost-drag table and the break-even turnover; part 2 converts a single operational incident into the years of edge it destroys.

Read it as the two-sided tax on going live: costs scale linearly with turnover and cap how much edge you keep; incidents scale with nothing you control and cap how long you keep it. The backtested Sharpe of 2.00 became a live 1.00 from costs alone, and one incident then sets you back five years.


4. Failure Modes & First-Principles Breakdowns

  1. Optimising the wrong objective. Maximising backtest Sharpe selects, all else equal, for higher turnover - which is precisely the direction that raises the cost tax. Production teams therefore optimise a different functional: net Sharpe, subject to bounded worst-case loss.
  2. Assuming the model gap is small. The live-vs-backtest divergence is not noise; it is systematic (costs, latency, partial fills, regime). A −4% net return at 300× turnover is not “the strategy underperforming,” it is the tax doing what the arithmetic says it must.
  3. Ignoring the operational term entirely. Backtests assign zero probability to “the process crashed mid-open.” The empirical base rate of serious production incidents is high enough that a firm trading the same strategy for a decade will experience one; the only question is how much it costs when it happens (see 05 · Failure Modes).
  4. Confusing edge with capacity. A strategy that only works at $1M of capital is not broken; it is capacity-limited. Production sizing must respect this, or the cost term ( size relative to available liquidity) silently grows until .

5. References

  • Narang, Inside the Black Box, 2nd ed.
  • Davey, Building Winning Algorithmic Trading Systems
  • Carver, Systematic Trading
  • López de Prado, Advances in Financial Machine Learning
  • Beyer et al., Site Reliability Engineering (O’Reilly, 2016)

6. Connected Graph Bridges