LLM Wiki

FSTS OMS RFP 需求總覽

閱讀時間約 11 分鐘

FSTS OMS RFP 需求總覽

此頁為 OMS 建置 RFP 的需求彙整入口。原始 raw 為 5000+ 行多版本整合文件（Daphne / Belle / Manus / gpt 等多位作者提供不同版本），本頁收斂共通主幹（背景、痛點、角色、Phase、驗收）。細節依主題拆至 OMS 功能需求、Algo 映射與 R6 整合、NFR 與 SLA。

文件編號 OMS-RFP-20260303，發布日期 2026-03-03（Daphne 版），後續有 Belle (FSD) 整合版 20260304、Manus v2.0 20260309、gpt 修正建議版。12

專案背景

目前複委託交易室高度依賴彭博 Bloomberg 系統作為主要交易執行平台。過去一年發生數次彭博全球性中斷與 EMSX 斷線 4 次（另 EMSX 斷線 1 次），對交易穩定性造成重大威脅；斷線時的備援僅限 Bloomberg IB Chat 或電子郵件人工下單，效率低且缺乏系統化追蹤與風控管理。1

通訊協定也僅限彭博固定標準，無法滿足法人客戶客製化需求；風控流程需人工從 R6 後台抓取額度資料，作業繁瑣、無法即時監控。1

專案目標（五大）

  1. 提升交易穩定性與備援能力 — 建立獨立於彭博的備援下單路徑（DMA / Algo），EMSX 中斷時無縫切換1
  2. 強化風險控管機制 — 將人工風控自動化，內建即時盤中風控模組（額度預警、下單金額控管、多層級授權複核）1
  3. 滿足客製化需求 — 支援 FIX 標準及客製化通訊協定，提升服務廣度1
  4. 增加下單彈性與效率 — 靈活的 Algo 參數設定與上手對應（Algo Mapping），UI 貼近 Bloomberg 操作習慣1
  5. 優化後台作業流程 — 與 R6 自動化整合，交易確認資料直接寫入 R61

服務定位

  • 法人交易中台 — 專為機構法人處理 FIX 接收、策略執行、部位監控、成交回報2
  • 自動化路由中心 — 整合 Smart Order Routing (SOR)，彈性選擇最優下單路徑2
  • 業績願景支撐 — 透過自動化接單與風控，取代人工以支撐未來「一兆元」成交金額業績成長目標2

現行痛點

痛點現況規劃改善
系統不穩定彭博去年斷線 4 次，EMSX 斷線 1 次，無自動備援OMS 直接對接上手作為備援路徑2
風控仰賴人工交易員收單後需手動到 R6 查額度、自行計算匯率收單前即時自動攔截超額訂單2
硬體與權限受限11–12 位交易員共用 4 台終端機（含帳號權限），無法精細 UID 管理一人一組獨立 UID，分層授權2
學習成本高約 15 家上手券商，每家 10–25 個 Algo 參數需交易員強記；母子單成交後需手動計算均價Algo 映射引擎 + 自動均價計算2
後台對接繁瑣EMSX 倒檔回 R6，流程易出錯OMS 直接寫回 R6，自動對帳1

核心使用者角色

角色職責主要功能
法人客戶透過 FIX 4.2 或其他協定傳送母單委託、回報訂閱2
交易員 Traders接單、母子單拆分、Algo 設定、執行監控訂單管理、成交追蹤、Algo 參數調整3
風控人員 Risk Officers設定法人特殊風控規則、監控熱區警示額度管理、風險監控、多層級複核3
交易室主管 Desk Manager超額 / 特殊警示訂單的電子化覆核Approve / Reject 線上簽核2
後台人員系統對帳、確認書產出、交易記錄管理日終結算、對帳、確認書3
客戶經理客戶額度管理、報表查詢、客戶服務額度設定、交易報表、客戶分析3
維運人員 IT/OpsFIX 線路監控、系統健康、DB 維護、LOG 管理SCOM/Zabbix 告警、版本部署2

系統分層架構（目標系統）

  • 前端接入層 — Bloomberg FIX 4.2/4.4/5.0、客製化 REST API、Web 手動下單1
  • 核心中樞層 — OMS 訂單管理引擎、即時風控模組、智慧訂單路由 (SOR)、R6 系統整合介面1
  • 後端執行層 — Bloomberg EMSX（主管道）、DMA 直連上手（備援）、Algo 交易引擎（擴充）1
  • 後台作業層 — R6 後台系統（帳務、對帳、確認書）、風控資料庫（額度、合規）1

分階段實施計畫

RFP 提供多版本 phase 切分，各版略有差異：

Daphne 版（兩階段，8 個月）1

階段期間核心
第一階段（基礎版）第 1–4 月FIX 客戶接入（4.2/4.4）、EMSX 對接、基礎風控、R6 額度介接與寫回、交易員 UI
第二階段（完整版）第 5–8 月DMA 直連、Algo 參數客製化、多層級複核、可自訂儀表板、客戶端 API

Belle FSD 版（三階段）2

階段期間重點
階段一（MVP）3–4 月核心接單、FIX 4.2 對接 EMSX、UI 主畫面還原、基礎 R6 風控、UID 管理
階段二（進階）2–3 月完整 Algo 映射、DMA 直穿、UI 板塊優化、電子覆核
階段三（擴充）視業務需求OTA 功能、大數據報表、中台對接

24 週 WBS 版4

6 個月 / 24 週開發藍圖，W1–W24 分 Phase 0–5（啟動期 → 基礎架構 → 連線中樞 MVP → 業務功能 → 測試優化 UAT → 部署上線）。

gpt 修正版（四階段）5

  • Phase 0 — 技術底座與控制框架
  • Phase 1 — 核心 OMS + 複委託合規 + 帳務一致性（能下、能控、能對、能查）
  • Phase 2 — 進階執行與法人能力（母子單、SOR、算法單、籃子單、進階分析）
  • Phase 3 — 稅務自動化、營運最佳化、跨區域擴展（QI / W-8 / 1042-S、執行品質分析）

驗收需求

  1. 功能驗收 — FIX 連線、母子單拆分、15 家上手 Algo 參數正確拋轉、R6 自動寫回2
  2. 非功能驗收 — 壓力測試需達預期峰值 2 倍不崩潰、資安弱點修正、AD 權限切換測試2
  3. 文件驗收 — 《系統架構說明書》《API 規格書》《操作手冊》《KM 知識庫初版》2
  4. 環境驗收 — 地端與雲端環境配置符合稽核規範2
  5. CI/CD 驗證 — 自動化佈署流程測試通過、更新過程不丟單2

測試範圍

  • 市場覆蓋 — 北美、歐洲、亞洲（含越南）全球 30+ 市場連線2
  • 測試項目 — 單元、整合 (SIT)、UAT、Bloomberg 斷線故障切換 (Failover)2
  • 資安弱掃 — Fortify 或相關掃描，高風險項目 100% 修復2
  • 壓力測試 — 模擬開盤瞬間每秒 500 筆以上訂單併發處理2

gpt 版對原需求的關鍵修正

文件內附 gpt 修正建議，值得特別留意：5

  1. 「全球市場自動算 NBBO」要改寫 — NBBO 是美國 NMS 概念，不是全球通用；非美市場應講「最佳執行證據」而非 NBBO
  2. 「FATCA 自動化申報 Form 8938」要改 — Form 8938 是特定美國納稅人附在自己稅務申報中，不是券商替客戶主動申報；系統應定位為「資料供應與名單報送支援」
  3. 「WORM 才合法」要改成「不可竄改留痕機制」 — SEC 17a-4 現行規則接受 WORM 或 audit-trail alternative，不必僵化
  4. 「2 秒沒回執就自動重送到備援」是高風險需求 — 訂單可能已送達市場但回報延遲，盲目重送會造成重複下單；必須建立 idempotency key / broker order token / duplicate check，不確定時進入 Pending / Unknown / Manual Intervention
  5. 延遲要求應定義為 SLO 而非保證值 — Gateway reject p95 < 20ms、R6 預扣 p95 < 200ms、FIX failover 秒級內、成交回寫 p95 < 1 秒

相關頁

補充資訊

(未來 ingest 新來源會在此追加段落)

參考資料

Footnotes

  1. OMS RFP §1 專案背景與目標（Daphne 版） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  2. OMS RFP §一 背景與目標（Belle FSD 版） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21

  3. OMS RFP §3.1 核心使用者角色（整合版） ↩ ↩2 ↩3 ↩4

  4. OMS RFP §二 24 週 WBS 開發藍圖 ↩

  5. OMS RFP §gpt 版修正建議 ↩ ↩2

關係圖譜

反向連結