BIS | 通过API机制实现开放金融

本篇文章主要研究了开放式金融生态系统中各方进行交互验证的主要需求，国际清算银行（Bank for International Settlement）针对该诉求与目前遇到的主要问题提出了API机制（Application Programming Interface）这一解决方案。开放金融系统需要对用户进行远程，安全的标识和身份验证，因为这可以确保不同实体的用户确实发出了给定请求。此外，开放和标准化的API方案可以为所有感兴趣的各方提供参与开放金融生态系统所需的互操作性。中国人民大学金融科技研究所（微信ID：ruc_fintech）对论文核心内容进行了编译。

作者 | BIS Representative Office for the Americas

来源 | Bank for International Settlements

前言与背景

01

为满足国际清算银行（Bank for International Settlement，下文简称BIS）中央银行在美洲技术创新和数字经济领域加强合作的需要，创新与数字化经济咨询工作组（Consultative Group for Innovationand the Digital Economy，下文简称CGIDE）于2020年2月成立。国际清算银行全力支持这一目标，因为技术创新是其中期战略Innovation BIS 2025的重点关注领域。技术变革正在扰乱支付系统、财务中介和金融市场，这是中央银行领域所关注的核心问题。CGIDE的建立十分及时，因为美洲部分国家正在改进零售支付系统并监管其金融科技部门，以提高竞争力和增强金融包容性。

创新与数字化经济咨询工作组CGIDE致力于以下目标：

1. 发展公共技术基础设施以应对所有司法管辖区的共同缺陷；

2. 通过开发应用程序接口（Application Programming Interface），来营造适合于开放银行的环境；

3. 从市场结构和监管影响角度分析这些公共技术基础设施的意义。

2020年2月，CGIDE开启了第一个任务——探索开发用于识别和身份验证API的技术，一种可用于实现无缝扩展的私人和公开管理的开放金融解决方案。本报告标志这项任务的成功完成。该方案允许用户安全地将其财务凭证输入到交易流程中，在金融机构和第三方之间建立安全的关系。虽然没有中央银行支持采用开放银行或经过分析的身份识别和认证API方案，但该文件仍然可以为想要开发自己支付计划的中央银行提供有用的一般参考。

一个开放的金融生态系统，通过建立一个不同参与者的竞争优势可以得到发挥的环境，为人们提供更好的金融服务，能够使金融系统参与者和整个社会受益。

创新与数字化经济咨询技术专门工作组（The Technical Task Force of the Consultative Group for Innovation and the Digital Economy），下文简称CGIDE TTF 负责开发身份认证应用程序接口(API)，以实现具有无缝可扩展性的私人和公开管理的开放金融解决方案。CGIDE TTF将向CGIDE报告：

1. 用于身份验证的集中API模型的技术方案；

2. 设计和运营此类基础设施所涉及的网络安全问题。

远程和安全的用户识别和身份验证是开放金融生态系统中各方进行交互的主要要求，因为这确保了不同主体的真实请求。此外，一个开放和标准化的API机制可以为所有相关方提供参与开放金融生态系统所需的互操作性。特别地，CGIDE TTF正在分析一种基于移动设备的API机制，以支持金融机构用户的远程、安全和有效的识别和身份验证。这一机制基于建立一个中心验证器（Central Validator），允许在金融机构和第三方之间建立安全的关系，而不需要他们相互直接联系。这是通过在中心验证器和第三方之间，以及在金融机构和中心验证器之间建立的联系实现的。中心验证器的安全计划将确保计划中的所有连接都在以前认证的实体之间建立，以便通过第三方有序地提供金融服务。此外，中心验证器还通过特定方式确保每一服务提供方只会访问特定金融服务所需的用户信息。

CGIDE TTF的工作并不包括审查通过API实现安全和远程识别和身份验证的所有可能的替代方案，而主要针对可行API架构的分析和设计。从这个角度来看，本文件应该只应作为那些想要发展自己的支付计划的个别国家的一般参考，因此没有任何成员支持采用开放银行业务或经过分析的身份识别和认证方案。不同辖区的机构正在努力设计和实施各种识别和认证API方案，以支持开放金融生态系统。例如，欧洲中央银行，欧洲银行业管理局和印度国家支付公司。

开放金融对于金融系统发展的重要性

02

开放式金融允许通过第三方提供金融服务，这些第三方在以下方面具有潜在竞争优势：

1. 当前的用户网络的覆盖范围；

2. 公众对其信息管理系统已经建立信任；

3. 简化和直观的用户体验，带来了便利和熟悉感。

开放金融服务根据其对强认证程序的要求，可分为两大类：

1. 不一定需要进行强身份验证的金融服务，包括通过第三方接口访问公开数据（如金融机构的产品列表或可用基础设施）；

2. 需要远程和安全的强身份验证的金融服务，包括需要使用第三方设施来访问或检索个人和交易信息的服务，以及远程启动交易（例如支付指令的触发，保险或投资等金融服务的合同签订）。提供这一类的服务需要一个远程和安全的替代方案来识别和认证用户，因为它需要访问并交换私有数据。

一个开放的金融生态系统可以在多方面使所有金融系统的参与者受益。现有金融机构可以通过间接使用传统上无法获得的数据源，来评估向客户提供服务的可行性，例如通过与第三方的电子商务或其他平台上评估给予他们信贷的可能。同样，金融机构也可以通过第三方为用户设计和提供量身定制的服务，并更好地利用现有的技术，为用户提供更好的服务体验。

同时，通过与金融机构合作，非金融第三方可以扩大其服务范围，并为更多的用户提供服务。此外，通过提供金融服务，这些公司可以吸引更多的用户到其核心业务平台。最重要的是，用户可以受益于定制的金融服务和更好的客户体验（这可以让他们通过同一渠道访问各种服务）。此外，在经常性服务提供者的平台上纳入金融服务将使更多的用户能够享受其利益，并扩大财务包容性。

开放金融实施方案

03

开放金融生态系统的设计深受识别和身份验证API架构的影响，这是整个体系的基础。该体系架构的决定性特征之一是它如何处理开放金融生态系统的参与者之间的联系。建立这种联系的主要选择包括：(i)集中化连接；(ii)多边（双边或独立网络）连接。两种可选方案各有利弊，在某种程度上相互映证。

集中化连接

在这种类型的结构中，有一个所有参与者都需要连接的中心参与者。这意味着在开放金融生态系统中存在着一个独特的连接网络，由系统的中心实体设定的标准来控制。

优势：

• 针对所有有意参与开放金融生态系统的各方的准入要求是相同的，这使得监管机构更容易监管和监督该生态系统；

• 集中化解决方案的治理使得具有重大市场权力的实体更难在生态系统内施加条件。例如，相比双边关系系统，掌控巨大网络的第三方在系统中具有更弱的话语权。

缺点：

• 从业务连续性的角度来看，集中化的实现可能增加服务暂停的次数，因为中心实体一旦出现问题影响运行，可能会影响到整个金融系统；

• 由于所有连接都按照中心实体设定的要求实施标准化，创新可能会受到一定程度的阻碍；

• 类似地，如果特定行业没有被给予特殊条件，一些商业模式可能会在标准化网络中难以发展。

多边（双边或封闭网络）连接

在这种类型的架构中，开放金融生态系统参与者之间有不同的连接网络，它们可能有不同的准入要求。这意味着网络参与者可以决定谁进入他们的网络，以及网络是否会针对一个特定的部门。不同网络之间的勾连互通在操作性上是可能的，这取决于不同独立网络所有者的共同协议和激励对齐。

优势：

• 依赖这种架构的开放金融系统可能对于服务暂停有更强的适应能力。如果实现互相可操作性，原则上来说，如果某一特定网络在特定时间不可用，用户可以在网络之间切换；

• 由于网络可能将服务集中在不同的部门，潜在的生态系统参与者可能发现只连接到系统的一个子集更有利；

• 这种系统网络拥有不同的准入和操作标准，这一定程度上可能会促进第三方金融服务创新。

缺点：

• 由于每个网络的治理可能有所不同，因此市场的力量可能会发挥作用。具体来说，一些有关各方可能被拒绝访问某个特定网络，可能被排除在市场之外；

• 多元网络系统的存在可能会削减监管部门的激励和监督职能；

• 总的来说，开放金融生态系统中的网络的复杂性可能更高，因为需要更多的连接来实现完全互连。反过来讲，这可能意味着一个对不同市场部门感兴趣的参与者可能比使用集中的API架构付出更高的连接成本。

决定应该实施哪种类型的API体系结构取决于每个司法管辖区的特征。此外，领导这一系统实施的只能是政府机构或者行业权威。在这方面，由不同API系统结构支持的一些开放金融模型的示例包括：

• Europe’s revised Payment Services Directive (PSD2) 

  欧洲第二次支付服务指令

• The UK Competitions and Market Authority (CMA) 

  英国竞争与市场管理局

• Open Banking Implementation Entity (OBIE) 

  英国开放银行实施实体

• Unified Payments Interface (UPI) 

  统一支付接口

• Account aggregators (AAs) framework 

  账户聚合器框架

• Singapore’s Financial Planning Digital Services (FPDS)

  新加坡金融规划数字化服务

• Brazil’s open banking initiative 

  巴西开放金融协议

API机制实现路径

04

如上所述，每个管辖权的理想解决方案将取决于几个因素，如行业对API机制设计的参与程度、法律赋予领导其实施的机构的权力、开放金融生态系统期望涵盖的目标用例或期望的用户体验。从这个角度来看，本文应仅作为希望制定自己的付款计划的个别国家的一般参考。

下面，我们概述了通过使用具有处理API体系结构中安全连接的中心验证器（CV）的API方案，通过第三方识别和用户验证的一般过程：

1. 用户将在其设备上安装其选择的第三方应用程序以及CV身份验证应用程序。

2. 用户与第三方一起登录，以请求所需的金融服务。

3. 第三方请求用户输入识别其金融机构所需的信息，以及与其请求相关的金融产品或服务。

4. CV应用要求用户输入他们与其金融机构一起使用的身份验证。然后，应用程序会对身份验证数据进行加密，以便只有金融机构才能查看这些数据，并将它们从设备中删除，以便没有其他方可以进行访问。此外，CV应用程序还会执行测试，以验证用户设备的整体完整性。

5. 第三方应用程序聚合并加密收集的信息，然后将其发送到第三方的服务器。

6. 第三方接收并验证该请求，并通过安全通道将其重新发送到CV。第三方仅可访问处理该请求所需的数据。特别是，第三方无权访问用户与其金融机构进行身份验证的凭据。第三方可以检查用户设备的违约状态。

7. 简历审查收到的信息，以确保其来自认证第三方，并验证其是合法请求。CV还可以检查用户设备的违约状态。

8. 如果适当，简历通过其维护的安全渠道将请求重新发送给相应的认证金融机构。CV无权访问用户与其金融机构进行验证的验证凭据。

9. 金融机构使用简历应用程序提供的信息对其客户进行验证，并在适当情况下准备提供与用户请求相关的信息。

10. 通知用户请求服务的结果。

结 论

05

上述的API方案目前依赖于由CV开发维护的认证应用程序的存在。这个应用程序是该系统的一个基本部分，因为它允许用户安全地将他们的财务凭证输入到交易流程中。此外，该应用程序还可以确保只有用户的金融机构才有权限浏览这些财务凭证，并验证用户手机的状态。当然，一个独立的安全身份验证应用程序并不是执行这些安全验证活动的唯一手段。

实际上，该方案中使用的解决方案可以是内部应用程序（作为集成库安装在内部），也可以是外部身份验证应用程序(这必然意味着应用程序间的信息互通）。选择哪种解决方案取决于以下要素，如所需的用户体验、解决方案的范围(能够使用API方案的人数)和预期解决方案的实用性。

在这方面，认证应用程序解决方案（如上所述）具有高效的优点，因为单个应用程序可以服务于任何数量的第三方应用程序。此外，单个实体可以处理应用程序的不同版本和更新，这有助于对认证应用程序功能的有序管理。然而，认证应用程序解决方案还要求用户在智能手机上安装一个他们可能发现目的模糊的应用程序，从而降低了他们愿意加入开放金融生态系统的可能性。此外，在用户的智能手机或互联网连接不允许此交换顺畅的使用情况下，在中央验证器应用程序和第三方应用程序之间的切换可能并不实用。

另一方面，应用程序内部的解决方案并不要求用户在其智能手机上安装不同于他们希望使用的应用程序。同样地，由于没有必要在应用程序之间切换，因此在大部分智能手机上，用户体验可能会更简单、更直观。然而，在方案中使用的每个第三方应用程序都需要包括安全应用程序的特性，这将使所有这些应用程序占据更多内存，并可能在一定程度上在API方案中产生不同的用户体验。在这方面，虽然凭证交换的安全性至关重要，但身份验证流的用户体验对于实现任何成功的开放金融生态系统都同等重要。最重要的是，当一些第三方应用程序必须由一个受信任的实体进行验证，以避免可能暴露用户凭据的不安全特性时，就存在一定的风险。

由于应用内部和身份验证应用选项各有优劣，考虑到每个设想的开放金融生态系统，应该对于上述要素进行权衡。

以下为文章部分截图

……

获取完整文章

请后台回复“开放金融”

获取下载链接

END

编辑/王亚勋

审校/李锦璇

【延伸阅读】