开放银行的国内实践及监管重点

1.国内银行业开放银行发展初期的模式趋同

国内开放银行的实践主要是将银行服务能力输出至合作方平台，因此存在一定的同质性。银行通过线上技术的方式，把金融产品和服务，嵌入合作方自己的应用程序和场景。在输出方式上，均以API为主，也支持H5方式；在输出内容上，主要是银行在底层账户管理基础上，附加投、贷、付等核心功能和基础服务为标准配置。

以建设银行为例，开放银行管理平台于2018年8月正式上线，首批推出了聚合支付、e账户、信用卡账单分期、龙支付钱包四大产品服务，采用了标准统一的接口（API）封装到软件开发工具包（SDK）中，以产品的概念对外发布，为第三方开发者提供开发、注册、认证、申请及购买的一站式服务管理，支持多平台应用注册，并提供标准化的便捷接入流程。

2.国内外监管差异导致发展路径有所不同

（1）自顶向下、监管驱动的国外开放银行。

以欧盟和英国为例，开放银行是由监管推动的。英国主要由竞争和市场管理局主导开放银行服务计划，并由财政部牵头成立工作组对外发布监管框架，初衷是为了推动中小企业的繁荣发展，提高金融行业的竞争效率。此类监管驱动的国家和地区，对于开放银行的政策与实施细节都有严苛的规定，除了建立完善的治理架构、严格准入第三方服务商，还拟定了详细的数据安全策略。如，英国把数据分为开放数据、客户交易数据、客户参考数据、聚合数据和商业敏感数据五类，并根据每类数据涉及客户隐私程度的不同，对第三方金融机构设置不同读写权限。

（2）倒逼转型、市场驱动的国内开放银行。

与各种不同的商业生态有机对接、融合并提供无处不在的金融服务，是一种比较典型的“平台+服务”运作模式。当前，工行、建行、浦发、招行等国内银行基本都形成了以API为媒介、以场景为切入的新型业务模式，意图通过开放银行将各类金融产品和服务，甚至将非金融服务能力，向同业、用户、合作伙伴开放，无感融入客户的生产和生活场景，开放银行发展迎来了金融科技能力和金融服务场景竞争的时代。

3.针对开放银行的监管架构正逐步完善

金融科技重构了金融服务业的交易规则，与此同时，风险相伴而生。今年2月，央行发布了《商业银行应用程序接口安全管理规范》，对于商业银行与场景应用方合作，应用程序接口设计（API）、集成运行、运维监测及系统下线等全生命周期过程提出安全技术与安全管理要求，这是我国监管机构发布的首份关于开放银行的规范。

此外，开放银行适用的相关监管法规和要求还包括：《信息安全技术个人信息安全规范》《信息安全技术网络安全等级保护基本要求》和《中华人民共和国网络安全法》等。

开放银行业务发展中需关注的几类主要风险

1.数据泄露风险

既然开放银行以数据共享为核心，那么在共享过程中数据泄露就是首要面对的风险。开放银行的业务模式相比传统银行业务，将数据存储、传输、使用链条拉长，如果在此过程中存在薄弱环节或设计缺陷，就有可能遭受恶意攻击，导致数据泄露，甚至可能将数据用于非法之途，产生安全隐患。

2.第三方机构风险

开放银行的重要内容是与第三方机构合作，在合作过程中对于第三方机构的选择也是风险的重要来源。无论是将服务嵌入到其他场景，还是开放平台与第三方合作，都涉及到第三方能否恰当运营、应用金融服务的问题。如果第三方不恰当使用银行数据及产品，就可能借用银行渠道实现非法目的，导致产生洗钱、资金空转套利等问题。

3.逃避监管风险

在银行直接与客户对接的情况下，其业务产品及流程较为清晰，可以有效地实施监管。但在开放银行的实践过程中，由于业务链条拉长，以及通过第三方平台提供业务，可能存在借产品创新之名迂回逃避监管的问题，本来明令禁止的业务，可能通过第三方平台进行包装提供，使监管效果下降，并可能产生金融风险。还可能产生资金绕开监管而投入到限制性领域的风险，从而导致货币政策调控效果下降，与开放银行的业务初衷背道而驰。

开放银行的IT审计切入点

在开放银行业务快速发展的同时，审计作为公司治理中风险管理的第三道防线，势必要发挥出其监督及建设职能。《商业银行应用程序接口安全管理规范》的出台，为开放银行业务审计提供了指引。结合银行业的IT审计实践，笔者认为，至少有以下三方面的审计切入点。

1.技术合规及数据、网络安全

一方面，接入主体较多导致银行数据安全风险加大。开放银行通过API的方式连接了多方主体，如果任何连接一方存在安全薄弱环节或服务接口有设计缺陷，或权限设置不当都可能提高整个系统数据泄露的风险，进而导致客户数据被非法获取。另一方面，依托互联网渠道也导致银行数据安全风险加大。API通过互联网共享数据，如接口使用不当或被恶意攻击时，可能导致银行业务的连接中断，影响客户正常使用。此外，开放银行接口属于面向外部的服务，面临着访问漏洞等安全风险，一旦漏洞被恶意利用，将导致服务器被入侵等不良后果。如果安全性校验、安全加固等保护措施实施不到位，还存在被应用方恶意篡改、逆向调试、二次打包等风险。

因此，针对API接口的技术合规性审查，以及应用方相关交易链的信息安全审计至关重要。内部审计关注的重点主要有：

一是身份认证鉴别安全。从开发设计角度看，开放银行需严格执行安全控制机制，结合网络安全手段和参与者合作身份校验机制，通过访问权限控制、签名认证、跨域校验等，尽可能避免API接口安全漏洞和被盗用的风险。

二是第三方安全管理。应审慎选择合作方，针对用户授权访问后的数据保护建立健全安全机制，对合作方使用接口开展的业务范围等进行严格控制，并定期审核，在授权范围内进行有效的控制和防护。对于合作方的业务数据和用户信息数据的使用范围、保存期限等进行明确约束，遵循范围和期限的最小化原则。

三是敏感信息防泄漏。应通过网络传输链路加密、身份认证、报文加密加签等多种方式，保障数据传输的安全性、隐私性和不可篡改性。严格控制对业务、用户数据的访问权限，避免被恶意使用开放银行接口非法抓取大量数据，并对系统日志中的敏感信息进行特殊处理，还要实现后台操作日志可审计。

四是网络边界防护。应遵循“纵深防御”的理念，在互联网边界、API服务层和业务层之间部署防火墙、入侵防御设备，实时监测、分析异常流量，智能感知风险态势，快速拦截外部攻击或自动阻断非法访问。

2.开放银行平台的运营管理

从业务层面来看，开放银行平台支持API对外发布、API接入的流程管理，并监控开放银行业务的运营情况；从技术层面来看，开放银行平台还提供了权限管理、流量控制、故障隔离及应用方全生命周期技术支持等功能。因此，一个功能强大的开放银行平台，不仅能提高运营效率，而且是开放银行业务与银行核心业务风险隔离的第一道“防火墙”。

针对开放银行平台的运营管理，建议内部审计主要关注以下三个方面的问题。一是接口安全分级管理，应对开放的接口进行分级分类，根据不同业务类别和风险程度设定接口使用权限和使用期限；二是业务安全监控手段，应采用大数据风控技术，实时、全方位监控业务运行情况，对异常交易和异常参与方，能做到实时流控、快速阻断，保障系统稳定；三是业务风险预警能力，应采用基于事后分析回溯的大数据风控技术，实现业务风控，防范例如营销欺诈、交易欺诈、信用欺诈等业务风险。

3.IT运行风险

技术和业务模式的开放性也意味着风险的开放，第三方对银行数据和接口的使用更多的是提供服务，风险控制的核心主体仍然是银行本身，银行在很大程度上要单方面承担输入风险、输出风险以及内外部风险叠加形成的新风险。建议内部审计关注的重点有以下方面。

一是开放银行相关的各类共享主体彼此之间相互紧密联系，一家银行或者金融科技公司的技术风险会迅速蔓延到其他关联方，导致系统性运行风险。

二是开放银行的合作模式还要求银行应与合作方之间提前建立充分的缓冲和隔离机制，以免风险出现时造成严重的后果，甚至带来法律和声誉风险。这对银行业原有的科技风险治理架构、边界、标准、能力等提出了新的挑战。

三是开放银行的发展依赖先进的技术，而技术漏洞往往不可避免，需要及时监测、有效跟进。再者，不适当的操作、信息系统宕机等会引发不可预期的风险，从而增加开放银行在实践中的操作风险。

针对开放银行的IT审计，还涉及外包管理系统安全、应用安全和基础设施安全策略的执行情况，以及事件与问题管理、变更管理、业务连续性管理等运维流程，但均未超出常规IT审计的范畴，本文不再赘述。