开放银行（Open Banking）作为银行数字化转型过程中的重要举措，得到了业界越来越多的关注和重视，开放银行通过 API 实现商业银行和外部的数据共享，将金融服务嵌入到用户的生活场景中来满足客户的多样化需求，以场景为核心、围绕客户旅程重塑传统业务模式，挖掘新的业务增长点。KPMG 在系列研究报告中指出，开放银行或许是未来中国银行业发展的必经之路。
开放银行与开发者体验
根据《Open Banking Trends Report Q1 2020》的报告显示，截止2020年Q1 世界前50的银行中72%已经构建了开放平台，78%的开放银行平台为开发者构建了明确的开发者门户网站（Developer Portal），越来越多的银行建立专门的合作渠道，积极探索新的业务场景，把一些不直接竞争的合作伙伴接入到自己的生态系统，据该报告显示其中一家银行通过向第三方开放API，每年新增账户增长72%，交易额增长91%。
和传统的产品形态不同，开放银行提供的是具有特定能力或者银行数据的API，虽然直接使用开放银行API的是生态应用的开发者，但是本质上这些API仍然是产品，也具备产品的特性，比如需要关注产品价值、市场的匹配度、用户体验，也需要考虑 API 的定价、营销等方方面面，而用户体验往往是其中最容易被忽略的维度。在2019年的 State of API 报告中，73%的开发者认为易用性是评估 API 开发生态最重要的因素，API 缺少标准化和文档不够完善是频繁提及的问题。
开发者通过开放银行的 API 构建多样化的场景，作为开放银行的平台提供方，需要加强对开发者体验的重视，把开发者体验和业务场景探索置于同样的优先级。良好的开发者体验不仅有利于建立产品的口碑，也有助于开放银行应用生态的蓬勃发展。
通过参考公开的开放银行协议，借鉴业界在 API 生态建设方面的经验积累，我们认为开放银行的平台提供方需要从以下几个重要的维度来提升开发者体验：
- 自助式的开发过程
- 现代化的开放协议和 API 工具
- 精心设计的开发者套件
- 友好的开发者社区
提供自助式的开发过程让应用开发更流畅
在应用的完整开发过程中，在很多环节都需要向平台方申请资源，比如在开发期间，需要创建具有唯一标识的应用程序（Application Id）；需要申请沙箱（Sandbox）环境的访问权限，通过集成 API 与沙箱环境进行功能验证；在开发完成之后，需要和平台方的产品环境进行集成；在正式部署上线之前，必须要经过平台方的架构评审、合规检查和安全扫描等，才能向应用正式开放产品环境的访问权限。平台方可以提供自助式的工具或者产品功能，让整个开发过程更加流畅。
(图1: 开放银行生态应用开发过程）
在访问申请环节
平台方需要提供方便、易用的开发者门户网站供开发者使用，除了基本的 API Catalog（API 清单）、API 文档之外，还需要自动化资源申请流程，让开发者可以快速获取所需资源。
对于非产品环境的资源申请，需要提供入口供开发者进行资源申请，并自动生成测试账户、API 账户和 API 口令等，无需等待冗长的人工审核流程，开发者可以立刻启动应用的开发工作。
（图2： BBVA开发者注册之后可以立刻创建生态应用，并获取访问沙盒环境的权限）
国内开放银行的平台方在自助式资源申请方面还有不少提升空间，比如某国内银行的开放平台，需要提交身份证号、借记卡号、住所地址、手机号码等信息，经过平台方的资质审核才能获取沙盒的访问权限，虽然一定程度上防范了来自黑客或者不法分子的恶意攻击，但是也限制了开发者快速熟悉 API 的途径，网络攻击防范的核心要从服务器端着手，需要建立威胁识别模型和自动防范体系，替代重量级的开发者审核流程。
(图3：国内某开放银行沙盒申请流程）
在开发测试环节
在开发过程中往往需要创建测试用户、准备测试数据，并在沙盒环境进行应用的功能测试。平台方需要提供自助式的测试数据管理工具，生成多样的、较完整的、具有代表性的用户记录，有助于开发者在开发期间发现和覆盖更多的测试用例、提前发现应用潜在的功能缺陷。
德意志银行的开放平台在测试数据准备方面比较成熟，开发者可以自助式地基于平台内置模版创建测试用户，测试用户的数据也比较全面。用户创建成功之后，开发者还可以模拟测试用户登录、授权应用访问用户在德意志银行的账号信息、交易历史等数据，在沙盒环境下进行端到端的功能验证。
（图4： 德意志银行开放平台内置了标准用户模版供开发者创建应用的测试用户）
（图5：德意志银行开放平台会自动生成多样、完整的测试数据供开发者使用）
在部署上线环节
考虑到法律和合规因素，在应用正式上线之前，需要经过必要的安全或者合规检查，比如生态应用的数据管理是否符合 GDPR 要求，如果涉及到支付相关的功能，还需要考虑 PCI 合规、PSD2 以及反洗钱等政策，在产品正式接入之前，平台方和开放银行的合作伙伴需要签订合约，明确平台进驻要求和双方权责。除了这些商务流程之外，平台还需要采用“测试左移”的方式，提供安全和合规检查清单，方便开发者在正式接入之前进行自检，避免在后期产生额外的返工。BBVA创新实验室（BBVA Labs） 围绕开发者体验开源了不少工具，帮助开发者在开发期间提前识别并解决一些安全和合规方面的问题：
apicheck：借鉴 Unix 系统的设计思路，自动化API测试相关的工具链，可以和BurpSuite、OWASP ZAP 进行集成，模拟渗透测试 ，发现生态应用的服务器配置或者生态应用代码的一些安全缺陷
patton：建立漏洞知识库，帮助开发者发现Ubuntu, Debian and RHEL 8 等操作系统的组件漏洞，提高生态应用运行环境的安全性
采用现代化的开放协议和 API 工具拥抱开发者生态
现代化的开放协议和API工具有助于开发者拥抱成熟的开源生态，避免重复造轮子，帮助开发者提升工作效率。在遇到系统集成相关问题时，也有大量的社区资源可以借鉴，方便应用开发者快速解决问题。
首先在于认证协议（Authentication Protocol）的选择上，目前大部分国外的开放银行的平台方都选择了主流的OAuth 2.0 协议作为用户身份认证协议， 但是在授权模式的选择上有较大的差异，BBVA只支持客户端凭证授权（Client Credential）模式，德意志银行在应用类型的选择上更具多样性，可以针对不同应用形态的特点，选择隐式（Implicit）、授权码（Authroization Code）和客户端凭证（Client Credential）模式，此外对于部分模式还需要考虑是否支持代码交换的证明密钥（PKCE）。
对于不熟悉OAuth协议的生态开发者来说，在认证模式选择方面可能会存在一些挑战，为此德意志银行提供了较为详细的决策树（Decision Tree）辅助开发者决策，帮助开发者选择合适的应用程序类型和授权模式：
（图6: 德意志银行的授权模式决策树帮助开发者选择正确的认证协议）
开发应用时，开发者往往需要构造地址（URL）、请求报文（Body）、请求头（Header ）等进行 API 测试，这些操作较为繁琐，在开发者社区已有比较成熟的解决方案可以帮助开发者简化这些操作 。我们也看到类似 Swagger 的工具在各家开放银行中都被大范围使用，开放银行的平台方使用 OpenAPI 规范描述 API 的定义，开发者下载描述文件之后使用 Swagger 工具打开，可直接查看 API 文档并进行 API 试用，这种交互式的API开发体验可以帮助开发者快速了解不同API的用途，把主要关注点放在快速构建生态应用上。BBVA 和 NBG 还进一步地提供了开箱即用的开放银行 API 集合，开发者可以从官网或者GitHub 下载，导入到本地的 Postman 中即可立即使用。
（图7：德意志银行开放平台可以直接下载JSON格式的）
（图8: 西班牙对外银行提供开箱即用的 Postman API 集合）
国内开放银行在协议的选择上大多还是以定制化的协议为主，在应用的形态上也存在一定的约束，不过目前大部分国内开放银行平台都已经支持了Swagger文件的下载，比如浦发银行的开放平台，对于 API 的用途、请求报文结构、返回报文结构和错误码等都有非常详细的描述：
（图9：浦发银行的开放平台API 的 Swagger 描述）
提供精心设计的开发者套件降低开发者维护成本
服务提供方是否需要提供开发者套件（SDK） 供 API 调用方使用？对于这个问题业界一直有很多争论，引入 SDK 意味着未来需要承担长期的维护成本，当所依赖的组件库升级或者框架升级的时候需要进行同步升级；如果支持多语言的话，这个维护成本会翻倍。
如果你的应用只需要调用开放银行的接口，获取平台金融产品和服务信息查询，对于这种较简单的API调用，我们推荐使用“宽容的读者模式”（Tolerant Reader Pattern ）直接进行API调用，调用时只依赖于所需的数据，对于不需要的数据直接忽略，这种松耦合的设计更利于 API 提供方和 API 消费端的独立演进。
但是对于大部分开放银行的业务场景来说，都涉及到较复杂的、加解密、签名等操作，我们鼓励平台方提供对开发者友好的SDK，封装这些技术细节，应用的开发者无需了解具体加密、解密或者签名算法，直接调用已经封装好的组件即可完成所需业务操作。2020 年 2 月 13 日，中国人民银行发布《商业银行应用接口安全管理规范》，为开放银行提供参考，加速了我国开放银行管理规范的进一步完善。在这份安全管理规范中对于 SDK 的使用场景也有较为详细的描述：
- 资金交易与账户信息查询应用类，此类金融产品和服务与用户个体直接关联，实施高等级安全保护强度，此类商业银行应用程序接口包括但不限于:
- 商业银行通过 SDK，提供资金交易类服务，如支付、转账以及金融产品与服务购买等
- 商业银行通过 SDK，提供用户账户信息查询类服务，如账户余额、交易历史、账户限额、付款时间、金融产品和服务持有情况等;
在实现方式上，我们推荐团队自主维护 SDK的开发，而不是依赖于工具的自动生成。虽然类似 Swagger 这样的工具可以自动生成多编程语言的 SDK，但同时也引入了很多新的问题。这种基于规范（Specification）生成的代码往往太过复杂、可读性较差、诊断调试也不方便。由于开发时间、产品周期等各种约束条件，即使发布了新的版本，开发者也很难在短时间之内把 SDK 升级到最新版，这些可维护性很差的 SDK 会一直留在应用代码中成为遗留的技术债务。
在开发语言的选择上需要保持谨慎，支持的语言种类越多，未来升级维护的成本也越高。在设计 SDK 的时候还要管理好 SDK 的依赖，尽量减少所依赖的外部组件库，这样可以减少开发者在使用过程中的版本冲突问题。此外，如果有新的语言版本或者框架发布，待其稳定之后也要即时升级 SDK 的版本，否则开发者还需要处理语言和框架的兼容性问题。
构建友好的开发者社区持续收集开发者反馈
除了API 文档、API 示例、行业案例和知识库的构建之外，平台方还需要注意从开发者收集针对产品的反馈信息。
Twilio对于开发者社区非常重视，在开发者社区方面有很多值得学习的地方。Twilio是一个专注通讯服务的开放PaaS平台，通过将复杂的底层通信功能打包成 API 并对外开放，从而实现云通信的功能。Twilio的员工经常会组织或参加各种会议、演讲、线下见面会和黑客马拉松等活动，通过与开发者交流技术、分享经验，收集来自产品使用者的直接反馈，这些活动不但有助于在开发者社区建立良好的产品口碑，也可以针对用户的痛点、想法和建议，适时调整产品的优先级和演进路线。
目前各家开放银行对于开发者社区的构建都有所关注，其中BBVA在这方面成熟度相对较高，例如BBVA在开发者官网中提供渠道，方便开发者提出API 功能的需求，反馈API 缺陷、咨询商业合作机会等。除此之外，BBVA也非常同样重视和开发者下线的交互和沟通，在开发者官网会实时发布对外的市场营销活动，吸引开发者参加。
(图10: 西班牙对外银行开放平台收集来自开发者的反馈)
(图11： 西班牙对外银行开放平台对外的营销活动）
相对来说国内的开放银行的开发者社区还处于起步阶段，开发者官网的信息主要还是围绕信息推送为主，需要提供反馈入口，从开发者收集关于API、文档等相关的反馈信息，促进平台逐步发展。此外还需要注重和开发者的线下沟通渠道，可通过官网、微信群或者钉钉等即时发布开放银行相关的动态、营销活动或技术洞见，吸引开发者加入到这些活动中。
企业走向数字化，就是一个从封闭走向开放的过程，通过充分联接挖掘数据的价值，形成新的商业模式，而 API 经济是企业数字化转型的关键。企业需要通过 API 连接更大体量、更多类型的用户，探索更丰富多样的商业场景，实现盈利的持续增长 。友好的开发者体验是支撑生态发展壮大的基础，开放银行作为 API 经济在金融领域的载体，需要把提升开发者体验作为重要的战略举措之一，吸引更多的合作伙伴参与到商业模式和业务场景的探索中来。
参考：
西班牙对外银行, BBVA One Platform: https://bbvaopenplatform.com/
德意志银行 API Program：https://developer.db.com/
希腊国家银行 NBG Technology Hub：https://developer.nbg.gr/
浦发银行API开放平台：https://open.spdb.com.cn/develop/#/index
Mastering Open Banking: How the ‘Masters in openness’ create value：https://www.linkedin.com/pulse/mastering-open-banking-how-masters-openness-create-value-art-stevens/
企业IT驱动业务转型，将重新定义API经济：https://mp.weixin.qq.com/s/qUV5Z-mZJVdLGu9Mbu7fQA
高盛等巨头们的“疯狂”是为开启API经济时代新商业模式: https://mp.weixin.qq.com/s/Po_R3sX67xLp7gOxQqBJow
开放银行发展研究报告：http://pdf.dfcfw.com/pdf/H3_AP202001141374061095_1.pdf
文/ThoughtWorks 杨政权
更多精彩洞见，请关注微信公众号：ThoughtWorks洞见
