第二階段：核心組件深度解讀
模組 09：風控引擎 — 交易的安全網在訂單到達交易所之前，風控引擎是最後一道防線
一、為什麼風控必須是獨立組件？
🚨 沒有風控的後果
2012 年 8 月 1 日，Knight Capital 因為一個軟件 bug 在 45 分鐘內虧損了 4.6 億美元，公司直接破產。如果有一個獨立的風控系統在訂單到達交易所之前檢查異常，這場災難完全可以避免。
flowchart LR
strategy["🎯 策略"] -->|"下單命令"| risk["🛡️ RiskEngine<br/>風控引擎"]
risk -->|"✅ 通過"| exec["⚙️ ExecutionEngine"]
risk -->|"❌ 拒絕"| denied["OrderDenied<br/>通知策略"]
exec --> exchange["🏦 交易所"]
圖 1：風控引擎攔截在策略和執行引擎之間
二、風控檢查項目
| 檢查類別 | 具體檢查 | 目的 |
|---|---|---|
| 訂單頻率 | 每秒最大訂單數 | 防止因 bug 導致的瘋狂下單 |
| 每分鐘最大訂單數 | 防止頻率過高被交易所封禁 | |
| 命令節流 | 限制 API 調用頻率 | |
| 數量限制 | 單筆最大下單數量 | 防止手滑多加幾個零 |
| 單筆最大金額 | 防止單筆交易過大 | |
| 最大未完成訂單數 | 防止掛單過多 | |
| 持倉限制 | 特定品種最大持倉 | 限制單一品種的集中度 |
| 全局最大持倉數 | 限制同時持有的Position數量 | |
| 數據驗證 | 價格/數量合法性 | 防止無效數據導致的錯誤訂單 |
三、配置風控規則
from nautilus_trader.risk.config import RiskEngineConfig
risk_config = RiskEngineConfig(
max_order_submit_rate="20/00:00:01", # 每秒最多 20 個訂單
max_order_modify_rate="10/00:00:01", # 每秒最多 10 次修改
max_notional_per_order={ # 單筆最大金額
"USDT": 100_000, # 每筆最多 10 萬 USDT
},
)四、風控觸發後的處理
sequenceDiagram
participant S as 🎯 策略
participant RE as 🛡️ RiskEngine
participant MB as 📡 MessageBus
S->>RE: SubmitOrder(買入 100 BTC)
RE->>RE: 檢查：單筆金額超過限制！
RE->>MB: 發布 OrderDenied 事件
MB->>S: on_order_denied(event)
Note over S: 策略收到拒絕通知<br/>可以記錄日誌或調整邏輯
圖 2：風控拒絕訂單的事件流
💡 你的策略應該處理 on_order_denied
當風控拒絕訂單時，你的策略會收到 on_order_denied 回調。你應該在這裡記錄日誌，分析為什麼被拒絕，而不是忽略它。
五、互動練習
🧠 練習：設計風控規則
你管理一個加密貨幣帳戶，初始資金 100,000 USDT。你會設置哪些風控規則？為什麼？
參考風控規則：
- 單筆最大金額：10,000 USDT（帳戶的 10%）
→ 防止單筆交易造成過大損失 - 每秒最大訂單數：5 個
→ 防止策略 bug 導致的瘋狂下單 - 最大未完成訂單數：20 個
→ 防止掛單過多佔用保證金 - 單一品種最大持倉：20,000 USDT（帳戶的 20%）
→ 防止集中度過高
💡 風控的核心原則：寧可錯殺，不可放過。
一個被風控擋住的好機會只是少賺，但一個沒被擋住的錯誤訂單可能讓你傾家蕩產。
六、本模組重點回顧
📋 關鍵點
- 風控引擎是訂單到達交易所前的最後一道防線
- 獨立組件：即使策略有 bug，風控也能攔截
- 多維度檢查：頻率、數量、金額、持倉
- 被拒絕的訂單會產生
OrderDenied事件通知策略 - 寧嚴勿鬆：風控設置應偏保守