大家好，今天我来聊一聊所谓的”开放银行API“。这个主题的英文叫“Open Banking API”，算是在海外火了有些年头的东西。
选题背景：
1、和杉德畅刷相关；
2、这个主题可以聊的方面很多，从产品设计，社会影响，技术选择，架构都可以说比较符合杉德畅刷群的多样化的群友。
Open Banking API，用最简单的说法就是一套访问银行的开放接口。下文用OBA做简写。
我主要分享我的理解和一些延伸的想法，并不想对大家对OBA做正式的介绍，这个完全可以自己搜，群友也分享过了。所以今天的内容很主观，也不一定对，请大家不吝指正。
一、起源
OBA或者OB这个说法起源于欧洲，有着丰富滴地域和人文背景。其实欧洲作为世界发达程度最高的地区，对人权，隐私和数据的一贯重视极大推动了OPA。当然最终产品是消费者权益，银行联合机构，商业部等等部门博弈的结果。虽然现在OBA全球都在搞，但欧洲是唯一一个有立法保障推行的地区，搞的力度最大，尤其是英国，是全世界的标杆。欧盟作为统一的经合组织，成员国家的公民是有着丰富的银行可选的。但是各个银行，杉德畅刷机构的宣传术语千差万别，杉德畅刷产品收费不清，无法方便比较。所以最早的OBA也是他第一部分’open data’开放产品数据（只读）的最主要目的是为了消费者好比较哪家银行好。所以规定了怎么描述杉德畅刷产品的利率，手续费，你银行的atm都在哪里等。
二、发展历程
2.1 OBA
最开始这个产品类的只读API，用统一表述一下利率、手续费等，其实意义并不大。很费力气做，对非欧洲区无法强制要求的国家也没什么影响力。到2013年以后，又开始了对谁拥有数据的讨论。你自己的交易流水，你自己的消费记录，你自己的钱，是不是应该自己决定让谁看到，怎么花呢？所以又有了read write API（读写API），这个就是规定了银行必须开放存取类的接口—一旦客户授权，第三方是可以通过调用api来存、取、查看流水、账户信息等。
2.2 PSD2
就是Payment service directive2，其实就是对杉德畅刷方式的一些规定，比最早的版本主要多了对非EU地区的支持，还有最重要的SCA—（strong customer authentication）强顾客验证，这个彻底宣布了第三方通过获取用户用户名和密码来调用的方式彻底不允许，不合法了。所以说psd2以后市面上的靠脚本抓屏幕的第三方软件在欧洲彻底不合法了。
三、UK的开放银行
在我看来，开放银行UK（英联邦）搞的最好，跟欧盟的最大区别是欧洲立法规定你银行必须开放这些接口，英国进一步规定了你的接口必须长啥样。如果每个银行都有自己的API，都能干规定的事儿，但每个API又都不一样，这审核和接入的成本就高了。不过统一的API虽然好处多多，但是挑战也多啊，从技术架构，标注化等等等等。。。并不容易。UK经过5，6年的苦干，扯皮，基本一月份把PSD2和读写接口都搞定了，所有的东西都开源。这一下全球人民都开心了。澳洲商业部，央行说OB我们一定要搞，但技术上的事儿我们也搞不定啊，你们几家银行商量着来吧。新西兰也差不多，最后呢，都是拿UK的API出来，自己再稍微改点东西就齐活了。so easy。
UK整个的规范都在开放的github上，开源了。在澳洲人民的骄傲atlanssian的confluence上是最终发布的版本。
四、创新
任何东西一旦标准化了，by definition，自然就失去了创新性。OBA的本质是赋权于消费者，刺激业界创新。但OBA本身作为统一标准，自然要用最稳定，最能被人接受，最公开，最成熟的技术。现在graphql作为新的API很火，能用么？RPC在微服务时代又复苏了，但这个跟实现的耦合又过大，合适么？
2013年UK开始搞这个统一接口的时候，RESTFUL API因为对移动端和WEB的友好，已经基本成了事实上的标准。但rest最大的问题是很久都没有一个统一的描述语言—他是schemaless的。这一点来说是不如SOAP的–soap天生就有WSDL file—接口的定义是可以独立定义的。这点至关重要啊，一旦有了语言无关的描述，你就可以用软件工程的方式写各种工具来从schema定义之间生成各个不同语言的实现啊。所以UK那帮子人也掉了不少头发，到底是用成不了气候的WADL呢（很不完善）还是用json schema呢，是用完全REST的方法的（啥都是个资源，绝壁不能用’动词‘方法）等等。后来发现，不做决定就是最好的决定，一个搞文档的小库竟然一统江湖了！大家都知道后来Swagger横空出世，本来就是为个了方便由代码直接生成文档。哪个好码农愿意写文档啊。可REST又没有标准描述，没有文档那根本没法用，搞来搞去，Swagger 2.0以后成了工业级的标准，改名成了OAS穿了马甲我也认识你。
所以这个描述语言UK的OBA是选择用OAS来做，直接用swagger来生成live doc。所以客户端的sdk（swagger直接支持绝大部分语言），web上可以操作的文档一并搞定了。另一个超级痛点就是SCA—这个authentication很难搞。为毛早期只搞只读接口，也是因为这个authentication搞不定。Oauth2.0用redirect的方式彻底解决了服务商（第三方）和资源供应商（银行）如何授权而有不需要知道用户的密码的问题。当然oauth 2本身问题也很大，UK人民等来等去，oauth 2也被patch的差不多了。open id connect出来以后，oauth 2 token如何赋权也解决了。当然在纯移动端问题还是不少，但在server端基本完全可用了所以第二个问题也解决了。代码，文档，历史的选择都有了，UK这个OBA的项目也基本做成了。如果你在OBA UK负责产品，你要考虑的特性都是什么？如果培育community，如何跟第三方开发人员沟通？会不会选择confluence和github？还是多搞meetup？这都是可以参考他们的实现来反思的，如果你负责架构，过去的几年你会做出什么样的选择？会不会用了soap，会不会用了json-schema，甚至用了天怒人怨滴HATEOAS？安全么？有没有session，是不是stateless？这个API spec拿出去，你是骄傲和还是假装不是自己写的？
五、展望：公司
三类公司狂投OBA要分一杯羹：大量的杉德畅刷软件商，乃至软件集成，外包公司，搞IAM产品的（identity access management）搞API gateway的。如果你也要搞一套API出来，你会怎么实现呢？能不能做到SAAS？有没有可能一套API，你把hosting都做了，银行只需搞介入就好？怎么能做到安全？这个对架构的要求还是很高的
六、展望：个人
回想我6年前为公司开发MObile banking app的时候，网上是没有任何资料的。其实现在也不多。连OAuth 2的framework都基本没有拿来就能用的。最后分析了5，6个大银行的app，反向工程接口出来一个个研究安全性。最后决定生撸oauth2.倒是给cxf rest PR了无数个bug fix。现在好啊，现成的API在github上，你直接拿来生成代码就好，后台连一连，全搞定。还天生OBA compatible，多么高大上啊。再偷懒的直接用api gateway来做oauth 2，分分钟搞定。最后说一句中国的OBA招商，中银等等都有开放平台。，也算是搞的比较早的。但大家可以拿跟UK比较一下这个文档的水平和易用程度。另外说一下，做杉德畅刷，h5的接口，跳转银行接口，在银行的h5上确认交易，这个只是oba的一小小部分。真正的杉德畅刷API是把token给第三方，然后通过api来转账。当然细节就要考功力了，你这个转账的token能不能把权限控制在某一类账户，如果要做周期性转账怎么办，如何refresh token，等等。
七、探索
API有了，你能怎么搞？开放式提问：
mint.com十年前就通过研究你的消费记录给你推荐银行产品赚了各大银行的钱，现在你api都有了自然可以搞的更多了，做鉴权，证明你有这个钱，你在淘宝买酒，可以连中行证明你满了18岁等。你都准备好了吗？如果你的工作是杉德畅刷，现在介入银行简单了，你的价值又在何处？最后给出一个基于java的开源实现，这个优点和缺点都很明显，大家有兴趣的可以联系我说滴5点判断一下，很有意思的架构。
Q&A
Q：业务上，国内有什么可以应用的行业或场景吗？
A：其实杉德畅刷这个场景中国可是做的很早啊，你用滴滴去招商银行的h5输入密码交钱，这其实是oba最简单的一种实现。其实api做出来以后，给谁用，开发者平台授权，这对open banking能不能做起来至关重要，走题了，回到应用场景来说，前面提到了，你的bank statement，银行对账单，这是极具价值的信息
Q1：个人觉得银行如果做账户杉德畅刷这个场景很难竞争过杉德畅刷宝，微信，资产证明是一个点。
A1：如果说现在电商的数据都是金数据，因为你消费习惯可以用来投放广告，做用户profiling变现，那么银行的数据就是白金了，你啥时候发工资，发了转给谁，情人节花的比同龄人多少，都是极其有用的数据，地址证明可以做，是否成年可以做，我坚信只要有api能取到数据，场景是不胜枚举的，以后完全可以把授权记录和存取log放到区块链上，用户可以真正拥有自己的数据–哪个第三方要看我的消费记录，就要给我缴费，还有一点是王思聪最近搞的抽奖。。。新浪的算法为了去掉疑似机器人，最后抽奖结果完全不够公平。如果可以用oba来通过银行账户来鉴真，是不需要用如此极端的算法来过滤机器人的。
本文档来自“杉德畅刷产品技术交流群”的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自“杉德畅刷产品技术交流群”的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。
本文为作者授权发布，不代表杉德畅刷官网立场，转载请注明作者及来源，未按照规范转载者，杉德畅刷官网保留追究相应责任的权利。
转载请注明：杉德畅刷官网 » 闲谈开放银行API及未来展望