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建议透过整体策略思考，打造支持合规、协作且具竞争力的核心银行架构。
