常見問題
EBS FinTech 提供企業級技術、實施及基礎架構支援服務。我們並非經紀商、流動性供應商、託管機構、監管機構或律師事務所,亦不接收客戶資金。對於 MetaQuotes、監管機構、流動性供應商或其他獨立第三方所作出的審批決定、報價、成交品質、正常運行時間或服務條款,我們不作任何保證。
01 概覽
EBS FinTech 提供哪些服務?
我們協助經紀商規劃、部署及營運交易基礎架構。核心服務包括 MT5 完整伺服器授權(業內通常稱為主標授權)的申請協調與技術建置、現有 MT4/MT5 環境維護、伺服器託管與日常維運、流動性及 Bridge 連接,以及部分 CRM、KYC/AML 和支付系統的整合協調。
EBS FinTech 的服務對象是誰?
我們只服務企業客戶,主要包括經紀商、金融機構及其他符合資格的企業。確認專案前,我們會審核申請主體、牌照、司法管轄區及相關供應商的准入要求。
EBS FinTech 是否向零售客戶提供交易或投資服務?
不提供。我們不會為零售客戶開設交易帳戶、招攬存款、以經紀商身分執行交易、管理投資或保管客戶資金。
02 MT5 授權與建置
EBS FinTech 支援哪種 MT5 授權申請?
我們支援符合資格的企業申請完整的 MT5 伺服器授權,業內通常稱為主標授權。我們可以協助界定技術範圍、協調申請流程,並在獲批後建置伺服器環境。授權協議由 MetaQuotes 簽發,申請資格、商務條款及審批時間均由 MetaQuotes 自行決定。
申請新的 MT5 是否必須持有監管牌照?
MetaQuotes 會執行自身的客戶准入及 KYC 審查,並可能要求申請人提供其認可的監管牌照和公司資料。相關要求可能調整,亦可能因申請主體及司法管轄區而異,因此在預估時間或結果前,應先核實個別申請人的資格。
EBS FinTech 能否保證 MetaQuotes 批准申請?
不能。我們可以協助評估申請準備情況、協調文件及完成技術工作,但是否與申請人簽約完全由 MetaQuotes 決定。
EBS FinTech 是否提供新的 MT4 授權?
不提供。MetaQuotes 目前通常不再簽發新的 MT4 伺服器授權。對於已經持有必要授權及存取權限的客戶,我們仍可託管、維護和遷移其現有的合法授權 MT4 環境。
EBS FinTech 是否為 MetaQuotes 授權經銷商?
不是。我們是獨立的技術及實施服務商。MetaQuotes 授權需要另行簽約,並始終受 MetaQuotes 自身審查及合約條款約束。
03 MT4/MT5 基礎架構與維運
持續性的 MT4/MT5 服務可以包括哪些內容?
視所選服務方案而定,服務範圍可包括伺服器配置與安全強化、平台更新、參數設定與變更管理、存取權限管理、監控、日誌檢查、備份檢查、容量規劃、故障初步排查以及第三方供應商協調。
EBS FinTech 是否管理外掛程式、Gateway 和 Bridge?
在客戶具備有效授權、技術文件及供應商存取權限的前提下,我們可以協調安裝、設定、測試及變更管理。第三方開發商仍須對其軟體、修復、保證及合約服務水準負責。
EBS FinTech 是否測試 EA 和伺服器端外掛程式?
用戶端 EA 與伺服器端外掛程式屬於不同元件。我們可以協助重現相容性或效能問題,並在約定環境中測試相關伺服器變更,但不會為任意第三方程式碼提供認證,亦不保證 EA 或外掛程式的具體運作結果。
緊急故障如何處理?
故障等級、溝通管道、回應目標及升級路徑由適用的技術支援方案或服務協議確定。涉及第三方服務中斷時,我們會進行初步排查,並在需要時升級至相應責任供應商。
04 託管、備份與營運持續性
MT4/MT5 環境可以部署在哪裡?
伺服器架構可圍繞主要金融中心及雲端服務區域設計,但需考慮供應商可用性、資料駐留要求、LP 接入點及客戶預算。最終區域、伺服器規格及網路設計會在專案範圍確認階段確定。
EBS FinTech 是否保證特定的延遲水準?
不存在適用於所有專案的統一延遲數值。實際延遲取決於伺服器位置、LP 或 Bridge 接入點、網路路徑、平台負載及其他第三方系統。如有需要,可在專案中確定可量度的延遲目標及測試方法。
服務是否包括高可用及災難復原?
可在部署方案中加入相關設計。備份頻率、保留週期、備援架構、復原程序及 RTO/RPO 目標取決於所選架構和服務方案;除非報價或協議明確列出,否則不應視為預設包括。
05 流動性、橋接與聚合
EBS FinTech 是否為流動性供應商?
不是。我們可以協助評估、引薦及技術接入獨立的流動性供應商,但最終仍須通過各供應商的准入審查並另行簽署合約。
每家 MT5 經紀商都需要 Bridge 嗎?
不一定。部分環境使用 MT5 Gateway,另一些則透過第三方 Bridge 或聚合器使用 FIX 連接。合適的方案取決於 LP 所提供的介面、執行模式、路由要求及營運控制需求。
流動性接入通常包括哪些工作?
常見範圍包括接入點協調、交易品種與合約規格映射、報價與訂單流驗證、執行參數、加點設定、拒單測試、模擬與真實環境分離、日誌檢查、上線測試及回復規劃。
甚麼情況下需要流動性聚合?
當經紀商使用多個流動性來源,並需要統一報價、路由規則、執行控制或提高連接韌性時,通常會考慮聚合。只使用一家 LP 且具備受支援 Gateway 的經紀商,未必需要獨立的聚合層。
如果 LP、Bridge 或聚合器發生故障,由誰負責?
相關第三方供應商須按照其自身合約對其服務負責。EBS FinTech 可以在約定的支援範圍內協助收集證據、進行技術排查及協調供應商,但不會承擔該供應商的流動性、成交、正常運行時間或合約責任。
06 第三方系統整合
是否可以整合 CRM、KYC/AML 和支付系統?
通常可以。我們可以協調受支援的第三方系統與交易平台或後台流程的整合。可行性取決於 API、技術文件、存取權限、安全要求及所選供應商。
EBS FinTech 是否作出 KYC 決定或處理付款?
不負責。身分驗證、篩查及支付處理由所選第三方供應商和客戶自身的合規及營運團隊完成。EBS FinTech 的責任僅限於約定的技術整合與支援。
是否可以接入客戶已經選定的供應商?
通常可以,但需要先進行技術評估。確認專案範圍前,我們需要了解供應商支援的介面、技術文件、測試權限、商務授權及故障升級聯絡人。
07 安全、資料與存取權限
可以實施哪些安全控制?
安全措施可包括作業系統強化、網路分段、IP 限制、多因素驗證、最小權限存取、傳輸加密、金鑰與憑證管理、監控、稽核日誌及 DDoS 防護。具體措施取決於架構及合約範圍。
客戶資料儲存在哪裡?
資料儲存及備份區域會在架構設計階段選定,並記錄於專案範圍中。客戶仍是其客戶資料的控制者或責任主體,並須確認有關設計符合適用的私隱、資料保留及監管要求。
哪些人員可以存取生產環境?
生產存取權限應只授予獲授權人員,並透過具名帳戶、權限設定、審批流程及日誌管理。具體存取模式會與客戶共同確定,亦可能受到 MetaQuotes 和第三方供應商要求的限制。
08 遷移與上線
是否可以遷移現有 MT4/MT5 環境?
可以,但客戶必須具備所需授權、管理員權限、資料權利,並取得相關供應商配合。遷移範圍可包括架構評估、伺服器部署、設定映射、歷史資料或其他資料處理、測試、切換及回復規劃。
MT5 部署需要多長時間?
沒有適用於所有專案的固定週期。MetaQuotes 准入審查、監管準備及第三方審批均不屬於純技術建置範圍。相關前置條件滿足後,時間仍取決於伺服器架構、交易品種、Group、流動性、系統整合、測試及品牌設定。完成需求分析後,我們會提供專案計劃。
是否提供測試和營運人員培訓?
專案範圍可以包括 UAT 支援、設定檢查、上線清單、管理員交接及日常營運指引。
09 價格與技術支援
價格如何構成?
專案通常包括一次性實施費;如需持續託管或技術維運,亦會收取定期服務費。MetaQuotes、雲端服務、資料中心、LP、Bridge、CRM、KYC 及支付供應商費用可能另行收取,除非報價明確說明已經包括。
最終報價由哪些因素決定?
主要因素包括交易平台及授權狀態、伺服器架構、部署區域、預期負載、環境數量、流動性路徑、第三方整合、遷移要求、安全控制及支援覆蓋時間。
是否提供 24/7 技術支援?
符合資格的託管維運方案可以提供監控和隨時候命的工程支援。具體覆蓋時間、故障等級、回應目標及溝通管道必須以適用的報價或服務協議為準。
10 合規與責任
EBS FinTech 是否提供法律或監管意見?
不提供。我們可以協調技術要求,並與客戶委任的專業顧問合作,但客戶須自行取得法律、稅務及監管意見,並持續持有其業務所需的全部批准。
誰負責客戶准入及 AML 管控?
經紀商或其他受監管客戶負責制定政策、風險評估、客戶盡職審查、制裁篩查、持續監控、記錄保存及監管申報。接入技術系統不會將這些責任轉移給 EBS FinTech。
是否為受制裁對象或受禁止司法管轄區提供服務?
不提供。服務可用性取決於 EBS FinTech 自身的盡職審查、適用的制裁及出口限制,以及 MetaQuotes 和其他相關供應商的准入規則。
11 關鍵術語表
經紀業務基礎架構關鍵術語
- 主標:業內對直接與 MetaQuotes 簽署合約的完整 MetaTrader 伺服器授權的常用稱呼。
- MT5 Gateway:用於連接 MT5 與受支援流動性場所或交易所的連接元件。
- Bridge:連接交易平台與外部報價及執行場所的第三方軟體。
- FIX API:用於訂單、成交及市場資料傳輸的機構級訊息協議。
- 聚合:整合多個流動性來源的報價並在其間執行路由。
- A-Book:將相關客戶訂單流或由此產生的風險敞口路由至外部交易對手的模式。
- B-Book:由經紀商在內部承接並管理相關風險的模式。
- RTO:故障發生後恢復服務的目標時間。
- RPO:故障發生後資料應恢復至的目標時間點。
- UAT:生產上線或重大變更前進行的使用者驗收測試。
找不到相關問題,請嘗試使用較廣泛的關鍵字。
