OMS Algo 映射與 R6 整合技術規格

本頁收斂 RFP 內「Algo 參數映射引擎」「R6 API 具體串接欄位定義」「FIX 訊息流實例」「上手券商 FIX 認證測試清單」四個深度技術章節。上游業務需求請見 OMS RFP 總覽；功能清單見 OMS 功能需求。

目標

打造支援 Goldman Sachs / Morgan Stanley / Interactive Brokers 等 15 家上手券商的通用 Algo 轉譯層，並建立 OMS ↔ R6 的強一致性帳務整合。¹²

第一部分：Algo 參數映射引擎

1. 映射邏輯架構¹

Algo 映射引擎是 OMS **「通用轉譯層」**的核心，負責把交易員在 UI 輸入的標準參數（如 VWAP 啟動時間、參與率）自動轉譯為不同上手券商所要求的特定 FIX Tag 與值格式。

[交易員 UI 輸入] 
    ↓ (Schema 驗證)
[OMS Canonical Algo Object]
    ↓ (Broker-specific Mapper)
[GS / MS / IB 各自 FIX Tag]
    ↓ (FIX Outbound)
[上手券商 Algo Engine]

2. VWAP 策略 FIX Tag 映射範例¹

參數（UI 輸入）	GS 對應 Tag	MS 對應 Tag	備註
啟動時間 StartTime	Tag 847（UTC ISO 格式）	Tag 168（StartTime）	UTC 時區轉換必須精確
結束時間 EndTime	Tag 848	Tag 126（ExpireTime）	與 StartTime 配對驗證
參與率 Participation%	Tag 849（Integer 15 表 15%）	Tag 849（Decimal 0.15）	格式差異：Integer vs Decimal
最大執行量 MaxQty	Tag 850（自訂）	Tag 38 subfield	各家命名不同

3. 動態參數 JSON Schema¹

每家 Broker 的 Algo 參數採 JSON Schema 定義，動態渲染前端下單 UI：

{
  "broker": "GS",
  "algo": "VWAP",
  "params": [
    {"name": "StartTime", "type": "datetime-utc", "fix_tag": 847, "required": true},
    {"name": "EndTime", "type": "datetime-utc", "fix_tag": 848, "required": true},
    {"name": "ParticipationRate", "type": "int", "fix_tag": 849, "min": 1, "max": 50}
  ]
}

此設計允許「不動核心，只加 Schema」即可接入新 Broker。

4. 映射錯誤攔截（Pre-trade Validation）¹

下單前驗證 Algo 參數是否在上手允許區間內，故意傳送上手不支援的參數應由 OMS 攔截，而非被上手 Reject 浪費交易機會。

第二部分：R6 API 深度整合

1. 整合交互流程（TCC Try-Confirm-Cancel）²

為確保「錢扣了單沒下成功」這類客訴永不發生，OMS 採分散式事務 TCC 模式：

Try:     OMS → R6: POST /api/block-fund   (預扣額度)
         R6 → OMS: { BlockID: "B-20260304-001234", status: "locked" }
         
Confirm: OMS 成功下單到市場後
         OMS → R6: POST /api/confirm-fund  (確認扣款)
         
Cancel:  OMS 下單失敗 / 撤單 / Reject 時
         OMS → R6: POST /api/release-fund (釋放額度)

2. R6 購買力檢核 API²

Request（OMS → R6）

{
  "client_id": "C-0001234",
  "symbol": "2330.TW",
  "side": "B",
  "qty": 1000,
  "price_limit": 650.00,
  "currency": "TWD",
  "estimated_commission": 500,
  "estimated_fx_buffer_rate": 0.03
}

傳輸金額必須含「預估手續費與稅費」，避免第二次扣款失敗。

Response（R6 → OMS）

{
  "status": "locked" | "insufficient" | "rejected",
  "block_id": "B-20260304-001234",
  "available_fund": 5000000,
  "locked_amount": 669500,
  "reject_reason": null
}

BlockID 是 R6 回傳的鎖定編號，必須儲存於 OMS 訂單欄位，用於後續成交時的沖銷對應。

3. 非同步降級機制²

R6 若無法在 200ms 內回傳，系統需具備邏輯：

判斷是否依本地快取額度進行風險放行（白名單客戶 + 小額）
高風險商品不得因降級直接放行
降級行為必須有紀錄，事後可稽核

4. 匯率快取機制²

匯率不逐筆即時查 R6，改採本地快取 + 定時更新策略（如 30 秒更新一次），下單時以快照匯率加 FX_buffer_rate（市場慣例 3%）計算圈存金額：

C_Total = (Qty × Price_Limit × FX_Spot × (1 + r)) + Commission

其中 r 為匯率緩衝比例。

第三部分：母子單均價計算引擎

即時 VWAP 均價³

每秒更新所有子單成交之加權平均價格與剩餘量。計算需支援：

部分成交 — 子單 i 成交 qty_i @ px_i，母單 AvgPx = Σ(qty_i × px_i) / Σ(qty_i)
成交更正 — Broker 後續送來修正 ExecutionReport 時正確沖銷
跨幣別 — 各市場子單若幣別不同，需依當下匯率折算統一幣別

母單撤銷的遞迴處理³

母單撤銷時，系統需遞迴發送所有未成交子單的 Cancel Request (FIX 35=F)，不可漏單。

第四部分：FIX 訊息流實例

1. 母單接收（New Order Single 35=D）⁴

法人客戶透過 FIX 4.4 送入母單，OMS 接收端典型 tag：

Tag	名稱	示例值
11	ClOrdID	CLIENT-20260304-X001
55	Symbol	2330
207	SecurityExchange	XTAI
54	Side	1 (Buy)
38	OrderQty	10000
44	Price	650.00
40	OrdType	2 (Limit)
1	Account	富邦內部帳號

2. 轉發子單至上手券商（帶 Algo 參數）⁴

拆成子單轉發至 GS，Algo 參數由映射引擎轉換：

Tag	名稱	示例值	說明
11	ClOrdID	FB-OMS-S001	OMS 重新分配子單編號
38	OrderQty	2500	子單量（母單 1/4）
40	OrdType	8 (Pegged)	Algo 類型
847	StartTime	20260304-09:00:00	GS 專屬
848	EndTime	20260304-13:30:00	GS 專屬
849	ParticipationRate	15	15%（Integer 格式）

3. 成交回報（Execution Report 35=8）⁴

上手回報成交，OMS 處理：

Tag	名稱	示例值
39	OrdStatus	1 (Partially Filled) / 2 (Filled) / 8 (Rejected)
150	ExecType	F (Trade)
32	LastQty	500
31	LastPx	650.50
14	CumQty	500
151	LeavesQty	2000
6	AvgPx	650.50

第五部分：上手券商 FIX 認證測試清單

一、Session 層測試（FIX 4.4）⁵

編號	測試項目	預期結果
S1	Heartbeat	每 30 秒互傳 35=0
S2	Sequence Reset / Gap Fill	模擬序號丟失，自動發 Resend Request 35=2
S3	Logon / Logoff	正確處理 TargetCompID / SenderCompID 握手

二、基本訂單生命週期測試⁵

編號	測試項目	驗證重點
T1	New Order Single	OMS 接母單 → R6 鎖額度 → 送子單 35=D 至 GS/MS
T2	Partial Fill	接 35=8, 39=1，OMS 實時更新均價並同步回 R6
T3	Order Cancel (35=F)	撤單後 R6 即時解扣剩餘未成交額度
T4	Order Replace (35=G)	減量 / 改價時驗證 R6 額度重新校準

三、Algo 策略映射測試⁵

VWAP 驗證 — Tag 847/848 在 GS 時轉譯為專屬代碼；StartTime / EndTime UTC 轉換精確
POV 測試 — ParticipationRate=15% 時，Tag 849 值格式驗證（Decimal vs Integer）
映射錯誤攔截 — 故意傳上手不支援參數，OMS 應 Pre-trade 攔截，不被上手 Reject

四、異常降級與 SOR 備援測試⁵

編號	情境	OMS 動作
E1	上手回 Reject (35=8, 39=8)	立即通知交易員，R6 秒級解扣
E2	EMSX 連線中斷	SOR 依優先權評分公式自動提示切 DMA
E3	R6 API Timeout > 500ms	進入 Degraded Mode，依快照餘額放行小額

五、最終交付物⁵

FIX Certification Report — 上手券商簽章的測試通過報告
UAT Signing Document — R6 對帳一致性、均價計算準確性證明
Production Readiness Review — 確認 12 位交易員 UID 權限配置完成

關鍵實作技術要求

1. 事件驅動架構（高併發撮合回報）⁶

採用 Kafka 或 RabbitMQ 作為成交回報中轉站。上手券商回報訊息 (35=8) 先進隊列，多個 Consumer 同時處理 R6 寫回與 UI 推播，避免大量成交造成系統阻塞。

2. R6 強一致性事務⁶

TCC 三階段（Try / Confirm / Cancel）確保分散式環境下，客戶的錢與訂單狀態永遠同步。

3. 仿 Bloomberg UI 低延遲渲染⁶

前端 Blotter 必須使用 Canvas 或 WebGL 渲染技術（如 AG Grid Enterprise），應對每秒數千次 Tick data 跳動，維持 60 FPS 流暢度。

4. 故障自動轉移⁶

主動模式 — 監控偵測 Bloomberg Session 中斷，OMS 500ms 內完成路由重定向至備援 DMA
被動模式 — 訂單送出後若一定時間未收到回執，絕對不可盲目重送；應進入 Pending / Unknown / Manual Intervention 狀態（避免重複下單，見 gpt 修正版 ⁷）

5. Idempotency 設計（去重與重播）⁷

對回報與補送流程建立 idempotency key / broker order token / duplicate check，避免重複成交或重複下單：

Session failover 可以自動
Order replay 必須建立 idempotency key
若無法確定市場端是否受理，進入人工介入狀態

補充資訊

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

LLM Wiki

探索

OMS Algo 映射與 R6 整合技術規格

OMS Algo 映射與 R6 整合技術規格

目標

第一部分：Algo 參數映射引擎

1. 映射邏輯架構1

2. VWAP 策略 FIX Tag 映射範例1

3. 動態參數 JSON Schema1

4. 映射錯誤攔截（Pre-trade Validation）1

第二部分：R6 API 深度整合

1. 整合交互流程（TCC Try-Confirm-Cancel）2

2. R6 購買力檢核 API2

Request（OMS → R6）

Response（R6 → OMS）

3. 非同步降級機制2

4. 匯率快取機制2

第三部分：母子單均價計算引擎

即時 VWAP 均價3

母單撤銷的遞迴處理3

第四部分：FIX 訊息流實例

1. 母單接收（New Order Single 35=D）4

2. 轉發子單至上手券商（帶 Algo 參數）4

3. 成交回報（Execution Report 35=8）4

第五部分：上手券商 FIX 認證測試清單

一、Session 層測試（FIX 4.4）5

二、基本訂單生命週期測試5

三、Algo 策略映射測試5

四、異常降級與 SOR 備援測試5

五、最終交付物5

關鍵實作技術要求

1. 事件驅動架構（高併發撮合回報）6

2. R6 強一致性事務6

3. 仿 Bloomberg UI 低延遲渲染6

4. 故障自動轉移6

5. Idempotency 設計（去重與重播）7

相關頁

補充資訊

參考資料

Footnotes

關係圖譜

目錄

反向連結

1. 映射邏輯架構¹

2. VWAP 策略 FIX Tag 映射範例¹

3. 動態參數 JSON Schema¹

4. 映射錯誤攔截（Pre-trade Validation）¹

1. 整合交互流程（TCC Try-Confirm-Cancel）²

2. R6 購買力檢核 API²

3. 非同步降級機制²

4. 匯率快取機制²

即時 VWAP 均價³

母單撤銷的遞迴處理³

1. 母單接收（New Order Single 35=D）⁴

2. 轉發子單至上手券商（帶 Algo 參數）⁴

3. 成交回報（Execution Report 35=8）⁴

一、Session 層測試（FIX 4.4）⁵

二、基本訂單生命週期測試⁵

三、Algo 策略映射測試⁵

四、異常降級與 SOR 備援測試⁵

五、最終交付物⁵

1. 事件驅動架構（高併發撮合回報）⁶

2. R6 強一致性事務⁶

3. 仿 Bloomberg UI 低延遲渲染⁶

4. 故障自動轉移⁶

5. Idempotency 設計（去重與重播）⁷