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/5 WebTrader 服务描述为按处理交易量计费。这一特定产品的说明，不应延伸为 Fortex 7、Bridge OMX、ECN 服务或 XCLOUD 的统一定价规则。采购时应要求分项报价，列明选用产品、实施、托管、连接、支持及可能与使用量挂钩的费用。本文不据此推算整个平台的价格。

Fortex 在经纪商供应商选型中的位置

Fortex 尤其对应三类评估路径：考虑采用 Fortex 7 交易环境的经纪商；评估 Bridge OMX 的 MetaTrader 运营方；以及希望为现有架构评估 XCLOUD 托管或 API 接入的企业。即使最终将多个组件纳入同一部署方案，各条路径的验收标准仍有所不同。

有效的选型过程应让一项真实业务流程贯穿拟采用的产品。演示客户提交订单、执行、敞口变化、报表生成及事件处理，并为每个阶段明确商业责任。这样，经纪商既可以将 Fortex 视为一套相互连接的技术产品进行评估，也能清楚掌握自身团队仍需管理的集成和运营工作。

资料来源与核验：本文于 2026 年 10 月 17 日核验 Fortex 官方交易平台、Bridge OMX、ECN、API 和 XCLOUD 页面、其 2026 年 10 月 14 日发布的产品文章，以及 Fazzaco 公司目录。文中产品介绍依据上述公开资料；部署演练建议和采购问题属于 Fazzaco 的编辑分析。