開放銀行

在金融服務中，開放銀行允許通過使用應用程式介面（API）在銀行和第三方服務提供商之間共享金融數據。傳統上，銀行將客戶金融數據保存在自己的封閉系統中。開放銀行允許客戶安全且電子化地與其他銀行或其他授權金融機構（如支付提供商、貸款機構和保險公司）共享其金融信息。

支持者認為開放銀行為帳戶持有人提供了更大的透明度和數據控制權，並可能允許提供新的金融服務。支持者還表示，開放銀行旨在促進銀行和金融領域的競爭、創新和客戶賦權。 反對者則認為開放銀行可能帶來更大的安全風險和對消費者的剝削。

首個開放銀行法規由歐盟於2015年引入，此後許多其他國家和地區也引入了與開放銀行相關的金融監管。

歷史

這一概念最早於2003年作為開放創新運動的一部分被探索，該運動由亨利·切斯布魯（Henry Chesbrough）推動。 2000年代初期網上銀行的出現和線上技術的發展引起了人們對數據訪問的興趣，技術公司首次嘗試進行賬戶整合。

在2010年代，開放銀行也與數據所有權態度的轉變相關，這體現在GDPR等法規和開放數據運動中。 通過開放銀行，銀行轉變為金融服務平台，技術上通過銀行即服務概念實現。

開放銀行的第一個真正監管舉措出現在2015年，當時歐洲議會通過了一項修訂後的支付服務指令，稱為PSD2。 新規則旨在通過開放銀行促進創新線上和移動支付的發展和使用。 這引入了一系列新服務、定義和市場參與者的義務。

金融科技公司對此表示歡迎，但銀行通常因技術和安全原因以及擔心新競爭而不願共享數據。在2015年至2021年間，許多國家和地區頒布了法律和法規，強制傳統銀行提供API訪問客戶數據。

風險與批評

隨著開放銀行，銀行向第三方金融科技公司開放其API，這帶來了安全風險。黑客可能針對第三方應用程式，員工可能被賦予過多的訪問權限。惡意行為者可能通過釣魚詐騙欺騙銀行客戶和第三方公司。

開放銀行也存在隱私問題。 存在基於公開可用的金融數據分析而採取激進市場做法或向客戶提供更昂貴產品的風險。

對消費者而言，開放銀行帶來「數碼和金融排斥」的風險。 英國研究機構金融包容中心的Mick McAteer表示，只有精通技術的人才能從開放銀行中受益，這將導致低收入人群金融排斥程度加深。 他說消費者可能被剝削，無論是通過新型即日貸款或濫用人們在網上透露的數據和個人信息。

使用與監管

大中華地區

香港

香港金融管理局推出了「戶口互聯」（IADS）計劃，該計劃在銀行業界的支持下實施。此計劃建立了銀行間帳戶數據共享的守則和標準，讓客戶可按意願，將其在參與銀行（數據提供銀行）的帳戶數據安全而高效地分享到其選定的其他參與銀行（數據接收銀行）。帳戶數據共享有助促進銀行業務數碼化，加強銀行風險管理，並提升客戶體驗。

客戶必須明確授權IADS參與銀行才能分享其帳戶數據。共享的數據包括個人、公司和中小企客戶之存款帳戶數據，如帳戶存在與否、帳戶狀態、結餘和交易記錄。

客戶授權流程通常包括： 1. 客戶在「數據接收銀行」的平台（例如網上銀行）啟動授權程序。 2. 上述平台將客戶轉到所選定的「數據提供銀行」的網上銀行。 3. 客戶登入「數據提供銀行」的網上銀行，審閱並確認授權內容。 4. 若客戶希望授權多家「數據提供銀行」，則需為所選的每家「數據提供銀行」重複上述三個步驟。

客戶可以在「數據提供銀行」的網上銀行隨時查閱當前授權情況，並可隨時按需要撤銷授權。

IADS的應用場景包括信貸申請（帳戶交易數據能幫助「數據接收銀行」更了解客戶的財務狀況，從而簡化並加快信貸申請流程）及帳戶資訊綜覽（整合和分析客戶在不同銀行的帳戶數據後，「數據接收銀行」可以為客戶提供度身定制的服務，從而提升客戶體驗）。

台灣

台灣金管會於2019年6月拍板定案，以「不修法」、「不強制」的模式，由財金資訊股份有限公司主導銀行與第三方業者合作推動開放銀行，並將進程分成三大階段：

• 第一階段：「公開資料查詢」，第三方業者（TSP）可透過API串接各銀行的商品資訊，如利率、匯率、ATM位置、分行資訊、產品資訊等。此階段已於2019年10月16日正式上線，截至2023年12月底，共計有27家銀行與TSP參與，平均每月交易筆數超過100萬筆。
• 第二階段：「客戶資料查詢」，銀行在經過客戶同意下，由TSP業者提供帳戶整合服務，包含銀行帳戶、信用卡、消費者個人資料。此階段已於2020年11月27日開始進行測試，截至2023年3月底，共計有17家銀行和集保與遠傳合作，客戶可在集保APP中一次查詢自己在各銀行帳戶有多少錢，平均每月交易筆數超過55萬筆。
• 第三階段：「交易面資訊」，銀行在經過客戶同意之下，由TSP業者做好帳戶整合後，可透過APP直接連結帳戶扣款及做消費支付，以及調整帳戶間的資金，包括貸款清償、扣帳授權等。此階段已於2024年1月16日正式上路，相關開放項目包括「存款」、「信用卡」、「貸款」、「支付」及「手機門號轉帳」等5種業務種類，共計35個項目。

開放銀行第三階段開放後，民眾可以透過TSP業者在一個APP整合畫面中，一次查到自己多家銀行、多筆定存並做授權交易，例如轉帳或扣款。這樣可以減少民眾一一查詢各家銀行網站的時間、減少需要下載的銀行網銀或APP數量，更有利於帳戶整合和金融交易，節省時間、提高效率。

中國大陸

2015年前，中國開放銀行主要體現為「銀企直聯」模式。銀企直聯是開放銀行的前身，以大型集團型企業ERP建設逐步完善為歷史背景。銀企直聯以非標準API、專線直連的形式連接大型集團客戶的EPR系統和銀行綜合業務系統。該模式下採取項目式API定制的模式，耗時長，連接成本高不下。該模式的主要價值是為大型集團對接業務流、財務流、資金流，為大型集團財務人員提供簡化流程的價值。就銀行方面言，銀企直聯是延展性相對有限的業務，以完善現有大型集團客戶用戶體驗為主，本身並不以獲取新客戶為目的，為銀行帶來的收益也相對有限。

2015—2020年，中國開放銀行主要體現為「Open API」模式。以標準化接口集市的出現為標誌，開放銀行進入「Open API」時代。該模式下雖然已出現標準API、SDK、小程序、H5集市，但實際很多情況下對接過程仍需定制開發。該模式下服務對象從大型集團客戶拓展至B2B2B模式下的產業互聯網平台/軟件提供商與B2B2C模式下的消費互聯網平台，有效拓展了服務客戶範圍。「Open API」模式在輸出標準金融產品與服務的同時，結合場景方特點，探索輸出行業或場景解決方案。得益於接口標準化，「Open API」模式下開放銀行的成本（尤其是與企業和場景方對接的成本）將顯著低於銀企直聯。「Open API」階段的開放銀行基於B2B2B與B2B2C模式將金融產品嵌入企業ERP、SaaS平台或消費互聯網平台，實現批量獲客，將終端服務客群從大型集團客戶延伸至小微企業和C端的長尾客戶，同時推出行業或場景定制解決方案，由此顯著提升了銀行的服務廣度與深度，為銀行帶來新的客群和收入貢獻。國內開放銀行先行者在該階段紛紛推出標準API平台，例如浦發銀行於2018年7月推出API BANK，建設銀行的開放銀行管理平台於同年8月正式上線，眾邦銀行於同年10月推出「眾邦銀行開放平台」等，目前已成為銀行自有渠道以外獲取新客戶的重要途徑之一。

2020年之後，中國開放銀行進入「Open API+」新階段。「Open API+」開放銀行以PaaS層開放為標誌，輸出解耦後的原子化產品。同時，在輸出自有金融產品與服務的基礎上，輸出更豐富的來自保險公司、資管公司、租賃公司甚至銀行同業的金融產品與服務，並拓寬至政務服務 (ToG)、中小銀行賦能 (ToF) 等場景。在「Open API+」階段，開放銀行將實現真正的接口標準化與業務規模化。由此，開放銀行將具備金融科技公司級能力，實現多維產品、技術、數據全輸出。為了輸出解耦後的原子化產品，「Open API+」開放銀行需要銀行內部系統的重構，打造企業級中台，沉澱業務能力、數據能力與技術能力。此外，基於不同場景生態夥伴以及銀行內部的海量數據打通與沉澱，在「Open API+」階段，領先銀行將數據資產化，最終向生態合作夥伴和中小銀行反哺輸出技術能力和數據洞察。「Open API+」階段的開放銀行將成為更加可持續的商業模式：一方面得益於接口的高度標準化與便捷組裝化，連接與輸出的單位成本顯著降低；另一方面得益於多層次產品體系的構建和多類型生態夥伴的拓展，開放銀行服務鏈條延長，收益顯著上升，最終實現開放銀行的規模化體量和商業價值。以平安銀行為例，數字賬戶體系是平安銀行面向「Open API+」階段進行的重要嘗試。數字賬戶體系基於數字證，打通用戶在各第三方場景的數據，沉澱單家場景方金融科技公司不具備的數據洞察，在確保客戶授權和合規安全的前提下，實現精準營銷與數據反哺。

非洲

尼日利亞的開放銀行由開放銀行尼日利亞（Open Banking Nigeria）啟動，作為為尼日利亞金融服務制定非黨派、非金融API標準的倡議。該組織於2017年6月由一組銀行家和金融科技專家組成，他們共同提議採用該國的通用API標準。 隨著尼日利亞中央銀行於2021年發布開放銀行法規，尼日利亞的開放銀行後來發展成為一項受監管支持的倡議，後續還頒布了尼日利亞開放銀行運營指南。

大洋洲

澳洲的開放銀行項目於2019年7月1日啟動，作為澳洲財政部和澳洲競爭與消費者委員會消費者數據權利（CDR）項目的一部分。 CDR立法於2019年8月由澳洲議會通過。

2023年5月，監督紐西蘭支付系統的Payments NZ表示，主要銀行將在2024年準備好實施開放銀行。

歐盟

2015年10月，歐洲議會通過了一項修訂後的支付服務指令，稱為PSD2。 新規則旨在通過開放銀行促進創新線上和移動支付的發展和使用。 它引入了一系列新服務、定義和市場參與者的義務。

在PSD2條款生效（2019年9月13日）兩年多後，歐盟委員會宣布啟動該指令的審查程序。 2021年10月18日，歐盟委員會向歐洲銀行管理局（EBA）提交了一份諮詢請求。 EBA於2022年6月23日作出回應。 計劃在2022年第四季度對該指令進行修訂。

SEPA（單一歐元支付區）API訪問計劃倡議由歐洲零售支付委員會（ERPB，歐洲中央銀行的戰略諮詢機構）啟動。 該倡議在兩份報告中描述，第一份於2019年5月31日發布， 第二份於2021年6月4日發布。 關於由歐洲支付委員會進一步推進該倡議和實施SEPA API訪問計劃的資訊也是公開的。

擬議的計劃定義了參與實體之間合作的原則，並定義了基於API使用、計費系統和支付系統實施選定服務的標準方法。該計劃工作的起點是歐洲信貸機構提供的PSD2服務，這些服務對第三方仍將是免費的。其他服務——稱為增值服務、高級服務或擴展服務——可由信貸機構根據計劃中採用的規則進行貨幣化。這些規則和計劃的一般假設將與歐盟委員會相關總司進行討論。

2020年10月26日，柏林集團成立了一個名為「柏林集團開放金融API框架」的新工作組，取代了先前負責創建NextGenPSD2標準的工作組。 新工作組的工作重點是標準化信貸機構可能基於雙邊協議或潛在新支付計劃向合格第三方提供的增值服務。

標準化倡議包括：

• NextGenPSD2 – 由柏林集團運營的泛歐洲標準化倡議。
• STET標準 – 由法國清算所（STET）開發；作為融合項目的一部分，該標準在形式上盡可能接近柏林集團的NextGenPSD2標準。
• 斯洛伐克銀行API – 完全由斯洛伐克銀行協會與斯洛伐克國家銀行合作運行的標準化項目，以文檔形式提供。
• PolishAPI – PolishAPI標準為基於支付賬戶訪問的第三方服務提供定義了接口，即經修訂的內部市場支付服務指令（PSD2）引入的服務。參與者包括波蘭銀行協會、聯營商業和合作銀行以及第三方提供商。