【台湾Open Banking银行实例】开放API要发威，国泰世华先大力改造中台强化IT体质

今年3月，财金公司成立了开放API研究暨应用发展委员会，并在委员会底下又成立开放API研究咨询小组，同时往下设立技术分组与资安分组，共同制订与推动开放API标准。

银行圈对API并不陌生，早就用于串连各种合作伙伴。但是，“现有API没有一套共通的规格和语言。”国泰世华银行资讯总管理处副总经理王志峰特别强调。这也是作为开放API研究咨询小组召集人的他，认为各家银行在与第三方业者合作时，最大的问题。

由王志峰与15家银行的代表，正站在台湾开放银行之路的第一线，一起为这个痛点找答案。 而在财金公司订定API标准的过程中，每每会透过开放API研究咨询小组会议，先与小组的银行成员讨论，希望找出可统一所有银行的作法，也希望可以有更大的应用。

所以，从第一阶段的开放API技术标准，就参考了国际Open API Initiative组织的OpenAPI Specification（OAS）作为Open API技术规格的一致性标准，并遵循OAS规范的RESTful API定义，使API互通界面不受程式语言限定。

除了参考国际标准，在API设计上，王志峰表示，国泰世华更是提供了自家内部开发API的实务经验和标准，作为标准订定时的参考。像是国泰世华已采用了可帮助开发人员设计、建构、记录和使用RESTful Web服务的Swagger标准，后来也纳入第一阶段的标准中。

使用同一套Swagger框架来设计API，不论在API的功能规格、参数设计都有一套规范，任何一家TSP，不需要重新了解每一家银行的API设计方式和定义就能开始串接，可以加快开发时间。甚至，财金还加上了API版本规范，更方便用来维护不同版本的API。

这意味着，以后第三方业者与银行API的串接，会有一套更明确的共通介接作业方式，而不只是大方向的规范。

另一个好处，王志峰指出，这次等于统整了银行彼此资料交换和串接的标准，银行间彼此也可以快速透过Swagger设计的API，与其他人快速串接。等于是，所有银行开发者间也有了一套共通的API沟通语言。

目前，在第一阶段公开资料查询API的支援上，已有API介接经验的银行，像是中信、台新、凯基、国泰世华都迅速完成支援，其他银行也很快就跟上。但王志峰认为，第二阶段API的导入难度会更高，不是所有银行都能跟得上，他希望，可以透过更详细的API订定参考与经验交流，协助小规模的银行，提高对外API介接的能力。

资安标准上也会朝国际主流标准靠拢，举例来说，到了第二、第三阶段会采用资安要求更高的身份验证机制，目前偏向采用国际常见的OAuth 2.0。王志峰解释，原因是，接下来会涉及使用者资料，其中又分为身份证号码（IDN）或是机敏性资料，像是信用卡卡号，就得考虑到要有加解密的作法。目前，已有银行开始进行OAuth 2.0的串接验证，国泰世华就是其中一家。王志峰提到，国泰会慢慢导入这样的作法，让自家金融服务能朝国际主流标准前进，他相信，各家银行也应如此。

王志峰提到，Open Banking的精神，得回归到资料所有权是客户的观点，银行得基于客户同意下，以安全的方式提供出客户资料。他也认为，当TSP业者提供的服务备受客户青睐时，客户会选择有与TSP合作的银行，优先使用其金融服务。这也是国泰积极拥抱Open Banking的原因之一，“跟得上的银行，比较不会在数位转型风潮中被市场淘汰。”王志峰强调。

国泰也认为，Open Banking对银行与TSP来说，应该是互惠关系。不仅是银行单方面提供资料，银行是各家TSP业者合作的集中处，也可以趁机吸收TSP的创新策略与服务。若以这角度来看，银行本身的角色，不见得会边缘化。

甚至，台湾已有像联合征信中心、电子发票整合服务平台，以及许多户役政单位，国泰认为，这些都是国外没有的机构或角色，是发展Open Banking的基础建设，若他们未来也能加入开放的行列，台湾在开放银行之路会走得更快。

打造技术与服务中台，分流核心系统交易量

尽管目前Open Banking的话题焦点是Open API、TSP业者管理等，但若要能彻底落实开放API，对银行来说，还有一个更大的考验，就是自身平台系统的体质是否健全。

Open API要做得好，王志峰认为，银行后面支援的平台没有做好准备，其实会很辛苦。所以，国泰世华第一个要解决的，就是资讯架构问题。过往，随着各种业务需求的增加，直接在银行核心系统不断扩充功能，导致核心系统越来越庞大，但是，这些业务可能不见得是银行的核心业务。王志峰提到，核心系统每天高达9成工作量都只是进行查询，只有1成以下才是真正的交易。当银行系统要支援不可预期的Open API需求时，“最大的瓶颈，还是银行后台核心系统的承载力。”

为了解决这个问题，国泰的作法是，将查询或批次能处理的系统或服务转移到中台，核心系统只保留交易功能，借此来分流，以提高核心系统的承载容量，并透过银行中台的横向整合，“让核心系统回归它原来的功能”他强调。

甚至，国泰世华内部还特别定义出技术中台和服务中台的资讯架构概念，成立了一个中台发展部，负责银行中台架构与服务的设计。王志峰提到，国泰内部IT，人人都能到这个部门学习中台的开发方式与技能，随着越来越多IT成员熟悉这些能力，就能发挥出中台的综效，这也是国泰转型计划的一部分。

打造中台微服务与私有云平台，强化IT体质拥抱Open Banking

国泰从去年就开始打造银行中台微服务的原因，同时也一并引进了私有云容器化平台，也将银行内部各系统的介接统一采用API，以利弹性缩放平台上服务所需的运算资源。而银行中台也可以进行服务整合，同样以API对外提供服务给第三方。

国泰世华银行中台发展部经理黄一峯解释，一般来说，支付API每秒可提供300次交易（TPS）就算很好的效能了，而国泰世华几年前，开始协助合作通路钱包发展行动支付所需的API平台，系统承载量可以达到每秒500笔以上（TPS）的交易，不只当时，也是目前业界最高者。

但，国泰没有因此而停下脚步，还大动作升级IT架构来强化体质，国泰世华银行中台发展部经理郑正略表示，去年中，国泰开始导入微服务架构，来打造中台微服务，进一步将银行的大型系统，拆解成一支支小型服务，更容易快速伸缩这些服务的规模。

正导入APIM管理自家API

目前，国泰也正在导入API管理平台 （API Management，APIM），来管理自家的API。王志峰提到，因为国泰除了60多支的对外API，连银行内部各系统介接，现在也都统一采用API进行跨系统呼叫，总数高达750多支API。“这么做的原因是，希望内部系统的介接标准一致，即便哪天得换掉某一套系统，API串接仍保持一致，其他系统不用特别修改写法就能继续呼叫。”

架构调整后，王志峰透露，若从国泰内部系统来呼叫中台的服务API，光是账单服务现在可以提供到每秒4,000次呼叫的能力。他提到，这代表，国泰技术中台的承载力提升了，而且容量可以横向扩充，这样的能力不只是这一支账单服务独有，其他服务也都可以具备。

这样的架构，让国泰更有能力将更多服务集中到中台，目前，王志峰提到，国泰会优先将客户在数位通路最需要的服务，集中到中台上，让前台的数位通路，例如App，或是与其他服务介接时，能以最快的速度对外提供服务。未来，国泰将继续将更多核心系统的服务，迁移到现在的中台架构上，最后目标是，核心系统只负责单纯的存、汇功能。