Statistical arbitrage capacity is a slippage problem disguised as an alpha problem. The Statistical Arbitrage Capacity engine on a default pair (mean-reversion half-life 7 days, 36 trades/year, target Sharpe 1.5) returns a maximum theoretical AUM of $1B as its headline, while the capacity curve runs $6.76B at zero slippage, $4.84B at 1bp and $3.24B at 2bp — counter-intuitive numbers driven by the engine's slippage decay model, not by the trader's real-world fill rates. The practical capacity for retail is set by the half-life, not the slippage curve.
TL;DR
- Default scenario: mean-reversion half-life 7 days, 36 trades/year, target Sharpe 1.5.
- Engine maxAum: $1,000,000,000 theoretical.
- Capacity curve at 0/1/2/3/5 bps slippage: $6.76B / $4.84B / $3.24B / $1.96B / $360M.
- The curve crosses zero by 8bp — at 8bp and above the engine returns $0 capacity.
- Practical retail capacity sits 3-4 orders of magnitude below the engine's curve.
- The binding constraint is half-life × position-size, not headline AUM.
The scenario
A market-neutral pairs strategy on US equities1 with a 7-day mean-reversion half-life, executing 36 trades per year (3 per month, roughly matching the half-life-bounded turnover), targeting a Sharpe ratio of 1.5. The Statistical Arbitrage Capacity tool returns a theoretical capacity curve.
| Slippage assumption | Theoretical AUM |
|---|---|
| 0 bps | $6.76B |
| 1 bp | $4.84B |
| 2 bps | $3.24B |
| 3 bps | $1.96B |
| 5 bps | $360M |
| 8 bps | $0 |
| 12 bps | $0 |
The engine's maxAum field returns $1B as the published headline. The curve shows how that drops as the assumed slippage rises. At 5bp slippage the capacity is already down to $360M, and by 8bp — a realistic retail fill cost on mid-cap pairs — the engine returns $0: the average trade's slippage has fully cancelled its alpha.
Why the curve drops
The model assumes alpha per trade is fixed and slippage scales linearly with position size relative to average daily volume. Above a threshold position size, slippage exceeds alpha and the marginal trade is unprofitable. Capacity is the AUM level at which the average trade's slippage exactly cancels its alpha.
The curve is steep because the half-life is short. A 7-day half-life means the trade must close inside 7 days; the realised alpha is a function of the mean-reversion gap captured, which is bounded by the half-life. Longer half-life pairs (30+ days) have larger per-trade alpha and can absorb more slippage before the curve crosses zero. The Cointegration Half-Life Solver gives the formal mapping from cointegration residual to half-life.
What retail capacity really looks like
The headline $1B is not a retail number. Two corrections apply:
Slippage is much higher
Retail fills on mid-cap pairs typically realise 15-30 bps of slippage including spread, commissions, and impact. The engine's curve has already crossed zero by 8bp on this default pair, so at a 15-30bp retail fill the model says there is no profitable capacity at all — the per-trade alpha is fully consumed by execution cost. The default 8bp alpha-per-trade assumption is itself optimistic for retail; a higher-alpha, longer-half-life pair is what keeps the curve positive at realistic slippage.
For retail-scale capital (€10k-1M), the question is not "what is the maximum AUM" but "what is the minimum AUM at which the strategy is worth the effort." Below roughly €50k of capital deployed per pair, the per-trade dollar profit drops below the cost of execution and monitoring.
Half-life sets the trade count
A 7-day half-life implies roughly 50 round-trips per year per pair under perfect re-entry. The engine's 36 trades/year is the practical version with re-entry friction. Running 10 pairs simultaneously gives 360 trades/year — which is high enough to dominate the trader's attention budget without giving a meaningful Sharpe lift over 3-5 well-chosen pairs.
The empirical pattern in published stat-arb research: pair count above ~20 starts to be dominated by maintenance overhead rather than alpha2. The retail sweet spot is 3-8 carefully validated pairs, each with verified half-life and PBO < 0.3.
The cointegration prerequisite
Before any capacity number means anything, the pair must actually be cointegrated. The Engle-Granger test, the Johansen test, or a half-life-based stationarity check on the spread are the standard diagnostics3. A pair that fails cointegration is not a stat-arb pair; it is two random walks that happen to look correlated on a backtest window.
The Pair Trading Tester runs cointegration and half-life checks on uploaded price series. Half-life under 1 day is suspicious (probably a microstructure artefact); half-life over 60 days is too slow for a retail strategy to capture before regime change kills the relationship.
Trade-by-trade economics
For a single pair with half-life 7 days and $50k deployed per leg, the per-trade economics:
- Position notional: $50k per leg ($100k gross)
- Expected per-trade alpha: 30-80 bps of notional (typical for validated pairs)
- Slippage at retail: 15-30 bps round-trip
- Net per-trade alpha: 0-50 bps = $0-500 per trade
- 36 trades/year per pair: $0-18k annual P&L per pair
Multiply by 5 pairs: $0-90k annual P&L. The variance on this estimate is wide because slippage and alpha are both empirical. The Execution Simulator gives a slippage envelope on a chosen pair's order-book history.
When the strategy stops working
Stat-arb pairs decay. Three failure modes:
- Regime change. The underlying economic linkage that creates the cointegration breaks (corporate action, sector reclassification, macroeconomic regime). Half-life lengthens, then the relationship fails the cointegration test entirely.
- Crowding. Other traders find the same pair. Spread tightens, alpha shrinks, slippage stays the same. Capacity per trader drops.
- Microstructure shift. Tick-size change, exchange fee change, or a market-maker withdrawing from one side. Slippage rises, alpha is unchanged.
All three patterns show up as deteriorating live performance against backtest. The Walk-Forward Validator catches early signs by re-fitting the cointegration parameters on a rolling window — a half-life that drifts is a half-life that is about to fail.
Failure modes
- Treating maxAum as a retail-applicable number. It is the theoretical ceiling under perfect execution. Retail realises 5-15% of that in practice.
- Sizing a strategy to the engine's slippage assumption without validating. Run the Execution Simulator on actual order-book snapshots to estimate true slippage at the chosen size.
- Ignoring the cointegration test. A pair that fails cointegration has no statistical foundation; the half-life is meaningless.
- Multi-pair correlation. Running 10 pairs that are all driven by the same factor is one bet at 10x leverage. Size the portfolio, not the trade.
FAQ
Why does the engine return $1B as maxAum?
The engine's maxAum is the theoretical capacity at zero slippage friction in the engine's model. It is the asymptote of the capacity curve, not a practical number. The practical number is on the curve at the user's realistic slippage assumption — which retail traders should expect to be 15-30 bps.
What half-life is too short for retail?
Under 3 days, the round-trip execution cost typically exceeds the alpha. The strategy works on institutional infrastructure with sub-bp execution, not on retail platforms with 10-30 bp realised cost.
How do I check if my pair is actually cointegrated?
Run the Engle-Granger or Johansen test on the price series. The half-life of the spread residual should be stable across rolling windows. The Pair Trading Tester wraps these tests; for the formal test detail, the standard reference is Lopez de Prado's Advances in Financial Machine Learning4.
Connects to
- Walk-Forward Validation Cookbook: catches pair decay early.
- Backtest Overfitting LLM Strategies: PBO Explained: qualify the backtest first.
- Execution Simulation: Slippage Impact: slippage at retail scale.
- How to Read a Backtest Report: turn the capacity curve into a deployment decision.
- Statistical Arbitrage Capacity: re-run on your pair.
- Statistical Arbitrage Capacity methodology: full input/output specification.
References
Footnotes
-
Avellaneda, M., & Lee, J. H. (2010). "Statistical arbitrage in the U.S. equities market." Quantitative Finance 10(7), 761–782. tandfonline.com ↩
-
Gatev, E., Goetzmann, W. N., & Rouwenhorst, K. G. (2006). "Pairs Trading: Performance of a Relative-Value Arbitrage Rule." Review of Financial Studies 19(3), 797–827. academic.oup.com ↩
-
Engle, R. F., & Granger, C. W. J. (1987). "Co-Integration and Error Correction: Representation, Estimation, and Testing." Econometrica 55(2), 251–276. jstor.org/stable/1913236 ↩
-
Lopez de Prado, M. (2018). Advances in Financial Machine Learning. Wiley. Chapter on mean-reversion strategies and pair trading. ↩
Verified engine output
Show the recompute-verified inputs and outputs
| signal_half_life_days | 7 |
|---|---|
| daily_volume_usd | 10000000 |
| slippage_bps | 4 |
| fee_bps | 1.5 |
| target_sharpe | 1.5 |
| alpha_per_trade_bps | 8 |
| impact_k | 0.25 |
| trading_days | 252 |
| max aum | 1000000000 |
|---|---|
| practical aum | 0 |
| trades per year | 36 |
| capacity curve (9 items) | [...] |
Computed live at build time.