大家好，今天我來聊一聊所謂的”開放銀行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本身作為統一標準，自然要用最穩定，最能被人接受，最公開，最成熟的技術?，F在graphql作為新的API很火，能用么？RPC在微服務時代又復蘇了，但這個跟實現的耦合又過大，合適么？

　　2013年UK開始搞這個統一接口的時候，RESTFUL API因為對移動端和WEB的友好，已經基本成了事實上的標準。但rest最大的問題是很久都沒有一個統一的描述語言—他是schemaless的。這一點來說是不如SOAP的–soap天生就有WSDL file—接口的定義是可以獨立定義的。這點至關重要啊，一旦有了語言無關的描述，你就可以用軟件工程的方式寫各種工具來從schema定義之間生成各個不同語言的實現啊。所以UK那幫子人也掉了不少頭發，到底是用成不了氣候的WADL呢（很不完善）還是用json schema呢，是用完全REST的方法的（啥都是個資源，絕壁不能用’動詞‘方法）等等。后來發現，不做決定就是最好的決定，一個搞文檔的小庫竟然一統江湖了！大家都知道后來Swagger橫空出世，本來就是為個了方便由代碼直接生成文檔。哪個好碼農愿意寫文檔啊?？蒖EST又沒有標準描述，沒有文檔那根本沒法用，搞來搞去，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?，F在好啊，現成的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來通過銀行賬戶來鑒真，是不需要用如此極端的算法來過濾機器人的。

責任編輯：陳愛