富邦 OMS 系統建置訪談會議 2026-02-26
日期：2026/2/26。富邦證券交易室與凌群（廠商）首場 OMS 需求訪談會議；確立「先求有再求好」的階段策略與 3–4 個月內基礎版上線目標。本頁為訪談錄音的重點整理紀錄。本會議在時序上早於 26 同日的 Syscom 內部 weekly meeting 與 2 OMS 規劃會議，是富邦對外正式提出 OMS 需求的起點。
一、 專案建置背景與現行痛點
系統不穩定與過度依賴
現行交易高度依賴 Bloomberg 系統串接上手券商，去年曾發生 Bloomberg 整機斷線 4 次 及 EMSX 斷線 1 次 的狀況。1
風控與彈性限制
Bloomberg 系統較為僵化，無法針對單筆帳號額度、主管覆核權限進行客製化風控攔截。現行法人風控（如查檢 R6 系統額度、匯率換算等）都需透過人工處理。2
人工作業負載過重
為了達成未來「一兆」業績目標，若無專屬的 OMS（Order Management System）系統，目前高度依賴人工的作業模式將無法負荷龐大的單量，導致接單效率受限。3
二、 新 OMS 系統架構規劃
雙軌下單渠道
為提高備援能力與彈性，新的 OMS 將作為法人客戶與外圍系統的中間節點，並設計兩條下單路徑：4
- 打入現行 Bloomberg EMSX：透過 EMSX 裡面的上手做交易
- 直穿（DMA）到上手券商：若系統斷線或有特殊客製化需求，可直接將單送給上手
帳務回報
成交與委託回報最終都會透過 OMS 複寫回 R6 帳務系統 中。5
三、 專案推動策略與時程（先求有，再求好）
第一階段（基礎版）
高階主管強調「先求有」，優先處理能減輕交易室負擔的核心功能。首要目標是先將 OMS 串接至 Bloomberg EMSX (FIX 4.2)，並期望能於 3 到 4 個月內完成上線。6
後續擴充（進階版）
直連上手券商、整合富邦整體中台風控、以及未來的 OTA 升級等需求，將在第一階段的基礎上保留擴充彈性，於後續階段逐步建置。7
四、 UI 介面與功能需求
高度還原現有介面
新系統的主畫面設計需與現行 Bloomberg 介面高度雷同，以降低交易員的學習成本與操作風險。8
客製化版面
系統須支援多種不同的模組與版面設定，讓交易員能依不同市場或需求自訂顯示欄位（常用欄位高達 50 個以上）。9
交易與單據管理功能
五、 權限管理與風控機制
帳號獨立
目前 11 至 12 位交易員共用 4 台終端機的群組權限，未來將改為一人一組獨立的登入帳號與權限（UID）。13
分層與覆核
系統需具備分層授權機制，針對超過額度的大單需能觸發主管覆核機制。14
前端防護
需將現行人工審核的額度與匯率風控機制系統化，在收單前提供警示功能。15
六、 後續行動事項（Next Steps）
- 定期會議：富邦內部與廠商將維持每週一次的溝通會議，以釐清架構細節16
- 報價與評估：期望廠商在一個月內提出基礎版本的初步架構與報價，以便富邦啟動後續行政與採購流程17
- 實地觀摩：會議結束後，將安排與會人員分批前往交易室，實地觀摩現行系統的操作畫面18
各與會人提出的意見
副總（業務主管）
- 先求有再求好，需盡快上線：為達到老闆指示的「一兆」業績目標，期望 3 到 4 個月內完成基礎版，否則會損失半年的業績19
- 階段性建置：風控的分層部分先按現有方式走，後續整家公司的副委託風控架構（中台）或 OTA 升級，未來再去擴充與對接，基礎版先保留接口即可20
- 預算與報價：報價需要將「基本版」與「完整版」分開談；若金額太大可能需要向處長或更高層級報告21
松如（交易室代表）
- 現有痛點與系統架構：去年 Bloomberg 整機斷線發生過 4 次，依賴單一系統風險太高，需建置 OMS 作為中間節點，雙軌渠道（EMSX + 直穿上手）增加備援22
- 人工作業與風控防護：目前收單後都要人工去 R6 系統查核額度並換算匯率；未來希望 OMS 能代為控管，並在單量過大時觸發熱區警示與主管覆核機制23
- UI 介面高度還原：常用欄位超過 50 個，系統需支援客製化版面與快捷右鍵功能（改單、刪單等）24
- 母單拆分子單與 Algo 參數：法人客戶常要求將一筆母單拆成多筆子單（特定點位、控量），目前約有 15 個上手券商、每家各自有不同的 Algo 演算法參數，系統須讓交易員在介面上自行輸入參數，且子單成交後要能重算母單均價回報25
- 帳號權限獨立：未來 11 到 12 位交易員不再共用群組終端機，改成一人一組獨立的登入帳號（UID）與權限，以利追蹤接單人員26
建榮（專案 / IT 相關人員）
- 同業經驗比對：詢問現有開出的規格與同業（如凱基）自建的 OMS 架構是否有落差。指出同業當初約用 5 個人花 2 個月建置上線，希望本次建置的時間與規格不要有太大落差27
- 移轉風險評估：提醒若系統上線時一次性把客戶直轉到新 OMS 風險太高，建議像同業一樣保留部分客戶透過舊有的 EMS 渠道進來28
中台 / 風控代表（四衡 等）
- 專案範圍調整：原本專案發起時是要先建置「中台」後再接 OMS，但因交易室 OMS 需求較急迫，所以同意先請廠商評估優先建置 OMS29
- 法人風控的特殊性：強調法人下單的風控屬於「特殊規則」，跟一般分公司通路的風控不一樣，這一段要先定義清楚廠商才有辦法規劃30
- 風控節點位置：往外打單到上手券商（DMA）或打給現有 EMS，兩者的底層管道可能有差異，因此「風控的檢核點要埋在哪個點」需要後續再細談31
廠商 / 技術人員
- FIX 連線與權限設定：說明 Bloomberg 連線分為 Net 與 Hub 兩種型態。Hub 會檢查較多欄位與額度限制；未來若申請新的 FIX 連線最好申請成 Net 模式，需要檢查的項目相對較少32
- 報價時程：將維持每週一次會議討論細節，期望能在一個月內把架構確認完畢，並提出初步報價給富邦走流程33
待辦事項（Next Steps）
| # | 事項 | 負責方 |
|---|---|---|
| 1 | 廠商於一個月內提出「基礎版（先求有）」與「完整版」的初步架構及報價 | 廠商 → 富邦業務端34 |
| 2 | 維持每週定期會議（含 Riven 與廠商）持續釐清 OMS 架構與操作細節 | 雙方35 |
| 3 | 確認風控的檢核點（買點） 具體要埋在系統的哪個環節 | 待釐清36 |
| 4 | 確認母單拆分多筆子單後，打給上手券商並接收回報時，如何正確串回 OMS 重算母單均價的細節 | 待釐清37 |
| 5 | 實地觀摩交易室：廠商人員分批（一次兩位、每次十分鐘）前往交易室實際觀摩 Bloomberg 操作畫面與流程 | 廠商38 |
| 6 | 機密簡報回收處理：紙本簡報含富邦客戶個資與 Bloomberg 介面截圖，與會人員須將機密頁面撕下或不外流，避免資安與稽核問題 | 全員39 |
現行系統 vs 新 OMS 系統 對照
本次訪談附帶整理的「現行（Bloomberg EMSX / 舊系統）」與「新 OMS 系統」需求功能比較表，凝結了會議全部結論。
| 比較項目 | 現行系統（Bloomberg EMSX） | 新 OMS 系統（規劃中） |
|---|---|---|
| 系統架構與連線渠道 | 高度依賴單一 Bloomberg EMSX 與終端機；去年整機斷線 4 次 | 雙軌渠道：可選擇打入 EMSX 或直穿（DMA）給上手券商40 |
| 風控與額度檢核 | 人工去 R6 查核、手動換算匯率；Bloomberg 無法設定單筆帳號額度或客製化擋單 | 系統自動化風控：收單前檢核客製化額度與匯率，單量過大觸發熱區警示與主管覆核41 |
| 帳號與權限管理 | 共用群組帳號；11–12 位交易員共用 4 台終端機（1 台主接單，3 台共用權限） | 一人一組獨立 UID；介面顯示該筆單由哪位交易員處理42 |
| 母子單與 Algo 參數 | 手動拆單、強記約 15 家上手、每家 10–25 個 Algo 參數 | 整合各家上手 Algo 參數於介面輸入；子單成交後自動重算母單均價並回報43 |
| 帳務回報機制 | EMSX 撈取後再回傳 R6，存在資訊斷點 | 一條龍自動化：透過 OMS 直接複寫回 R644 |
| UI 介面與操作 | 標準 Bloomberg 終端機畫面 | 高度還原現行 Bloomberg 畫面 + 客製化版面（50+ 欄位）+ 右鍵快捷選單（改單、刪單、DVP）45 |
| 後續擴充彈性 | 受制於外商，中台風控客製化或 OTA 升級難以彈性配合 | 保留高度擴充性，後續可對接副委託交易中台、風控模組與 OTA 升級46 |
關鍵實體
- Bloomberg EMSX — 現行下單系統，FIX 4.2 連線
- R6 — 帳務系統，匯率/額度查核資料來源
- DMA（Direct Market Access）— 直穿上手券商通道
- OTA（Over-The-Air）升級
- FIX Net vs Hub 模式 — Hub 檢查更多欄位與額度限制
- 熱區警示 + 主管覆核（Supervisor approval）
完整 OMS 術語與功能參見：
相關頁面
- 會議總覽：FSTS 會議紀錄總覽
- 同日內部會議：26 Syscom Weekly
- 後續內部規劃：2 OMS 開發規劃會議
- 後續對外 Demo：26 OMS Demo（Fubon × Syscom）
- 4/17 後續訪談：17 富邦複委託需求訪談
- 富邦客戶端參考文件： unsOMS 截圖）
補充資訊
(未來 ingest 新來源會在此追加段落)