Quantitative Trading
Systematic, data-driven trading strategy development
Use Cases
- Develop trading strategies (trend following, mean reversion, arbitrage)
- Strategy backtesting and performance analysis
- Risk management and position control
- Factor research and alpha mining
Strategy Development Process
假說形成 → 數據準備 → 策略編寫 → 回測驗證 → 風險控制 → 實盤監控
Core Knowledge
Strategy Types
| Type |
Description |
Risk |
| Trend Following |
Go with the trend, buy on the way up and sell on the way down |
Losses in ranging markets |
| Mean Reversion |
Reversion after price deviation |
Losses in trending markets |
| Statistical Arbitrage |
Pairs trading, spread convergence |
Correlation breakdown |
| High-Frequency Trading |
Microsecond-level spread capture |
High technical risk |
Risk Metrics
| Metric |
Formula |
Good Standard |
| Sharpe Ratio |
(Return - Risk-Free) / Standard Deviation |
> 1.5 |
| Maximum Drawdown |
Maximum decline from peak to trough |
< 20% |
| Calmar Ratio |
Annualized Return / Maximum Drawdown |
> 1.0 |
| Win Rate |
Profitable Trades / Total Trades |
> 50% |
Common Factors
| Factor |
Description |
Logic |
| Value |
Low P/E, P/B |
Cheap stocks perform well over the long term |
| Momentum |
Past winners keep winning |
Trend persistence |
| Quality |
High ROE, low debt |
Good company premium |
| Size |
Small-cap premium |
Liquidity compensation |
| Volatility |
Low-volatility anomaly |
Low risk, high return |
Backtesting Checklist
- Data Quality: Is there survivorship bias?
- Look-Ahead Bias: Was future data used?
- Overfitting: Were parameters over-optimized?
- Transaction Costs: Are commissions and slippage included?
- Out-of-Sample Testing: Is a test set reserved?
Best Practices
- Simple first, then complex - Start with a simple strategy and gradually increase complexity
- Out-of-sample validation - Always reserve a portion of data for final testing
- Consider transaction costs - Include realistic commissions and slippage in backtests
- Diversify risk - Don't put all your capital into a single strategy
- Continuous monitoring - Monitor strategy performance after going live and set stop-loss conditions
Common Mistakes
| Mistake |
Correct Approach |
| Going live because backtest returns look amazing |
Check whether it is overfitted |
| Ignore transaction costs |
Include real commissions and slippage |
| Train on all data |
Split into training/validation/test sets |
| Single strategy all-in |
Multi-strategy portfolio to diversify risk |
Sharp Edges
SE-1: Backtest overfitting
- Severity: critical
- Scenario: The strategy performs excellently in backtests (Sharpe > 3), but loses money in live trading
- Cause: Parameters are over-optimized for historical data, capturing noise rather than signal
- Symptoms: Backtest Sharpe > 3, live performance < 50%, parameter sensitivity, too few trades
- Detection:
sharpe.*[3-9]\.|sharpe.*\d{2,}
- Solution: Use walk-forward validation, with 5+ rolling test segments
SE-2: Look-ahead Bias
- Severity: critical
- Scenario: Future data was unintentionally used during backtesting
- Cause: Time order was not taken into account during data processing
- Symptoms: Perfect backtest returns, using the same day's closing price as the same day's signal
- Detection:
shift\(-|iloc\[-1\].*today
- Solution: Signals must be delayed by one day
signal = prices.shift(1) > ma.shift(1)
SE-3: Survivorship bias
- Severity: high
- Scenario: Backtesting using only stocks that currently exist
- Cause: Delisted and removed stocks are excluded, leading to overestimation of strategy performance
- Symptoms: Backtest returns are significantly higher than actual, small-cap strategies perform especially well
- Solution: Use a complete database that includes delisted stocks, use Point-in-Time data
SE-4: Ignoring transaction costs and slippage
- Severity: high
- Scenario: A high-frequency turnover strategy looks very profitable
- Cause: Commissions and slippage are not included, and actual costs eat up all profits
- Symptoms: Annual turnover > 1000%, profit per trade < 0.5%, backtest fills at closing price
- Solution: Include commission (0.1%) + slippage (0.2%) = 0.3% per trade
SE-5: Overconfidence in in-sample performance
- Severity: medium
- Scenario: Deciding to go live based only on in-sample backtest results
- Cause: No independent test set was reserved
- Symptoms: No out-of-sample testing, validation set reused, test set data volume too small
- Solution: Split data 60/20/20 (training/validation/test), use the test set only once
Risk management framework
Layer 1 Trading layer: 2% stop-loss per trade, set take-profit based on volatility, trailing stop to protect profits
Layer 2 Strategy layer: A single strategy must not exceed 20% of total capital, halve position size if drawdown exceeds 15%
Layer 3 Portfolio layer: Daily VaR must not exceed 2%, stress testing, maintain 20% cash
Kelly formula
f* = (p × b - q) / b
f* = 最佳投注比例, p = 勝率, q = 敗率, b = 賠率
範例：勝率 55%, 賠率 1.5 → f* = 25%（實務用 Half-Kelly 12.5%）
Execution risk
| Risk |
Description |
Countermeasure |
| Slippage |
Difference between execution price and expected price |
Limit orders, batch execution |
| Liquidity |
Unable to execute sufficient quantity |
Avoid small-cap stocks, set limits |
| System failure |
Program/network interruption |
Backup systems, manual monitoring |
| Black swan |
Extreme events |
Position limits, stop-loss mechanisms |
Tool recommendations
- Backtrader - Python backtesting framework
- QuantConnect - Cloud quantitative platform
- TradingView - Chart analysis and strategy testing
- Zipline - Quantopian open-source backtesting engine
Additional resources
Reference resources
- Quantitative Trading - Ernest Chan
- Advances in Financial Machine Learning - Marcos Lopez de Prado
Disclaimer
Quantitative trading involves high risk, and historical performance does not guarantee future results. This content is for educational reference only and does not constitute investment advice.
