Fortex：交易平台、Bridge OMX 橋接、API 與 XCLOUD

Fortex 為經紀商及機構市場參與者開發交易平台、流動性連接與託管基礎設施。其產品範圍涵蓋 Fortex 7 交易介面、AlgoX 策略引擎、適用於 MetaTrader 的 Bridge OMX、配備 XBook 撮合引擎的 ECN 平台、開發者 API，以及 XCLOUD 基礎設施服務。釐清這些元件的分工十分重要：經紀商可能正在評估一套交易平台，也可能需要為現有 MetaTrader 業務建立連接，或為多套系統配置底層基礎設施。

Fortex 成立於 1997 年，據公司介紹，其服務對象包括經紀交易商、區域性銀行、對沖基金、資產管理公司及專業交易者。Fazzaco 的 Fortex 公司檔案將其歸入交易軟體、橋接技術及網路解決方案類別。本文聚焦公開產品架構，以及經紀商部署時需要理解的業務關係；評估對象是技術供應商的產品與服務，而非零售交易帳戶。

Fortex 產品如何融入經紀商的技術架構

從交易者的操作畫面，到處理、路由及記錄訂單的後端系統，Fortex 涵蓋多個環節。這些能力彼此相關，但採購需求仍應逐項界定。下表將各項產品與其用途對應，並列出可用於評估的實際演示內容。

Fortex 7：整合平台中的交易操作入口

Fortex 交易平台頁面將 Fortex 7 定位為整體平台的使用者介面，具備市場深度、多語言存取及自有品牌配置能力。頁面列出 Windows、Linux 與 macOS 桌面環境，以及 HTML5 網頁介面。對經紀商而言，這提供了建立自有品牌客戶體驗的途徑，同時將交易活動接入供應商的執行基礎設施。

實際評估不應只停留在交易畫面是否熟悉。團隊需要檢查交易品種的呈現方式、訂單處理、帳戶歷史，以及異常狀況如何分別顯示給交易者與交易管理團隊。這些視圖保持一致，有助於降低客戶查詢成交結果或帳戶變動時的調查工作量。

Fortex 在2026 年 10 月 14 日發布的產品文章中，將 Fortex 7 描述為結合交易、流動性連接、執行與風險管理，並支援 CRM 整合的方案。這裡描述的是系統整合關係，並不能據此認定所有 CRM、開戶或客戶管理功能都是 Fortex 的原生模組。

AlgoX：自動化策略的開發選擇

AlgoX 是 Fortex 7 所包含的演算法交易引擎。公開說明列出 JavaScript 與 C#，供開發者編寫自動化交易策略。對已使用這些語言的企業而言，團隊可將技術選擇與既有工程能力及開發工具一併評估。

熟悉程式語言只是部署的一部分。策略運作還取決於市場資料事件、交易品種定義、下單權限，以及連接狀態改變時的處理方式。因此，技術演示應包含一個可以觀察其決策、訂單提交與回應的小型策略，讓團隊檢查執行過程，而不只是查看已完成的績效圖表。

對經紀商營運而言，核心問題是自動化與監督機制如何銜接。團隊可確認如何識別策略產生的訂單、查找異常交易背後的事件，以及在必要時停止後續下單。這些是針對擬議配置提出的驗收問題，不代表標準 AlgoX 套件已包含所有被詢問的控制功能。

Bridge OMX：擴展現有 MT4 或 MT5 業務

Bridge OMX 提供了接入 Fortex 技術的另一種方式。它的用途是將 MetaTrader 4 與 MetaTrader 5 環境連接至 Fortex 的交易執行及流動性基礎設施。保留現有客戶交易平台的經紀商，可以據此評估連接與交易管理能力，無須將整個項目視為前端平台的全面更換。

官方產品頁面列出按交易域設定報價、訂單流內部化、自動交易處理、分配功能、omnibus 與 minibus 帳戶、自動避險及報表。這些功能的營運意義，在於報價分發、進場訂單處理與最終風險敞口之間的關係。評估橋接方案時，應連續追蹤這些環節，而不是將它們當成互不相關的功能項目計數。

例如，交易管理團隊可要求演示兩組採用不同執行設定的客戶，再將各組訂單與避險活動及報表逐一核對。Fortex 亦介紹了受管理託管服務與白標部署選項。適用的平台使用權、配置責任及持續服務範圍，都應在提案中明確列出。

ECN、XBook 與交易執行及風控的銜接

Fortex ECN 平台將流動性聚合與訂單處理結合。在這套架構中，Fortex 將 XBook 描述為撮合引擎，用於在市場中呈現訂單，並與可用流動性進行撮合。公司同時列出按企業、交易域、個別帳戶、資產類別及貨幣對監控風險敞口的能力，以及風險警示和自動保證金處理。

對經紀商而言，這套架構的價值取決於資訊是否能連續傳遞。一筆成交應可從執行紀錄追蹤至風險敞口視圖，再延伸至營運報表。驗收時，可在這些視圖中比對一連串成交、部分成交及部位變動，讓交易管理與對帳團隊共同檢視相同事件。

Fortex 將其 BackOffice 入口描述為支援交易處理、結算、帳戶對帳單、報表與管理的工具。採購方應將這些功能與自身會計及申報要求逐一對應。接入交易執行技術，本身並不等於已確定商業上的流動性合作關係，也不能代替特定經紀商需要履行的申報義務。

連接外部交易應用與內部系統的 API

來源：Fortex 官方 API 頁面，截圖於 2026 年 10 月 17 日。畫面為廠商產品演示，並非獨立效能測試。

Fortex API 方案包含 FIX、WebSocket 及 RESTful 介面。其公開定位涵蓋專業交易機構、量化開發者及外部應用程式開發團隊。API 頁面也介紹了對 XForce 功能的存取，包括風險管理、多家流動性提供商連接及自訂流動性。

這些介面為整合項目提供了多種可能途徑，但所選協定必須符合實際工作流程。既有機構訂單連接的需求，可能與瀏覽器應用程式或內部營運服務不同。實作討論應明確指出每項必要操作與資料欄位由哪個介面提供，並界定身分驗證及帳戶權限。

重新連接是特別值得測試的情境。測試用戶端連接中斷後，經紀商應能說明如何取得具權威性的訂單與部位狀態，並避免重複操作。就此而言，API 文件、範例訊息及雙方確認的錯誤處理流程，比籠統地宣稱整合容易更有助於判斷實作要求。

XCLOUD：交易系統的託管與營運支援

XCLOUD 被定位為 Fortex 的基礎設施即服務業務，提供專用伺服器、虛擬私人伺服器及連接服務。其託管頁面明確列出紐約 Equinix NY4、倫敦 LD5 及香港 HK3。這些是託管方案所列的地點；個別部署的實際位置與網路拓撲，仍應另行確認。

同一頁面介紹了 MetaTrader 安裝、既有伺服器遷移、外掛與資料源、備份與災難復原伺服器、維護及監控支援。監控項目亦包含過期報價偵測與警示。因此，除了伺服器規格，營運模式同樣重要：當基礎設施仍在運作，但交易服務出現異常時，經紀商需要知道由誰負責處理。

實際託管評估應追蹤從客戶連接、交易伺服器、橋接系統到交易對手的完整路徑。團隊可要求提供標示各段連接責任歸屬的架構圖，並進行有明確責任分工的復原演練。網路位置的接近程度可以作為部署規劃依據，但仍需量測經紀商實際訂單路徑的表現。

部署範圍、CRM 整合與商業條款

Fortex 在 2026 年 10 月的文章中，著重討論跨多家供應商協調交易、流動性、執行、風控、CRM 及託管所產生的成本。其主張是，更整合的安排有助於減少重複整合工作，並釐清營運責任。對採購團隊而言，這是一項值得結合自身系統及合約進行驗證的提案。

第一步可先建立範圍文件，區分 Fortex 原生功能、接入的第三方應用，以及仍由經紀商負責的工作。CRM 整合尤其需要具體界定：哪些紀錄需要交換、每筆紀錄由哪個系統主導，以及更新失敗後如何核對與補正。CRM 連接應避免讓兩套系統各自保留互相衝突的客戶狀態。

公開交易平台頁面提到，MT4／MT5 WebTrader 服務採用按處理量計費的方式。這項特定產品的說明，不應直接套用為 Fortex 7、Bridge OMX、ECN 服務或 XCLOUD 的統一計價規則。採購方應要求逐項列明所選產品、實施、託管、連接、支援及可能按使用量收取的費用。本文不據此推算整套平台的價格。

Fortex 在經紀商供應商選擇中的位置

Fortex 對三類評估路徑尤其具有參考價值：考慮採用 Fortex 7 交易環境的經紀商、評估 Bridge OMX 的 MetaTrader 營運商，以及為既有架構尋找 XCLOUD 託管或 API 存取方案的企業。即使多項元件最終整合為同一套部署，不同路徑仍需要不同的驗收標準。

較有說服力的選擇流程，是沿著真實工作流程檢查擬採用的產品。演示客戶下單、交易執行、風險敞口變化、報表及事件處理，並將每個環節對應至明確的商業責任。如此，經紀商便能從相互連接的技術方案角度評估 Fortex，同時清楚掌握自身團隊仍需承擔的整合與營運工作。

資料來源與核驗：Fortex 官方交易平台、Bridge OMX、ECN、API 及 XCLOUD 頁面，2026 年 10 月 14 日產品文章，以及 Fazzaco 公司目錄，均於 2026 年 10 月 17 日查閱。上述產品描述以公開資料為依據；部署演練與採購問題屬於 Fazzaco 的編輯分析。