目录：

开放银行基础设施

· 平衡业务价值和开发者体验

· 安全、安全、还是安全

API不等于“接口”

· 面向互联网

· 自动化体验

API的潘朵拉魔盒

· API治理全景图

· API的持续演进

API的正确打开姿势

· 面向业务场景设计

· 面向客户持续运营

开放银行的实现离不开对外开放的接口，从目前各家银行的技术实现看，有以下三种常见方式。

（对外接口开放的三种常见方式：H5、SDK和API）

从相对严谨的开放实践角度，H5和SDK都不是真正意义上的开放接口，存在较大的定制化约束，也很难真正在整个行业进行标准化。所以API是希望实现真正开放银行业务的金融机构必须拥抱的对外接口方式。

ProgrammableWeb在API的系列科普文章中用电源插座做了比喻，虽然全球范围插座的模式还是有差异（比如欧洲和美洲标准不同，电压也有110V和220V），但在一个大区域里我们拿着电器是可以各地通用的。插座标准化的好处自然是不言而喻的，背后电从哪里来的复杂实现完全不用消费者费心。当然API比插座还要更加强大，插座只是提供简单的供电，而API提供的是各种能力，这些能力被外部的应用调用和组装之后，就可以演变出各种定制化、个性化的服务。比如我们现在习以为常的根据地理位置提供的各种服务，从附近餐厅推荐到附近的网红景点，其实都是基于地理位置服务（API）的调用和信息叠加。

如何正确规划API仍然是各家银行的挑战。从开放银行出发，API本身就是对外的业务，现在普遍性的将API定位为内部IT系统接口的思路是阻碍API认知的主要障碍之一。希望通过本文和大家一起提升对开放API的理解。

开放银行基础设施

今年1月14日，央行公布了北京市6个拟纳入金融科技创新监管试点的应用，API和大数据、区块链等一起被认为是金融领域技术的前沿应用。这些技术应用的主旋律其实都是围绕着金融服务的开放使能，接下来的数字化货币DECP无疑会更进一步推动这样的数字化开放生态形成。

全球数字化先锋的西班牙对外银行——BBVA，针对Open API，Open Banking 和 Banking-as-a-Service 进行了区分。BBVA认为Open Banking向第三方提供对现有银行客户数据的访问权限，而Banking-as-a-Service向第三方提供对银行功能的访问权限，以便非银行机构可以将银行现有业务范围之外的用户连接到银行服务。两者的基础都离不开Open API，对外开放的API，不论是对外提供数据的访问，还是把银行自身的金融服务变成社会公共平台。

构建这样的开放API平台是一项颇具挑战性的任务，银行长期面向内部业务需求设计系统的惯性，及业务和IT部门的分隔，成为API设计和落地的巨大障碍。笔者有交流的银行决策者对于开放API的支持已经是毫无保留，但横在他们面前的问题是如何规划？谁来负责？ROI怎么算？

在解决开放API平台规划设计这些具体问题之前，树立正确的理念必须先行。我们认为银行组织在不同层面推行API开放至少有以下几点显著收益：

内部API可提高组织的敏捷性，执行效率和有效性。银行面对耗时数十年构建的遗留系统网络，业务变化响应力越来越差。使用内部API，将客户体验和业务流程，与底层技术约束，进行隔离，能很大程度上提高了业务敏捷性。挑战在于确保API封装了真正的业务功能，而不仅仅是新瓶旧酒的老程序包装。

B2B（“合作伙伴”）API优化了银行外部的流程和合作关系。B2B API通常在特定的业务流程和合作关系（例如付款或提供数据）的背景下，与选定的业务合作伙伴，客户和其他利益相关者实现高度定制化的集成。这种集成能力在数字化时代成为了很多合作的先决条件。

外部API通过开放和创新促进市场范围扩展。通过这种类型的API开放，银行可以通过互联网向开发者开放数据、产品目录、业务渠道或其它业务资产。这样的做法毫无疑问可以帮助银行扩大其市场份额，增加销售，产生新的收入来源或促进围绕其业务的开放式创新。

产品API通过连接和扩展生态系统来增加价值。借助API，银行产品可以成为开放商业生态系统的一部分而获得价值。例如，Visa发布的一个产品API，允许发卡行向客户提供“卡控制”功能 —— 设置支出控制、接收警报以及打开和关闭帐户。产品API看起来可能与其它类型的API非常相似，无论产品是一种付款方式，一种服务，还是某种诸如移动钱包之类的数字“实体”。关键区别在于，由于它们可以直接控制产品或服务，并集成另外的产品或服务，因此产品API主要是购买和使用产品的人感兴趣，商业生态伙伴也会感兴趣如何利用产品API形成增值服务。

（图示：典型银行的API架构，综合参考多家领先银行模式。）

全球领先的数字银行对于API的整体规划都是产品模式，但不可忽视的是，API产品化的能力在每家银行都不会是一蹴而就的，内部和外部API的快速落地和规范是能力培养的良好阶梯，而这个过程中有两个核心要素。

平衡业务价值和开发者体验

Deutsche德意志银行的Bank API Program和Barclays巴克莱银行的Open Banking平台都是相对比较成熟的开放银行API平台，获得了全球行业协会的不少赞誉。评判银行开放API优劣的关键点之一就是API设计在业务价值和开发者体验之间的平衡。

很多银行在此方面都经历了惨痛教训，一方面业务要求的API开发者使用过程中效率低，每次都需要在API调用获取的结果之上做大量的重复劳动。比如针对卡的查询，业务总是希望“包罗万象”，把报文字段都传出来。造成的实际结果就是各种分类查询实际上都需要拿到数据再完成自身的逻辑处理，并且经常就某个字段能不能被开放而增加复杂逻辑。

另一方面，开发者本身也是API的设计者，各种为了自己眼下应用实现方便而开口的API应运而生，最后的结果就是形成大量无人问津的API，逼得组织上马API调用率这样的指标。

设计阶段缺乏平衡思考是银行API开放目前的普遍问题，类似英国Open Banking这样的标准化协会组织在此方面有一定的帮助，也是中国银行业目前急需的。但随着开放银行模式的深化落地，银行必然需要根据自身业务特点进行API设计，此时围绕API的思维建设就至关重要。

针对中国银行的现状，我们认为对于有志于快速构建开放API作为基础设施的银行，需要成立专门的API治理团队，兼顾业务和开发者视角，参考全球先行者的经验，形成API设计的指导原则，逐步建立适合于银行自身发展方向的开放价值观！

安全、安全、还是安全

谈开放就不得不关注安全，安全是开放的基本前提，特别是在银行这样的金融服务领域。API普遍存在的问题是大家会不自觉的将安全放一边，或者“外包”给专门安全团队。“内部接口，安全不用讨论了”这样的言语充斥于需求分析阶段。

开放API平台安全意识的转变需要从过去“内向”变成“外向”，传统针对接口的技术安全性扫描只是整个安全策略的冰山一角，如果我们看看英国Open Banking在安全问题上的FAQ，就能够感受到开放API安全的广阔含义：

原文：

“How do I know Open Banking is safe?”

Open Banking has been designed with security at its heart – here’s how:

Bank-level security – Open Banking uses rigorously tested software and security systems. You’ll never be asked to give access to your bank login details or password to anyone other than your own bank or building society.It’s regulated – only apps and websites regulated by the FCA or European equivalent can use Open Banking.You’re in charge – you choose when, and for how long, you give access to your data.Extra protection – your bank or building society will pay your money back if fraudulent payments are made. You’re also protected by data protection laws and the Financial Ombudsman Service.

从客户视角，英国开放银行组织认为安全是核心，具体体现在银行自身构建、行业规范、客户自主等方面，底线是银行要为不安全事件造成的客户损失买单。

这种外向的转变，从客户视角思考，让安全成为了API规划、设计、开发和运营共同的责任，意味着每个环节的都需要执行相关的安全实践，建立相关的安全思考。

我们建议银行在构建开放API的能力时，关注安全内建的思想，把安全的实践植入到工作过程中。这不仅仅意味着开发人员需要遵守良好技术规范，也需要业务人员从客户及商业环境角度去分析安全相关的场景。

API不等于“接口”

国内的先行者，如 浦发银行的API开放平台 和 招商银行的企业开放平台，离真正的开放API平台还有不小的距离，从整体设计上看来还是受制于过去银行内部系统间报文沟通接口的惯性，没有能够真正的从互联网和开发者体验视角出发去转变思维观念。

面向互联网

互联网时代某种意义上已经过去，而互联网技术给当下数字化时代留下了宝贵资产。其中很重要的一项就是应用之间交流沟通的协议 —— HTTP（超文本传输协议）。正是这种协议的存在才能有互联网应用的百花齐放，才能有一秒数十万次的远程交易处理。

毫无疑问开放API也需要通过这样的协议在互联网之上被调用和集成。尽管标准的RESTful架构很早就被定义出来，成为互联网应用应该遵循的统一接口原则，但HTTP的开放性让我们可以用多种方式来设计系统和应用间的接口。

REST全称是表述性状态转移，表述的对象就是资源。任何事物，只要有通过网络被引用的必要，它就是一个资源，比如一个账户，一笔交易，甚至是一次坏账。要让一个资源可以被识别，需要有个唯一标识，在网络中这个唯一标识就是 URI（Uniform Resource Identifier）。URI 既可以看成是资源的地址，也可以看成是资源的名称。这样的做法在互联网普及的今天是常见做法，只是背后的技术标准可能并非为大家所熟悉。对于开放API设计来说，这是必修课，也需要我们银行业务人员理解资源的抽象原理和唯一标识机制。

REST设计的背后是对HTTP协议的充分利用，包含HTTP成熟的性能和安全实现模式，同时也简化了API的调用成本，提升开放者的体验。下图来自于BBVA在卡方面的API设计，我们看到最前面的关键字POST、GET、PATCH和DEL即是HTTP协议里规定的标准“动作”。开发者会知道用POST去创建一个资源（开新卡），用GET去获取资源信息（查询卡信息）。

(BBVA Cards API列表截图，遵循RESTful架构规范，对外提供卡相关的操作。）

完全不遵循RESTful架构的接口设计显然学习成本非常高。比如每家银行同业在接口报文上的设计都是不一样的，对于外部开发者，想要使用这样的接口首先要学习特定银行的业务上下文，想要大规模对外开放是不可能的。

其次，银行内部报文一般是对数据的格式化，以提供特定业务所需要的信息。直接针对这样的报文进行接口设计，很难获得业务上的通用性。作为外部调用方，开发者更关心的是业务行为，而不是业务信息，比如开卡本身是一个业务行为，外部仅需要知道结果，而不是整个开卡的过程信息。REST方式的API设计也能够利用HTTP的标准返回编码传递信息，比如赫赫有名的404，即表示请求的资源不存在（可能是一张被查询的卡并没有签发）。

最后，报文这种数据表格方式的传递信息对于未来的业务变化是一种阻碍，每一个业务字段的变化都可能造成接口的不稳定，都需要使用者进行程序修改。试想在互联网这样成千上万应用集成互联的开放时代，是不可能有集中制度来保证大家整齐划一改变的。

由于篇幅有限，这里不可能进入RESTful API的详细设计方法，但作为每家银行迈向开放的重要一步，银行人都需要学习互联网的基础规范，利用好几十年来积淀出的开放经验。

自动化体验

在这样一个讲究客户体验的时代，毫无疑问API作为产品被商品化的过程中，体验比拼也是至关重要的。试想使用一个API需要首先阅读冗长的说明文档，然后联系相关开发团队给测试环境，最后还要协调上线的联调，这样的API可能没人会认为是真正开放的。

不幸的是上面的体验仍然是大多数银行在谈论API时的现状。不遵守规范和对开放技术的陌生成为构建良好API体验的阻碍，结果是形式化的传统报文被包装成对外接口（名义上的API），使用上仍然是系统之间的点对点集成。

通过近期体验获奖的Deutsche的Bank API Program，我们看到了现代开放技术对于API开放的良好支撑，简单的试用就可以帮助大家理解什么是现代API体验，API的业务价值十分明确的呈现给了开发者，完整的实验、沙盒和生产环境，最重要的是通过自动化的脚本生成调用代码供开发者使用。

（Deutsche银行的AccountInsights API页面截图，明确提供了相关API的业务价值。）

对于开发者来说这样的自动化体验是开放的基础，没有这样的自动化能力，开放API的大规模实践是不可能的。通过过去几年的沉淀，自动化相关的开放技术，包括自动化的说明文档、自动化的调用代码生成、自动化的沙盒环境等，都已经拥有了全球技术社区的广泛支持。

对于中国银行而言，拥抱这些开放技术是必然的，同时改造自身企业的思维及文化去适应开放的商业模式可能是更为挑战，也更为关键的！

API的潘多拉魔盒

作为用户，当我们把电器插入电源插座，启动电器时，可能鲜有人再关注从发电、蓄电、供电到计费的整个复杂设计了，显然这是国家电网单位的责任。只有在电路改造时，大家可能才会感慨原来为了得到一个可用的插座，背后的工作如此繁琐。当然对于专业人士来说，可能已经了然于胸，毕竟是一个标准化相当成熟的行业了。

类比到咱们的API，作为设计者，为了让我们的用户（开发者）可以像插电一样的便捷使用，我们就需要去分析背后的复杂业务逻辑，分解从设计到实施，再到运营和演进的各个环节。构建这样的能力固然是挑战的，但得到的开放平台和使能的新业务模式，就像面对琳琅满目的电器一样，让人充满期待。作为追求开放银行的践行者，会毫不迟疑地打开API的潘多拉魔盒。

API治理全景图

良好体验开放API平台的背后是一套完整的治理体系，随着很多企业——包含文中提到的那些先行银行——在API构建方面的持续积累，我们已经逐步清晰了整个API治理的全景图。

（图示：API治理全景图）

从治理的角度，仅仅考虑最上层的API管理功能是不够的，API连接的服务及支撑服务运行的基础构建是水平面下隐藏的冰山。限于本文的意图，我们不再展开每一项能力（图中实线框）进行讨论。希望利用全景图帮助开放API平台的设计者们更好的全局思考，也根据自己的业务述求逐步明确每一项能力的具体要求。

API的持续演进

在API治理能力分解基础之上，我们需要时刻强调时间这个维度带来的诉求——API必须持续演进！

这种演进能力必须考虑于API设计之初，不同于实体产品，一个真正开放的API发布时，意味着一个资源的诞生，这个资源将有可能被来自于互联网的千百个产品和服务所使用。随之而来的要求是这个资源的唯一标识在后续的变更中应该不变，对于一个接口来说意味着如果要增减任何参数，都需要保证向后兼容。

而内部的业务逻辑发生变化造成系统需要重新发布时，我们通过API提供的服务应该是7×24的，至少应该尽可能缩短无法提供服务的窗口期。这背后所涉及的数据一致性保障，新老服务的路由，以及基础设施协调，都是需要在API设计过程中考虑的。

针对这样的持续演进，一个良好的实践就是从场景视角去梳理相关的要求，比如新服务版本部署的场景，新合作伙伴接入的场景，网络不可用的场景等等。我们永远不可能面面俱到考虑所有细节，保持业务和技术的紧密合作是开放API能够持续演进的核心保障。

API的正确打开姿势

构建开放API的完整体系固然是复杂的，绝不等同于对外暴露一些接口，或置办一套基础设施。一个成功的开放API平台会得到市场的肯定，获得源源不断的需求，所有方也可以通过API消费的货币化获利。开放API实质是银行对外提供的一种商品、一项服务。因此在构建开放API时，API as Product的原则，即把API当作一个产品来看待，能够帮助我们剥丝抽茧，找到正确的打开姿势。借鉴良好的产品研发方法，开放API的构建过程也包含以下几个阶段：

（图示：开放API完整的生命周期，需要兼顾API平台和开发者两个视角。作为平台方，应该特别关注设计和运营两

每个阶段中都会有不同的侧重点，遵循API as Product的原则去采用相关的方法。这样的实践思路，正是构建开放API与构建传统系统接口的显著差异。

在不进入过多技术细节的前提下，我们希望整个API团队（包含业务和技术）能够关注以下两个方面的实践落地，保证整个团队跨专业的协作，真正贯彻开放API作为一个面向客户的产品的核心思想。

面向业务场景设计

在开放API设计阶段，优秀团队强调从真实业务场景出发进行设计。这样设计出的API才是鲜活的，有真实市场需求的，而不会一上架就变成“僵尸”API。平台用户可以使用这些API去快速构建自己的场景应用，或者进行进一步的业务创新。

为了促成业务和技术能够在设计过程中基于场景去协作，设计方法上需要关注两点：

1. 基于业务场景识别高价值的开放触点；
2. 基于业务领域模型定义易于理解的开放资源。

借鉴服务设计领域的成熟实践 —— 服务蓝图，我们可以很好的组织业务和技术同事们完成这样面向场景的设计。

（示例：通过服务蓝图，面向保险业务场景的车企开放API设计，这里的一个开放资源就是车险产品——insurance，针对这个资源识别出两个开放触点，分别是将保险公司的产品添加到车企的车险产品中，和客户需要进行的车险产品查看。）

John Musser（ProgrammableWeb.com创始人）在 2012 年的 O’Reilly 开源项目大会上提出，“a great API on a bad service is lipstick on a pig”，面对糟糕的业务系统，即使设计再良好的API也是徒劳。考虑开放API设计时，如果只考虑对已有系统蒙上一层薄薄的API，而忽略背后系统本身的开放性，那么不论这个API设计得如何精致，在其交付上线后我们可能都会面临这样的窘境。

因此在设计和交付开放API时，需要考虑这个开放API所依托的后端系统是否能够达到能力要求至少应该从两个方面进行评估：

1. 相关业务场景对于开放API在跨功能层面的诉求，如7×24高可用要求，是否能够被后端系统满足；
2. 开放API所依托的后端系统是否具备足够的业务响应力，比如按周的新功能发布能力。

而银行业的现实情况是，在经年累月的业务发展历程中，核心业务逐步形成了对IT系统支持的依赖，这些系统设计之初是面向封闭的，并没有考虑对外开放的诉求。很多这样的系统由于缺乏持续优化而被我们称之为“遗留系统”。在设计和实施开放API时，我们需要直面这样的挑战，把开放API变成一次契机，建立封闭系统的改造机制，逐步实现真正的科技开放。”

面向客户持续运营

通常产品上线后，产品团队就开始针对线上数据和真实用户反馈进行分析，据此对产品进行优化和迭代，也就是我们常说的持续运营。这个实践对于开放API来说也同样重要，不同点在于所需要关注的数据。很多能力强大的工具已经可以帮助我们获得丰富的线上数据，但需要我们事先明确适用的运营指标，依据这些指标筛选出有价值的关键数据，进行分析并决定开放API的演进策略。

谈到线上数据和指标，作为开放API平台方，首先需要考虑的是针对API管理提供的周期性报告和实时的仪表板（Dashboard）：

（图示：API管理平台产品Apigee Edge提供的两种仪表盘）

API管理平台往往会从性能、缓存、设备、地理位置，以及开发者参与度等方面展示API的表现，使用的指标也都是业界常见的。这些指标包括流量、响应时间、请求延迟时间、响应错误、开发者参与度等，其中有些指标还被细化为多个具体分项。比如流量指标部分还包含Total traffic/Traffic success/Traffic errors/Average TPS这四个具体分项，开发者参与度指标则可能被细化为开发者总量、活跃开发者数量、应用活跃度等。

诚然，这些指标在保障开放API的健康度方面很重要，一定程度上突破了传统SLA只关注技术指标的思维，比如纳入开发者作为用户的参与度。但从产品思维出发，这些指标还是局限于API提供方自身，并没有从客户视角出发，以客户为中心。我们需要从开放API的客户——开发者的视角去思考，为他们提供高质量的体验。好的开发者体验可以简单定义为：开发者通过直接高效的途径，去快速应用平台提供的开放API，从而收获期望的业务收益。

聚焦在开发者体验方面，针对开放API的持续运营，我们推荐两个关键指标：

1. TTFHW（Time to first hello world）这个指标是衡量开发者能否高效使用API的一种方式，度量他们需要多长时间才能在自己的产品中使用API。TTFHW是切实从开发者体验角度出发的，毕竟作为开发者，如果连实现一个“hello world”都需要耗费极大的精力和时间，很容易给这个平台打上“使用曲线陡峭”的负面标签。我们可以从开发者不同的使用场景去思考如何降低TTFHW：1、在开发者初次加入平台时，需要考虑整个平台信息上的易理解和易使用，其中具体措施可以包括在API门户上简洁明了的展示平台所能提供的能力及API分类等，同时提供自助高效的“入伙”流程；2、在开发者寻找所需API时，为每个API都提供易于理解的demo和配套文档，并保证相应的沙盒环境可以进行快速试验；3、当开发者选定API进行集成开发时，最好有相应的快速启动（Quickstart）指南以及工具来减少重复的文档和代码工作。
2. TTFPA（Time to first profitable application）这个指标是对开放API平台运营方的一个提醒 ——除了平台自身的收益之外，开放API应该为平台客户带来真正的业务收益。如果说TTFHW是开发者体验的表层度量，那么TTFPA可以称得上是针对开发者体验核心的关注了。这个指标的具体定义会很棘手，因为每个客户对于收益（profitable）的定义是不一样的。作为起步，我们可以定义的泛化一些，比如开发的应用多久达到期望的用户数量，或者相关日活跃用户数（DAU）等。总而言之，这个指标迫使平台方真正站到客户的视角，去关注API的核心价值——开放共赢。

千里之行始于足下

API及API经济在数字化时代正一步一步成为现实，毫无疑问也是开放银行得以实现的基础。构建开放API平台和生态仍然是充满挑战的任务，要求各家银行从组织结构到思维观念的转型。

开放API的落地，将推动银行完成业务和IT的进一步融合，并促进银行走出去，构建自身业务场景洞见和生态资源整合的核心能力。

面对开放银行带来的巨大机遇，我们衷心希望有志于此的各家银行能够抓住机会，把开放API的构建作为整个组织的一项核心数字能力，创造一个专注客户、敏捷迭代的实验和学习环境。

参考资料

• 英国开放银行Open Banking
• 英国开放银行API标准
• 浦发银行的API开放平台
• 招商银行的企业开放平台
• Barclays巴克莱银行Open Banking平台
• BBVA西班牙对外银行开放平台Open Platform
• BBVA西班牙对外银行开放API趋势分析
• Deutsche德意志银行API Program
• Gartner开放银行2019分析
• ProgrammableWeb API简介