Red Hat憑藉開放混合雲，加速推動Open Banking創新
- 尤嘉禾／台北
-
近年隨著疫情加速變革節奏，大幅影響消費者與企業的行為，連帶為金融科技業者帶來新挑戰。種種變革紛至沓來，驅使台灣金融機構必須重新詮釋其服務，以期滿足客戶期望，且為自身營運能量做好相應的準備。
此外金管會於2019年推出「開放銀行」（Open Banking）計畫，不久之後即將邁入計畫的第三階段「交易面資訊」，意謂金融業須有能力透過非傳統管道來提供金融交易服務，並支持銀行交易平台營運。
為協助金融機構做好充分準備、面對上述挑戰，Red Hat於日前舉辦「金融機構數位韌性的新發展：開源創新的下一關鍵」高峰論壇。Red Hat身為開源軟體解決方案的領導品牌，不僅可讓金融機構實踐現代化系統、流程自動化、應用交付簡單化等目標，還有助於提高彈性、效率及加快上市時間；因此透過這場活動，Red Hat偕同Intel、TCS BaNCS、Finastra等金融生態系重要夥伴，聚焦分享如何借助關鍵方案，加速推動Open Banking布局。
Red Hat副總經理陳蔚華致詞表示，為強化本次活動的議程內容，作為主辦方的Red Hat，盛邀國立政治大學金融科技研究中心主任王儷玲教授，剖析今後Open Banking創新發展脈絡。不僅如此，也邀請包含Red Hat亞太區總部、及Finestra和TCS（Tata Consultancy Services）等策略夥伴的多位海外專家，聯手分享全球Open Banking趨勢。
從Partner API到Open API，有助加快開發進程
率先登場的王儷玲教授，以「開放銀行創新趨勢與數位轉型」發表演說。她指出綜觀全球開放銀行，大致分為政府強制、政府鼓勵以及市場驅動三種模式；目前已有30餘國投入開放銀行，其中英國、歐盟及澳洲的發展相對蓬勃，已培育眾多相關新創公司，其中不乏獨角獸。
談到開放銀行的重要發展方向，第一就是「消費者資料賦權」，由消費者擁有資料權，可授權透過第三方業者交換資料與服務。第二為「透過API建立跨業資料共享」，藉由API來串聯平台的服務與商品，如澳洲制定Consumer Data Right（CDR）法案，開放金融、電信、能源等產業可跨產業使用消費者資料。第三是「由開放銀行走向開放金融生態圈」，如新加坡的API Playbook蘊含大量多元API，使開放銀行輕易整合TSP（第三方服務提供者）提供完整金融服務。
至於國際開放銀行運作模式，也包含三大類。首先為「銀行即服務」（Bank as a Service），像是提供API給第三方串接，或結合第三方打造生態圈，擴增金融應用場景。其次是「銀行即平台」（Bank as a Platform），集結多項外部金融服務到銀行平台或Super App中。最後是「提供金融服務API」、或稱「White Label」，譬如有業者取得金融牌照，但不實際經營客戶，僅提供金融服務API。
台灣開放銀行採取三階段進程，前兩階段已順利施行，惟第三階段因有資料識別問題尚待突破，暫時處在Pending狀態。她歸納台灣開放銀行面臨幾個較大問題，包括銀行與TSP的合作被定義為「委外關係」，在法源上不利開放銀行長遠發展。另外舉凡個資法不利於資料交換、尚無消費者賦權法制可規範API交換、缺乏可取信銀行的第三方身分認證…等，都是問題之所在。
政治大學為加快台灣開放銀行發展腳步，提出TSP與API資安分級方法，顧名思義就是根據TSP分類與API服務等級進行風險等級配對，確保銀行與TSP的合作都建立在資安風險可控的基礎上；例如小型TSP可買資安保險來提高風險承擔能力，爭取銀行信任。
王儷玲另提到，台灣目前在實務上多使用Partner API，由銀行自行開發API與TSP直接串接，尚無共通規格，導致資料介接取得成本偏高。未來期望能形成標準格式的Open API，以吸引更多TSP願意投入金融創新應用。
靈活可組合架構，確保開放金融永續運轉
接著由Red Hat亞太區金融服務部門總監Arvind Swami、Red Hat台灣首席資深解決方案架構經理Joe Yu緊接依序登場，共同闡釋「開放銀行中的開放平台如何為業務帶來敏捷性和增長」主題。
Arvind Swami認為，之所以掀起開放銀行變革浪潮，主要源自4個驅動因素，前兩項是大家熟知的即時、體驗，此外一是讓客戶獲得想要的便利、一是社群參與。但與其稱為「開放銀行」，不如稱「開放金融」更加適切，因為開放銀行只是開放金融的一個子集，顯見開放金融範圍更大，甚至涵蓋客戶360度金融投資組合的所有構面。
目前在開放金融的發展上，出現一些挑戰。首先是採用速度緩慢，尤其支付是一個十分明顯的落後環節，甚至像是澳洲CDR，規定第三方須經由客戶同意才能使用數據，也造成速度放慢。其次一些金融機構的進展也有遲滯現象，他們不願意、或沒有能力提供API給其他生態系統。此外開放銀行、開放金融的下一步正是超個人化行銷（Hyper Personalization），其間需收集與處理大量數據，接著觸及AI/ML、邊緣運算，在技術面亦充滿挑戰。
金融機構如何迎向開放金融？一開始許多業者從API著手，惟著眼於可擴展性、性能、數量等考量，業者其實更需建立「靈活的可組合架構」，否則中台與後台終將出現瓶頸；因為所有金融服務最終仰賴後端提供，而不是前端的API。
Red Hat台灣的Joe Yu補充說，開放銀行系統須奠基在彈性、韌性、安全、穩定的基礎平台，譬如Red Hat OpenShift Container Platform（OCP）即是全球常見的典型案例。但他強調，OCP不只是Kubernetes（K8s）環境，而是一個完整平台，可為創新應用提供諸多支持。首先OCP的底層為「Just Enough」作業系統，拿掉所有不需要的東西，以利營造更安全、更穩定的環境，也讓Red Hat更能同時基於Linux OS、Container和K8s來設計整合管理架構，讓用戶只需一鍵發動Over-the-air Upgrade，便可由系統自動Interlock相關的相依性，順利完成升版。
再者Red Hat提供豐富Middleware架構，可廣泛支援Spring Boot、JBoss、Node.js、Ruby、Python、.NET…等各種應用程式Runtime。而在Middleware之上，用戶不論要運行傳統服務、新型態的微服務，甚至一些功能即服務（Function as a Service）都可以。
Finastra與TCS BaNCS，從支付、核心系統來詮釋開放銀行
Finastra亞太區支付部門主任David Brown，以及Finastra新加坡、越南及台灣區銷售總監Sam Tan，聯手解析ISO 20022與未來支付趨勢。Sam Tan指出， Finastera為全球最大的支付系統供應商，客群涵蓋三百多家銀行，而在台灣的合作夥伴是神通（MiTAC）。
David Brown表示，隨著開放銀行發展，及ISO 20022的影響性逐步發酵，現在正是一個發展支付系統的好時機；背後存在幾個重要驅動因素，例如有愈來愈多的客戶、尤其是國際客戶，期望使用基於ISO 20022的服務。
故對金融機構來說，目前正是導入ISO 20022的最佳時刻，只因此標準有助於業者快速專注在所需更改，不必再耗時處理常規標準、交易格式等合規作業。與此同時，業者亦需一併思考引入容器化、雲原生等技術，以便妥善支持新的支付策略。
更重要的，ISO 20022將在2025年11月之前陸續生效。就現狀而論，金融機構擁有手機銀行、網路銀行…等多個通路支付，另外亦須面對不同清算系統，如SWIFT跨境支付，本地的「即時總額清算」（RTGS）、即時付款、代收代付等，還有諸如Visa Direct等替代路徑；若業者想在ISO 20022架構下，藉由輕鬆插拔、快速啟用替代路徑類型產品，或力求更順暢地處理複雜的SWIFT、RTGS交易，即可借助諸如Finastra Global PAYplus之類的支付中心方案。總之ISO 20022意在讓整個支付產業的訊息更加協調一致，有助於銀行加快與其他各種方案的整合，為開放銀行業務打下良好基礎。
此次應Red Hat邀請為活動站台的另一夥伴，即是TCS印度商塔塔顧問服務公司，其TCS BaNCS資深解決方案架構師Ankur Arya以「在開放銀行發展中，您的核心系統有何作用？」為題，發表本次論壇的最後一場演說。
當今開放銀行浪潮席捲全球，惟仔細觀察各國發展態勢，卻又不盡相同。例如英國是基於金融科技生態而發展開放銀行，由監管機關主導；反觀澳洲，雖同樣由監管機關主導，但發展初衷並非針對金融科技，而是CDR數據計畫。因此業者不妨從不同維度來解析各國開放銀行計畫，包括「誰在主導」（監管／強制vs.自願／選擇）、「生態系統參與者」（TSP／金融科技生態系統vs.客戶資訊交換生態系統）、「最終目標」（金融服務新措施vs.資料政策新措施）、「金融價值鏈中的角色」（生產者模式vs.經銷商模式vs.整合者模式vs.平台模式）。
上述維度之所以重要，係因會影響到系統架構。以業務目標為例，若是在銀行與TSP間建立生態系統，即需明確定義API標準，並在現行核心系統上建立API介面層；若是如同澳洲般啟動客戶間的數據交換，則可複製核心資料，並透過微服務進行CQRS讀寫分離的查詢交易。
在實現開放銀行系統架構的過程，TCS BaNCS可望起到莫大作用。首先TCS BaNCS所有組件兼能支援本地、雲端或混合託管等部署模式；可在容器化基礎設施上部署為雲原生微服務，進而彈性擴展；符合標準API規格，同時支援IFX、英國開放銀行、PSD2、CDR等。
多位專家對話交流，闡述開放銀行實踐之道
這次論壇的壓軸好戲，是由Red Hat台灣總經理孫媛音主持的焦點座談，與談人除了Finastera的Sam Tan外，還包括TCS BaNCS產品總監劉仲威、Intel技術專案經理湯承倫。
孫媛音說，許多銀行對Open Banking既期待又怕受傷害。期待的點在於當開放銀行進入第三階段，不管產品查詢或交易類型皆可上雲，對使用者的便利性更高；至於怕受傷的點，在於銀行身為服務提供者，需準備的項目急遽增多。
湯承倫認為，如何在第三階段執行時被有效解決資安，為重大課題。這時Intel近年持續發展的SGX加密運算（Confidential Computing）可派上用場，確保整個生態系統的安全性，能從底層開始就受到保護。
Intel在多國皆有金融業成功案例，利用SGX強化資料保護。如英國的全英建築房屋貸款協會，是提供土地資產信用貸款的銀行，其痛點在於核貸時要做徵信，因而調閱個人PII資料，須善盡保護之責；啟用SGX後，可把資料直接存入Memory當中加密保護專區，其間不會經過Hypervisor或OS，資料保全性極高。
劉仲威表示，已看到有不少銀行客戶，從核心系統上直接提供Open API，有效解決交易、電文等方面的整合問題。現在舉凡Embedded Finance、Behavior Banking…等都成為大勢所趨，旨在讓客戶很舒服地啟用任何服務、滿足日常生活所需；因此台灣若一眛沿用Partner API，不僅辛苦且整合速度慢，應轉向全球或區域型標準格式的API，以利快速跨境、實現更多整合運用。
Sam Tan指出，開放銀行對支付的影響，在於衍生眾多小額支付進入銀行支付系統，故支付系統要能負荷這些交易量。如今很多業者亟欲導入ISO 20022，因為它可帶動STP直通率提高，也由於可參考的訊息量增多，有望大幅優化交易對帳作業，讓機構的競爭力就此提升。
如何讓支付系統順利承載激增的交易量？Sam Tan強調應該系統更有彈性、能支援Auto Scale，因此走向微服務與容器化為必經之路。
最後由孫媛音進行總結。回顧本次議程，一開始王儷玲教授談到從Partner API邁進Open API的重要性；Red Hat主張藉由開放混合雲，打造一個深具彈性且靈活組合的開放銀行架構；Finastra強調現在是發展支付系統的佳機，且能順勢與ISO 20022進行接軌；TCS BaNCS建議透過整體策略思考，打造支援合規、協作且具競爭力的核心銀行架構。
