LLM Wiki

FSTS 介接規格書（FIX／API／SFTP／銀行／保管行／會計）

閱讀時間約 14 分鐘

FSTS 介接規格書（V1.0 呈核版）

定義新一代複委託系統對外與對內介接規格基線，作為需求確認、系統分析、程式開發、聯測驗收與後續維運之共同依據。1

平台前提：MSSQL / .NET Core / UNIX(Linux)。1 編製單位：凌群電腦／專案規劃團隊。1 回到 Planning 總覽。

文件目的與適用範圍

1

本文件涵蓋：

  • FIX Gateway（上手交易）
  • 前台 API（客戶／分公司）
  • 批次檔案交換（SFTP）
  • 銀行與保管行介接
  • 會計介接
  • 監控告警與錯誤回補

本版為呈核版本：建立可發包、可估工、可驗收的接口治理框架。正式專案啟動後，各上手券商、銀行、保管行及內部相依系統仍須個別產出 ICD（Interface Control Document）與 Message Mapping 表。1

五條介接設計原則

2

  1. 核心交易域與介接域解耦：OMS、成交、清算、帳務不直接依賴單一上手格式，統一先轉成 Canonical Message
  2. 同步與非同步並存：下單／改單／刪單屬低延遲同步流程；成交回報、檔案交換、對帳與補單採事件化與批次並行
  3. 固定欄位與彈性擴充並存：針對市場別、商品別、上手別保留 Extension 欄位與 Mapping 規則
  4. 不可否認與可追溯：所有介接訊息均應有 Message ID、Correlation ID、來源系統、時間戳、簽章／摘要與留存政策
  5. 可觀測與可重送：每一條介接流程需可被監控、回放、重送、人工介入與差異追蹤

整體介接架構（三層 + 監控）

3

建議採三層式介接架構：

介接層級主要用途典型協定關鍵設計重點開發優先級
Channel/API Layer客戶與內部前台即時查詢／下單HTTPS REST、WebSocket驗證授權、限流、Idempotency、追蹤碼P1
Gateway/Adapter Layer與上手、銀行、保管行、會計等外部系統對接FIX、SFTP、MQ、DB Link欄位轉換、重送、序號控管、容錯P1
Canonical Service Layer統一交易事件與主資料語意Internal API / Event Bus避免直連耦合、版本化、審計軌跡P0
Monitoring/Control介接監控、補送、重跑、告警Dashboard、Alert Hook營運可視性、Runbook、值班支援P0

設計關鍵：Canonical Service Layer 與 Monitoring/Control 同列 P0，反映「先把核心語意與可觀測性建好，才能承接上手差異」的原則。3

FIX Gateway 規格基線

4

FIX Gateway 為核心外部交易介面，負責與海外上手／執行券商進行 Session 管理、委託傳輸、成交回報、拒單、補傳與對帳。

項目規格基線功能作用重要性開發順序
FIX SessionFIX 4.2 為主，保留升級至 FIX Latest 之映射能力建立標準化交易訊息通道最高1
Session 控制Logon／Logout／Heartbeat／TestRequest／SequenceReset／ResendRequest維持連線穩定與序號正確最高1
交易訊息NewOrderSingle／OrderCancelRequest／OrderCancelReplaceRequest／ExecutionReport／Reject承接委託全生命週期最高1
Mapping Layer上手別欄位模板、代碼映射、Tag 規則避免 OMS 與單一上手耦合最高1
Replay & Archive訊息封存、查詢、補送與重播支援對帳、稽核、事故回復高2
健康監控Session 狀態、延遲、拒單率、重送次數支援 7×24 維運高2

FIX 介接最少交付物

5

  • Session 設定表
  • CompID 清單
  • IP／Port 與白名單
  • 交易時段表
  • MsgType／Tag Mapping
  • 欄位必填規則
  • Reject Code 對照表
  • 證券代碼轉換規則
  • 重送與斷線復原流程

API／Web 通路規格

6

介面群組主要 API用途安全要求優先級
委託交易POST /orders、PATCH /orders/{id}、DELETE /orders/{id}下單、改單、刪單OAuth2／JWT、簽章、Idempotency-KeyP1
交易查詢GET /orders、GET /trades、GET /fills委託與成交查詢權限分級、欄位遮罩P1
資產查詢GET /balances、GET /positions、GET /buying-power現金、庫存、可交易額度資料新鮮度標示P1
客戶服務POST /withdrawals、GET /statements、GET /notifications出金、對帳單、通知雙因子／覆核P2
管理與監控GET /health、GET /metrics、POST /replay健康檢查與補送內網限定、特權審批P0

API 設計要求

7

  • 所有交易類 API 均須支援 Request ID 與 Correlation ID，便於前中後台問題追蹤
  • 交易 API 須支援 Idempotency Key，避免通訊抖動導致重複送單
  • 查詢 API 應回傳資料版本與產生時間，避免營運端誤判即時性
  • 對外 API 與內部 API 必須分級管理，避免把管理權限暴露到前台

檔案交換（FTP／SFTP）規格

8

用途：銀行入出金、保管行交割、行情／商品主檔、日終對帳、會計分錄、歷史資料匯入。統一採 SFTP + PGP／檔案摘要驗證。

檔案類型來源 / 去向頻率主要欄位範圍控制重點
銀行入金回饋銀行 → 複委託日內多次客戶帳號、幣別、金額、交易序號、入帳時間重複入帳防呆、異常金額告警
出金放行檔複委託 → 銀行日內多批申請單號、覆核資訊、受款帳號、金額四眼原則、批次摘要覆核
保管交割檔複委託 ↔ 保管行日終／交割日證券代號、數量、DVP／RVP、交割日期交割狀態追蹤、差異表
會計分錄檔複委託 → 會計日終會計科目、借貸、幣別、金額、來源交易重拋機制、分錄平衡檢核
商品／行情檔外部來源 → 複委託日更／盤中代號、名稱、市場、價格限制、FX版本控管與上下架

銀行、保管行與會計介接要點

銀行介接

9

  • 入金對帳：依虛擬帳號／交割帳號／流水號入帳，需支援重複交易檢核與異常待人工池
  • 出金放行：申請 → 覆核 → 放行 → 回饋四階段；需保留審批與回執完整軌跡
  • FX／匯兌：若涉及換匯，需區分申請匯率、成交匯率與實際入帳匯率

保管行介接

10

  • 交割模式需支援 DVP／RVP、自由交付及例外人工調整
  • 需保留交割失敗原因碼、補交割流程與差異清單

會計介接

11

  • 採事件轉分錄，不應由會計系統反向決定交易語意
  • 每一筆分錄均需帶來源交易主鍵、會計期間與重拋批次號

監控、錯誤處理與補送規格

12

監控面向指標／事件建議閾值處置方式
FIX SessionDisconnected、Sequence Gap、Reject 爆量5 分鐘內未恢復即升級自動重登／人工介入／停送某上手
API5xx 比率、逾時、平均延遲1 分鐘內連續高於基準流量保護、重試、降級
SFTP 檔案到檔延遲、摘要不符、檔名不符逾 SLA 即告警通知窗口、人工收補、批次延後
銀行／保管行對帳金額／數量差異任何差異均需建單差異清單、責任歸屬、補正
資料一致性委託／成交／清算狀態不一致單筆即列管事件回補、重跑、人工覆核

版本管理與驗收要求

13

  • 各類接口必須有版本號（例 FIX Session Profile v1.0、Order API v1、Bank SFTP Layout v1.2）
  • 欄位異動分為相容升級與破壞性升級；破壞性變更需經 CAB／專案 Steering Committee 核准
  • 介接驗收應至少涵蓋：Happy Path、錯誤碼、逾時、重送、斷線復原、重複送單防呆、差異對帳
  • 正式上線前需完成 SIT、UAT、外部聯測、平行測試與 Cutover Drill

建議開發順序（4 波）

14

波次主要交付理由預估期間
Wave 1Canonical Service、FIX Session、Order/Trade API、監控框架先建立交易閉環與介接底座0–6 月
Wave 2銀行／保管行／會計 SFTP、差異對帳、Replay 工具建立交割與營運閉環7–12 月
Wave 3客戶服務 API、通知、報表分發、監理介接分化通路與營運能力13–18 月
Wave 4高可用、容量優化、上手擴充、介接治理平台化支援正式切換與多市場擴張19–24 月

Review 結論

15

本文件已從**「列出要串什麼」提升到「如何以金融級治理把接口做成」。真正的風險不在是否能接上，而在是否能於多上手、多市場、多通路情境下穩定營運**，因此本規格將 Canonical Message、Replay、對帳、監控與版本化納入 P0／P1 範疇。

建議正式發包時，把本文件列為 RFP 附件，要求各投標廠商分別回覆：

  • FIX 能力成熟度
  • 銀行／保管行導入經驗
  • 日終批次與補帳工具能力
  • 介接事故處理 SLA

相關頁面

補充資訊

2026-04-23 CI 同步版本校對

fb.fsts main 分支透過 CI 同步至 _raw/projects/fsts/docs/project/planning/富邦證券_新一代複委託系統_介接規格書.md（hash d791005f5325）。本頁的三層介接架構（Channel/API、Gateway/Adapter、Canonical Service）＋ Monitoring、五條設計原則、FIX Gateway 規格、API/SFTP/銀行/保管行/會計介接、監控與版本管理要求、4 波建議開發順序皆維持不變。161718

重點校對結果：

  • Canonical Service Layer + Monitoring/Control 同列 P0 — 設計關鍵一致17
  • FIX 4.2 為主，保留升級至 FIX Latest 映射能力 — 規格基線不變19
  • Wave 1–4 規劃（0–6 月 Canonical+FIX+Order API+監控；7–12 月 SFTP+差異對帳+Replay；13–18 月客戶服務+通知+報表分發+監理；19–24 月 HA+容量優化+上手擴充+介接治理平台化） — 一致18
  • RFP 發包時要求投標廠商回覆四項：FIX 能力成熟度、銀行/保管行導入經驗、日終批次與補帳工具能力、介接事故處理 SLA — 一致20

參考資料

Footnotes

  1. 11 介接規格書 §一 文件目的 ↩ ↩2 ↩3 ↩4 ↩5

  2. 11 介接規格書 §二 介接設計原則 ↩

  3. 11 介接規格書 §三 整體介接架構 ↩ ↩2

  4. 11 介接規格書 §四 FIX Gateway ↩

  5. 11 介接規格書 §四 FIX 交付物 ↩

  6. Web 通路 ↩

  7. 11 介接規格書 §五 API 設計要求 ↩

  8. 11 介接規格書 §六 檔案交換 ↩

  9. 11 介接規格書 §七 銀行介接 ↩

  10. 11 介接規格書 §七 保管行介接 ↩

  11. 11 介接規格書 §七 會計介接 ↩

  12. 11 介接規格書 §八 監控與錯誤處理 ↩

  13. 11 介接規格書 §九 版本管理 ↩

  14. 11 介接規格書 §十 建議開發順序 ↩

  15. 11 介接規格書 §十一 Review 結論 ↩

  16. 介接規格書（CI 同步版）§二 介接設計原則 ↩

  17. 介接規格書（CI 同步版）§三 整體介接架構 ↩ ↩2

  18. 介接規格書（CI 同步版）§十 建議開發順序 ↩ ↩2

  19. 介接規格書（CI 同步版）§四 FIX Gateway 規格基線 ↩

  20. 介接規格書（CI 同步版）§十一 Review 結論 ↩

關係圖譜

反向連結