Case Study - Building a Quantitative Strategy from Scratch › Stage 7: Deployment Readiness
Quantitative FinanceAll chapters Case Study - Building a Quantitative Strategy from Scratch › Stage 7: Deployment ReadinessOne section · Sections in this chapter8 / 12 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
With a backtested strategy and risk framework in place, we now outline what it takes to move from research to live trading. This draws on the infrastructure and execution concepts from the earlier chapters in this part.
System Architecture
A pairs trading strategy requires several interconnected components:
- Data ingestion. Real-time price feeds for both stocks, with a fallback to delayed data for monitoring. Store tick-level and minute-bar data for execution; daily closes for signal generation.
- Signal engine. Compute the spread, rolling z-score, and position signal at the close of each trading day (or intraday if operating at higher frequency). This is the code we developed above, wrapped in a production framework.
- Order management system (OMS). Translate position changes into orders. For a pairs trade, this means simultaneously sending a buy order for one leg and a sell order for the other, ideally using a pairs execution algorithm that minimizes leg risk (the risk that one leg fills and the other does not).
- Risk monitor. Continuously track exposure, PnL, drawdown, and VaR against limits. Generate alerts when thresholds are approached.
- Reconciliation. At end-of-day, reconcile fills from the broker against the strategy's internal position records. Any discrepancies must be flagged and resolved.
Execution Considerations
As we discussed in the chapters on transaction costs and execution algorithms, the way we execute trades has a material impact on realized performance:
- Leg risk. In a pairs trade, both legs must be executed simultaneously. Using a single exchange and limit-order approach creates the risk that only one side fills. Market orders guarantee execution but at the cost of wider spreads. Smart execution algorithms balance these trade-offs, as covered in the optimal execution chapter.
- Market impact. Our backtest assumed 10 basis points of round-trip costs, which is reasonable for liquid large-cap equities. For smaller stocks or larger position sizes, slippage could be significantly higher.
- Execution timing. We generate signals at market close and execute at the next day's open. The overnight gap between signal and execution introduces slippage. An alternative is to trade near the close using a VWAP or TWAP algorithm.
Monitoring and Decay Detection
Once live, the most important ongoing task is monitoring for strategy decay. Mean-reverting strategies can stop working when:
- The fundamental linkage between the two stocks weakens (e.g., one company diversifies into a new business line).
- Market conditions shift such that mean reversion gives way to momentum (e.g., during a sector-wide trend driven by macro factors).
- Other market participants discover and trade the same pair, arbitraging away the opportunity.
We implement a simple monitoring framework by tracking the rolling Sharpe ratio and the ADF test p-value on the live spread.
def compute_rolling_sharpe(pnl_series, window=60):
"""Compute rolling annualized Sharpe ratio."""
rolling_mean = pnl_series.rolling(window).mean()
rolling_std = pnl_series.rolling(window).std()
rolling_sharpe = (rolling_mean / rolling_std) * np.sqrt(252)
return rolling_sharpe
def compute_rolling_adf(spread_series, window=120, step=20):
"""Compute ADF p-value on rolling windows (expensive, so sample periodically)."""
p_values = pd.Series(index=spread_series.index, dtype=float)
indices = range(window, len(spread_series), step)
for i in indices:
window_data = spread_series.iloc[i - window : i]
try:
adf_result = adfuller(window_data, maxlag=10, autolag="AIC")
p_values.iloc[i] = adf_result[1]
except:
p_values.iloc[i] = np.nan
return p_values
# Compute monitoring metrics
rolling_sharpe = compute_rolling_sharpe(results_test["net_pnl"])
rolling_adf = compute_rolling_adf(results_test["spread"])
The monitoring dashboard gives us an at-a-glance view of strategy health. If the rolling Sharpe drops below zero for an extended period or the ADF p-value rises above 0.10, these are early warning signs that the cointegrating relationship is weakening, and we should consider pausing the strategy and re-evaluating.
Pre-Deployment Checklist
Before going live, you should work through the following checklist, which spans everything covered in Part VII:
- Backtest validation. Is the out-of-sample performance consistent with in-sample? Are the assumptions (transaction costs, fill rates, data quality) realistic?
- Risk limits defined. Position size, stop-loss, portfolio-level exposure, and daily loss limits are documented and coded into the system.
- Execution tested. Has the execution algorithm been tested in a paper trading environment? Is leg risk controlled?
- Infrastructure resilient. Are there failover mechanisms for data feeds, execution gateways, and signal computation? What happens if the system goes down mid-day?
- Regulatory compliance. Are short-selling restrictions accounted for? Is the strategy compliant with market manipulation rules, as we discussed in the ethics chapter?
- Monitoring automated. Are alerts configured for drawdown limits, VaR breaches, and cointegration breakdown?
- Kill switch. Is there a manual override to flatten all positions immediately?