FEP 擬真測試之可行性研究

作者/范綱元

【內容摘要】金管會強化資安監理，要求系統異動前完成擬真測試，銀行前端交易系統(FEP)首當其衝。然市場缺乏通用測試工具，各銀行架構、規則差異大，加上人力有限、舊系統限制，測試工作長期仰賴人工。隨系統現代化與可稽核要求提升，自動化測試需求日增。凌羣憑藉深厚FEP開發經驗，研發開放式自動化測試工具，以標準API對外開放，搶占市場先機，深化銀行合作關係。 【TAG 關鍵字】#FEP #擬真 #測試 #金融 #銀行

作者簡歷

作者現任凌羣電腦金融產品研發處專案處長，專職於專案執行及新技術研究。

監理驅動需求：FEP是資安合規的樞紐

金管會近年持續強化金融資通安全的監理要求，明確規範金融機構在系統上線或重大異動前，必須透過「擬真測試」驗證交易安全性、系統穩定性與法規遵循程度。無論是電文安全欄位的驗證、跨行交易的互通性檢核，或是配合「金融資安行動方案2.0」定期執行的資安攻防演練，都讓擬真測試從選項變成銀行資訊部門的必要功課。 在此監理背景下，銀行前端交易處理系統(FEP)扮演承上啟下的關鍵角色——一端銜接財金公司、ATM、網銀、行動銀行等外部通路，另一端串接核心主機。FEP系統一旦有任何規格調整、程式過版，或是周邊系統因應資安漏洞進行修補，都必須重新驗證交易流程是否正常運作，測試需求可謂常態且頻繁。

市場空白與產業困境，亦是機會所在

然而，觀察目前市場現況，卻找不到一套現成可用的通用型測試工具。原因在於每家銀行的核心系統架構、內部稽核制度與業務規則差異極大，測試工具若要真正貼合實務，勢必得高度客製化，難以標準化銷售，也不易做成SaaS服務。多數銀行的資訊服務商因此僅能依個案需要，開發零星的小型測試程式應急，缺乏統一整合的效率與可持續性，市場上也就一直沒有出現真正產品化、可對外銷售的解決方案。 這也點出銀行業普遍面對的困難。長期以來，銀行測試工作高度仰賴人工，測試人員需反覆輸入電文、比對結果，專案結束移交銀行內部維運後，往往缺乏足夠人力持續進行重複性作業與品質把關；導入商用測試工具，又得面對投資回收期長、資安審查與IT風控流程繁瑣等現實考量；再加上不少銀行仍保有大量COBOL、Mainframe架構，系統之間欠缺開放的自動化測試介面，ATM、FEP、網銀等系統又分屬不同廠商，要串起一致的整合測試流程並不容易。除了各銀行客戶環境本身的差異之外，測試資料同樣帶有時效性與唯一性限制，例如交易日期、流水序號等欄位必須配合當下情境即時產生，無法沿用過去的歷史資料重複測試；而用於驗證電文安全性的金鑰交換機制與運算方式，各銀行也各有規則與差異，使得同一套測試邏輯難以直接套用於不同銀行。此外，測試資料受個資法與金管會規範，必須採用去識別化或模擬資料，種種因素都讓工具設計必須格外謹慎、難以一體適用。 儘管挑戰不小，這也正是機會所在。隨著金融機構加速系統現代化，從COBOL逐步移轉至Java、.NET等開放架構，中介系統與外部服務介接日益頻繁，回歸測試的需求只會有增無減。同時，金管會與財金公司對於測試紀錄可稽核、可重放、可審核的要求日益明確，意味著未來的測試工具不僅要能執行測試，更要能完整留存執行軌跡，作為稽核與合規佐證。可以預見，模擬環境搭配自動化測試，將逐漸成為金融系統升級專案中不可或缺的一環，這也讓具備開放介面、可延伸串接能力的測試工具，有機會在市場站穩腳步，甚至成為銀行汰換舊架構過程中的關鍵配備。

用開放架構，搶先定義銀行測試新標準

面對這樣的產業趨勢與需求缺口，凌羣電腦憑藉數十年深耕銀行資訊服務的經驗，長期承作多家銀行FEP系統的開發與建置，對銀行交易流程、電文規範與系統整合有深刻理解。基於這樣的基礎，凌羣投入研發「銀行FEP擬真自動化測試工具」，鎖定測試個案管理與測試執行自動化兩大核心，協助銀行大幅降低人工重複性作業負擔，提升測試效率與品質一致性，也讓專案移交後的內部維運更加輕鬆。 更重要的是，凌羣在工具設計上採用開放性介面架構，測試個案的觸發與呼叫以標準化API方式進行，並將此規格對外開放，即使不是由凌羣建置FEP系統的銀行，也能委託既有的資訊服務商依此規格開發對接，不受限於單一廠商綁定。這樣的設計不僅呼應了銀行客戶對彈性與自主性的期待，也讓凌羣得以在目前市場尚無成熟解決方案的空窗期搶先卡位，藉此深化與銀行客戶的長期合作關係，為後續更多測試相關服務需求，預先埋下溝通的契機。