神刀安全网

协作翻译 | 银行业的开放 API 标注

声明:我是开放银行工作组( Open Banking Working Group (OBWG) )的成员并且受邀参加起草这份OBWG报告。但是,这里发表的观点仅代表我个人意见。

这份昨天发布的OBWG报告用了一个 误导性的标题<开放银行标准( The Open Banking Standard )>。我们还有很长的一段路要走,但是这份报告确实是这条路上很有意义的一步。发布这份报告的目的,一个是为 定义一个能被广泛采纳的开放银行API标准而铺路, 另一个是提出一些基础性 的提议, 引发对它们 优缺点的讨论, 以达到抛砖引玉的目的。

OBWG的工作基于看重银行业API和开放数据的潜在效益的芬格尔顿报告( Fingleton report ),以及英国财政部关于银行业的数据共享和开放数据的公众咨询( public consultation )。

OBWG的组建为达成以下三个核心目标:

  • 发布一个致力于英国银行业的开放API标准设计的框架, 侧重于个人和企业现有账户;

  • 评估开放数据以何种程度发展可以使客户,企业和社会收益;

  • 在2015年年底发布一篇建议性论文, 概述 开放API标准按照 时间表和路线图 来进行设计,发布和管理的实施方案。

重要的是,开始的时候 是从一个比PSD2范围更广的项目中分出来的。然而,我有信心预测,履行PSD2所需功能的要求将形成开放银行业API标准的一部分,如果英国实现PSD2,通过强制遵守开放银行业API标准, 我不会感到惊讶。

其中的一个关键挑战是,想出这样一个标准是要找出如何向第三方开放银行业的API,同时还要确保消费者不被欺诈,且银行也不能不合理地承担第三方的损失。目前,银行控制着技术渠道,他们的客户使用电子账户来访问。在线银行是银行的自己的网站;移动银行是银行自己的app。任何损失的责任在于银行(如果事实证明他们的安全不足)或者客户(如果他们未能采取必要的安全预防措施)。开放访问第三方银行API会让这一切复杂化,银行的谨慎也是可以理解的。

在报告中提出的建议包含许多条款(包括一个基于 OAuth 的验证和验证模型,审查及第三方许可),这代表银行对完全开放,甚至允许业余程序员创建 app 连接到银行 API 做出了让步,过分严苛的制度需要或消耗,对于金融创新和创业来说来太繁复了。这方面,我特别看好的是,API功能可以被自动许可,通过安全标准,第三方能通过对应级别的审核,获取对应级别的访问。举例来说,创业者希望申请个人金融管理解决方案,它需要“只读”访问账户,减少了繁重的工作,让公司指导客户支付。

我很希望看到大家对这份报告的反馈,最后,我建立了一份讨论该报告和下一步开发的邮件列表。如果你有兴趣参与的话,请 联系我

总地来说,我相信如果我们能加快制订开放银行API标准的进程,英国金融技术部门将受益巨大,而且我相信英国有机会成为这个方向上的领导者,就像英国的信息安全标准BS7799被采纳为ISO27001一样。

不论是银行还是金融的 革新者 都很有可能非常满意这份报告的提议。假如果真如此,我认为我们还是完成了一项很棒的工作。我个人认为这是很有意义的一个进步,而且我希望继续留下参与下阶段的实现任务来推进这项理念。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 协作翻译 | 银行业的开放 API 标注

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址