Statistical arbitrage capacity is a slippage problem disguised as an alpha problem. The Statistical Arbitrage Capacity engine on this pair (mean-reversion half-life 7 days, 36 trades/year, target Sharpe 1.5, 8bp alpha, $10M daily volume) returns a maximum theoretical AUM of just $10 at the strategy's 4bp slippage, and a capacity curve that runs $67.60 at zero slippage, $48.40 at 1bp and $32.40 at 2bp. The square-root impact model lands on tiny, retail-scale numbers because the per-trade edge is thin and the half-life is short. The binding constraint is half-life and position size, not a large headline AUM.
TL;DR
- Scenario: mean-reversion half-life 7 days, 36 trades/year, target Sharpe 1.5, 8bp alpha, $10M daily volume.
- Engine maxAum: $10 at 4bp slippage; practical AUM (50% alpha haircut) is $0.
- Capacity curve at 0/1/2/3/5 bps slippage: $67.60 / $48.40 / $32.40 / $19.60 / $3.60.
- The curve crosses zero by 8bp: at 8bp and above the engine returns $0 capacity.
- Capacity scales with net-alpha squared and with the dollar-volume universe, so a thin-edge short-half-life pair is small by construction.
- The binding constraint is half-life and position size, not a 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), 8bp alpha per trade against a $10M daily-volume name, targeting a Sharpe ratio of 1.5. The Statistical Arbitrage Capacity tool returns a theoretical capacity curve.
| Slippage assumption | Theoretical AUM |
|---|---|
| 0 bps | $67.60 |
| 1 bp | $48.40 |
| 2 bps | $32.40 |
| 3 bps | $19.60 |
| 5 bps | $3.60 |
| 8 bps | $0 |
| 12 bps | $0 |
The engine's maxAum field returns $10 at the strategy's 4bp slippage. The curve shows how capacity drops as the assumed slippage rises. At 5bp slippage it is already down to $3.60, 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 engine's number is already retail-scale-small for this pair, and even that overstates deployable capital. Two effects make it worse:
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 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 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 deployable number. It is the theoretical ceiling at the modeled slippage. Realistic retail slippage of 15-30bp sits past the 8bp zero-crossing, so the model says there is no profitable capacity at that fill cost.
- 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 such a small maxAum?
Square-root impact at an impact coefficient of 0.25 on an 8bp edge yields a low-dollar capacity for this thin-edge, short-half-life pair. The maxAum is the ceiling at the modeled slippage, not at zero friction. The practical number is lower still: realistic retail slippage of 15-30bp sits past the 8bp zero-crossing, where the model returns no profitable capacity.
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 | 10 |
|---|---|
| practical aum | 0 |
| trades per year | 36 |
| capacity curve (9 items) | [...] |
Computed live at build time.