在早期台灣建設金融科技的日子中，獲取銀行數據是一個複雜的過程，通常依賴於個人關係。大多數商業銀行並不提供面向開發者的API，沒有公共沙箱，沒有結構化的上線流程，也沒有在機構間分享數據的標準。若想要開發需要帳戶資訊或交易歷史的應用，一些公司會撰寫腳本自動登錄到網上銀行平台並擷取用戶數據；這種方法可行，但卻非常脆弱，還引發了嚴重的安全和合規問題。其他公司則依賴於像Mono、Okra和Stitch等API聚合器，這些平台提供了一個更完善的層次來獲取銀行數據，幫助簡化了整合，但這也通常使用了相同的非正規方法。

沒有統一的行業標準來請求、格式化、安全保護或取得數據同意。金融科技企業必須維護多個與銀行的一次性整合，每一個都有其限制，這造成了大量的重複工作，對新的進入者形成了高准入門檻，且在許多情況下，使用者體驗也變得脆弱。這種情況即將改變。

隨著台灣的開放銀行推行，將轉向一個更結構化、更透明和有法律依據的系統。與中央銀行合作，開放銀行台灣已經建立了定義如何分享金融數據的框架，包括API標準和使用如金融級API（FAPI）等安全協議的治理模式，並要求用戶同意和可審計性。

對於正在成長階段的金融科技公司的工程及產品領導者來說，這全面改變了與銀行整合及獲取客戶金融數據的方法。這減少了猜測工作，開啟了新的產品可能性，並使得負責任地擴展變得更容易。

本文說明了當台灣的銀行業與金融科技產業採用開放銀行時，API整合會有哪些不同，以及金融科技團隊可以如何為未來做好準備。

金融科技在台灣如何當前處理與銀行的API整合？

最常見的方法分為三種：

屏幕爬取與憑證獲取

使用此方法，使用者把他們的網路銀行憑證輸入至第三方應用，然後後端腳本模擬登錄，從他們的儀表板中擷取數據並返回給金融科技公司。這種方法深具安全隱患。如果銀行改變其前端，你就必須重新設計整個數據管道。

直接的銀行合作夥伴關係

成熟的金融科技或者那些擁有強大連結的公司能與特定銀行形成直接整合。然而，這些合作夥伴發展受到限制，技術質量不一，難以擴展。每家銀行擁有不同的身份驗證方法、數據結構和SLA。

API聚合器

像Mono、Okra、Stitch和OnePipe等平台進入，以縮短金融科技與傳統銀行間的距離。它們提供統一的API，簡化了整合，為工程團隊節省了構建及維護多個銀行連接的痛苦。但在其背後，尤其是在初期，這些聚合器常常依賴於屏幕爬取、反向工程及創意解決方案。最終，一些公司與銀行達成了直接合作，但該模式長期在一個監管模糊空間中運作。

金融科技目前能獲取什麼樣的金融數據和服務？

儘管基礎設施不完善，台灣的金融科技已能獲取多樣的金融數據和服務。

目前常見的是：

  • 基本帳戶資訊，諸如帳戶名稱、號碼及當前餘額，通常用於開戶、欺詐預防和設定交易限額。
  • 交易歷史，包括時間戳、交易描述、商戶代碼、信用/借記標誌以及每次交易時的可用餘額，這些數據有助於信用評分、金融分析及預算功能。
  • 身份驗證數據點，如銀行驗證號（BVN）、國家身份號（NIN）、出生日期、電子郵件和電話號碼。這些對於客戶身份驗證（KYC）和預防欺詐很重要。
  • 銀行對帳單生成，通常以原始PDF或結構化JSON形式提供，貸款和信貸平台可將其用於支付能力檢查和風險模型。
  • 支付啟動。通常有限制和條件，但在某些情況下可通過NIP或與PSP或銀行的合作提供。此能力使得金融科技能啟動轉账、扣款及電子錢包充值。

現有Fintech API整合有哪些限制？

即便金融科技在台灣的金融生態中已取得驚人進展，當前獲取銀行數據的方式仍面臨嚴重的挑戰，影響了產品的可靠性、用戶信任運營成本及法律地位。

壓力點解析：

安全問題

廣泛使用憑證獲取和屏幕爬取是一場即將到來的災難。當金融科技要求用戶交出銀行登錄詳細信息以擷取數據，它們從根本上破壞了核心的網絡安全原則。這種做法開啟了欺詐、帳戶接管和資料洩漏的大門。它也把金融科技公司置於一個不穩定的法律地位，尤其是在台灣的數據保護法律如NDPR（台灣國家數據保護法）演變的情況下。

API標準化缺失

每個銀行都有其自己的技術語言。這意味著每一個整合都成為了一個定制化的項目，工程團隊必須花費無數小時去解碼多樣的API回應、映射不同的JSON結構和統一不一致的數據格式。沒有通用的結構或標準，擴展整合變成一個噩夢。

高整合和維護成本

由於這些連接脆弱而容易中斷，金融科技必須不斷監控和修復整合。這意味著工程資源不僅要用於創建新功能，還要用於修補現有功能的漏洞。

有限且不可預測的用戶數據訪問

銀行控制了金融科技能訪問哪些數據，通常是非常選擇性的窗口，可能會得到部分交易歷史、過時的餘額或無法訪問某些帳戶類型。實時更新是稀有而非常態。

客戶體驗的碎片化和不一致性

由於金融科技從多個來源提取數據，每個來源具有不同的格式和更新時間表，最終用戶經常看到相互矛盾的信息。想像一個應用顯示不同銀行的不同帳戶餘額，或缺少重要的交易細節，如商戶名稱或時間戳。這種不一致性會讓用戶感到沮喪，導致混亂並損害品牌的信譽。

監管模糊和合規風險

沒有明確的、可執行的數據共享和同意標準，金融科技正在四處瀏覽一個灰色區域。即使是無意的，也有真正的風險違反台灣央行的規定，NDPR，或其他數據隱私框架。

開放銀行的採用會如何改變Fintech與銀行的API整合？

開放銀行有一個直截了當卻雄心勃勃的目標：將凌亂、脆弱且經常風險的數據獲取方法替換為一個標準化、可靠且受監管的框架，造福所有人。

更豐富、標準化的數據訪問

開放銀行API將提供在銀行間數據一致性。這意味著無論從國泰、兆豐或國泰銀行提取交易歷史，數據字段將是統一的、結構化且可預測的。這種標準化大大降低了整合的複雜性，使金融科技團隊能更專注於數據利用而非清理。

由客戶控制的受監管同意框架

當前系統最大失敗之一即是如何處理同意（如果有處理的話）。開放銀行引入法定、標準化的同意機制，這需要用戶顯示授權才能分享數據。這種同意是細化的、限時的和可撤銷的。對於金融科技而言，這不僅符合台灣的數據保護法（DPL）或全球標準如GDPR；更在於建立基於尊重和透明的長期顧客關係。

為現代金融科技需求制定的強大安全協議

開放銀行基於金融級API（FAPI）標準與OAuth2授權流程的精進安全協議之上。代替密碼或OTP，金融科技將使用安全令牌授予有限、可撤銷的數據訪問。

具有服務級別保證的、更加可靠且可維護的整合

金融機構不再能把其API當作副業或「實驗性」介面。開放銀行要求金融機構維持生產級API，並包含覆蓋了正常運行時間、延遲和事件響應的具體服務級別協議。

新產品和商業模式機會

開放銀行最吸引人之處在於其在整合問題解決之外的解鎖。 可信賴的信用評分模型能更全面地引入及實時金融行為。個人理財管理應用可以更有信心地自動設定存款目標或還款。中小型企業貸款者將獲得現金流和支付周期的詳細視圖，啟動針對性的貸款產品。

此外，開放銀行使得新興商業模式如帳戶資訊服務（AIS）和支付啟動服務（PIS）成為可能，這可能會顛覆台灣支付及金融建議的提供方式。總之，開放銀行為新一代金融科技產品鋪平了道路，更快構建，更可靠運行，且為客戶提供更豐富的價值。

結論

儘管處於一個不完善的整合環境，金融科技已建構了令人印象深刻的解決方案，它們證明了即使在挑戰中，創新也可蓬勃發展。但想像當他們採用開放銀行且能不受當前挑戰地進行創新時，會有哪些可能性。 開放銀行不僅會解決當今的整合頭痛，還會創建新金融產品的基礎，讓金融科技更容易進一步擴展其服務。