風控機制總覽¶
Tapio 風控中台存在的核心目的，是在客戶端送出的委託抵達期交所之前，把所有可能導致超額損失（Over Loss）、逾部位限制或其他違規的委託在本地攔下。 期貨是保證金交易，凡違反保證金或部位規定的委託一旦成交，就牽涉保證金追繳、代為沖銷乃至申報違約；期貨商若未確實執行風控，更面臨主管機關的行政裁罰。事後補救的代價遠高於事前攔截。因此 Tapio 的設計哲學是：
名詞說明
- 超額損失（Over Loss）：帳戶虧損超過保證金，權益數為負數。客戶不只虧光本金，還倒欠款項，須依法補足差額，是期貨交易中最嚴重的風險事件。
- 逾部位限制：委託或持倉口數逾交易所或業者設定之上限，違反集中度風險規範。
寧可在本地多擋一次，也不要讓異常委託送出去。
所有風控檢查都在同一個處理路徑內一氣呵成完成——從客戶端送來委託、到決定是否送往期交所，全程不跨網路、不等待外部查詢。這讓 Tapio 能同時達成兩個看似衝突的目標：微秒級延遲與完整的事前風控。
委託的完整路徑¶
每一筆新單從客戶端送出後，會依序經過兩個階段；任一關卡未通過即立刻回覆錯誤，不再繼續下游檢查。
前置檢查¶
進入風控核心路徑之前，系統先驗證以下六項條件：
- 連線登入與速率上限：連線必須已完成登入，且每秒送出的委託數不得超過該連線的速率上限。
- 帳號旗標：帳號設定必須允許此類委託，例如帳號未被凍結。詳見帳號層級控管。
- 系統總開關：系統必須處於開啟狀態；管理員可隨時遠端切換，影響所有新單、改單及撤單。
- 欄位合法性與商品支援：委託的價格、數量、商品代碼等欄位格式正確，且系統支援該商品。
- 單筆口數上限：單筆委託口數不得超過期交所規定的上限（限價單與市價單規則不同）。
- 行情資料可用：系統已收到並載入該商品的行情資料；行情未就緒時無法試算保證金。
六項條件全部通過，才進入下方的風控核心路徑。各項條件的詳細說明請見「前置檢查」。
風控核心路徑¶
flowchart TD
A([前置檢查通過]) --> H{此筆為平倉單<br/>且有效委託單口數不超過淨部位？}
H -->|是| P[平倉通路：直接放行]
H -->|否| I{帳戶淨值與<br/>可動用額度均為正？}
I -->|否| X7[拒絕：帳戶餘額為負]
I -->|是| I2{帳號允許<br/>新開倉位？}
I2 -->|否| X9[拒絕：帳號禁止開倉]
I2 -->|是| J{可用資金足以<br/>涵蓋所需保證金？}
J -->|否| X8[拒絕：保證金不足]
J -->|是| K2{多空部位<br/>未超出上限？}
K2 -->|否| X10[拒絕：部位超限]
K2 -->|是| K[登記為委託中]
P --> K
K --> L([送往期交所])平倉通路的設計意圖
當客戶想出場（平倉既有部位）時，系統不應該因為「目前保證金不足」、「帳號被停新倉」或「餘額為負」而擋下。判定為平倉後立即放行，跳過後續的餘額不足、禁止開倉、保證金不足及部位超限等檢查。這樣設計是為了確保客戶在需要出場時不會因風控設定而被迫持有不想要的部位。
平倉通路成立的條件是：委託方向為平倉（Close），且同方向的累計有效委託單口數（含本筆）不超過既有淨部位的絕對值。注意這裡比對的是已送出的有效委託單累計口數，不是單筆委託本身的口數。
另外，欄位合法性檢查（例如客戶指定開倉但系統判定為平倉、或客戶送出當日沖銷單）發生在平倉通路判定之前，因此即使是平倉單，若開平倉碼本身有誤，仍會在進入平倉通路前被攔下，不在跳過範圍內。詳見「部位限制」。
兩種保證金相關拒絕的區別
流程中有兩個不同條件的保證金拒絕：
- 餘額為負拒絕：帳戶淨值（equity）或可動用額度（餘額與可用資金）本身已為負值——此時即使不下任何新單，帳戶已處於虧損狀態。
- 保證金不足拒絕：帳戶餘額仍為正，但扣除既有委託佔用後，可用資金不足以再涵蓋本筆委託所需保證金。
兩者的觸發順序固定：先檢查餘額是否為負，才檢查保證金是否足夠。
五大風控機制¶
五個獨立模組各自負責一個風控面向。下表為概覽，細節請參閱各子頁面。
| 機制 | 負責內容 | 典型拒絕情境 |
|---|---|---|
| 帳號層級控管 | 依帳號旗標決定該帳號能不能交易、能不能下市價單、能不能新開倉位 | 風控主管手動將某帳號設為「只允許平倉」，新開倉請求會被擋下 |
| 保證金檢查 | 以原始保證金為基準，計算這筆委託送出後該帳號需要的保證金，並與可用資金比對 | 餘額不足以涵蓋新增一口 TXF 的原始保證金 |
| 部位限制 | 依商品、多空方向設定上限；平倉單不受約束 | 已持有多方 50 口 TXF，上限為 50，再下買單開倉即拒絕 |
| 餘額與可用資金 | 未實現利潤不計、未實現損失立扣——可用資金 ＝ 當日餘額 ＋ min(未沖銷期貨浮動損益, 0)；再套上帳號額度上限得到可動用額度 | 行情大幅逆向時，未實現損失把可用資金吃光 |
| 委託追蹤 | 每筆委託送出前先預先鎖定所需保證金；成交或取消時再釋放；所有委託種類（ROD／IOC／FOK；限價單、市價單、市價保護單）一律以最保守方式計入，不預設成交機率 | 連續下五筆大單，即使前四筆仍為有效委託單，第五筆也已計入保證金佔用 |
速度與嚴謹的平衡¶
在一般金融系統中，「風控完整」與「延遲低」往往是取捨。Tapio 透過以下三個設計，讓兩者同時成立。
全部在本地完成¶
風控不向外部資料庫、其他服務查詢。所有判斷所需的資料——帳號設定、昨日結餘、未沖銷期貨浮動損益、目前部位、委託中數量——都在本地記憶體中維護，開盤前從盤前檔一次載入。
一致性快照¶
同一筆委託的風控驗證期間，保證金計算、可用資金計算、部位累計三者使用同一瞬間的資料，不會出現跨時刻的不一致情況。這代表：
- 不會出現「用 A 時刻的行情算保證金、用 B 時刻的部位判斷上限」的不一致情況
- 結果可預期、可重現，便於事後稽核
系統總開關¶
系統總開關預設為開啟，可由管理員透過管理介面遠端切換。每次切換皆先確認落盤後才生效，確保重啟後狀態一致——若前一交易日已關閉開關，重啟後依然保持關閉。開關影響所有新單、改單及撤單，登入操作不受影響。
速率限制（兩層機制）¶
Tapio 在兩個層面各自執行速率控制，彼此獨立：
第一層：使用者連線速率上限
前置檢查中「未超出速率上限」節點對應每條連線一個獨立的速率限制器。參數從 TOML 設定檔的 [gateway] 區段讀取：
| TOML 鍵 | 預設值 | 說明 |
|---|---|---|
user_request_rate |
3 |
每秒穩態補充速率（令牌/秒），有效範圍 1–256 |
user_request_burst |
5 |
瞬間允許的最大積累令牌數（突發上限），至少為 1 |
每條連線在建立時各自初始化，帳號之間互不影響。
第二層：期交所連線速率管控
每條往期交所的連線，期交所本身也設有每秒下單數上限。Tapio 追蹤已使用的配額，並預留 20% 緩衝供內部心跳等必要封包使用，實際可送出委託的配額為期交所上限的 80%。
當期交所回傳速率警告（使用量已達上限的 80% 或 90%）時，Tapio 立即暫停該連線的委託送出，並等待約 2 秒後才恢復。這個機制確保在異常流量湧入時，Tapio 不會因超出期交所規定的速率上限而遭受警告或裁罰。
兩層機制各自獨立運作：委託可能因第一層（使用者端速率）被擋下；也可能通過第一層後，因第二層（期交所連線）配額已耗盡而直接拒絕——系統不排隊等待，需由客戶端重試。
檢查順序由便宜到昂貴¶
愈便宜的檢查（例如連線狀態、帳號旗標）排在最前面，愈昂貴的（例如保證金試算、部位累計）排在最後。多數被拒的委託在前幾關就擋下，不會浪費後段的計算資源。
對營運方的意義
這個設計意味著：即使某一支帳號的風控設定特別嚴格（例如同時開啟禁止開倉、極低的部位上限、極小的可用資金），它的延遲並不會顯著高於一般帳號——因為會被擋的委託在前期就擋下，不會走完全程。
審計與可追溯¶
每一筆通過或被拒的委託，系統都會寫入審計紀錄。紀錄內容包含：
- 觸發時間、帳號、商品、價量
- 當下使用的行情快照
- 試算後的所需保證金、可用資金、部位狀態
- 通過或拒絕的結果，以及拒絕原因
這讓事後稽查（無論是內稽、主管機關查驗、或客戶對帳）都能在毫秒等級的時間軸上，還原每一筆委託當下的風控情境。
審計紀錄採非同步方式寫入，不影響委託處理路徑的延遲。每筆記錄包含兩個時間戳：系統收到委託的時刻，以及風控檢查完成的時刻。紀錄依日期分目錄存放，供稽核人員查詢。