隨著金融科技在台灣發展，開放性銀行制度爭議逐漸浮上檯面。這種過去須依靠個人關係才能取得的銀行數據，如今透過進階的API技術，讓金融科技公司能更加利便地整合各種金融機構的數據。回顧早期的發展，許多商業銀行並未提供開發者友善的API，缺乏公開的沙盒環境與結構化的上線流程。而金融科技公司若需獲取帳戶信息或交易歷史，更多時候是以不規範的方式操作，例如寫程式碼自動登入網路銀行後抓取用戶數據。然而這些方式不僅脆弱，還帶來了嚴重的安全與合規風險。像Mono、Okra以及Stitch等第三方平台，則提供了一種更精緻的數據存取方式，協助金融科技公司避開直接與每一間銀行自行整合的困難。儘管如此，這些平台也多半以非正式的取巧方式運作。

隨著台灣開放銀行的推進，將帶來更具結構性的透明體系。開放銀行台灣在中央銀行的指引下，建立了明確的框架，定義金融數據分享的模式，包括API標準、使用安全協議如FAPI（金融級API），以及標準化的用戶同意與稽核模型。對於成長中的金融科技公司來說，這改變了他們整合銀行的方式，並減少猜測工作，釋放新的產品可能性，讓擴展變得更加容易。本文將解釋台灣銀行業與金融科技業引進開放銀行後，API整合將有哪些不同，以及如何準備迎接即將到來的挑戰。

金融科技公司目前如何處理與銀行間的API整合問題？

資料畫面抓取與憑證搜集

這種做法是用戶將網路銀行的帳號密碼輸入至第三方程式，然後後端程式碼模擬登入，抓取儀表板上的數據再回傳給金融科技方。這種方式極不安全，如果銀行改變前台，你需要重新設計整個數據流程。

直接的銀行合作

若某些金融科技公司與特定銀行有合作，就能有直接整合的途徑。然而這些合作的技術質量不一，難以擴展。每間銀行採用不同的認證方式、數據結構以及正常運行的服務級別協議。

API 資料集中平台

像Mono、Okra、Stitch、OnePipe這類平台，試圖彌合金融科技公司與傳統銀行的斷層。他們提供統一的API，簡化整合過程。然而在此之前，許多這類聚合平台倚賴技術上不那麼規範的方式，如數據畫面抓取、反向工程等。

金融科技公司目前可獲取哪些金融數據與服務？

即便因基礎設施不統一而分散，台灣的金融科技公司已經能掌握範圍很廣的金融數據。

可接觸的範圍包括：

  • 基本帳戶信息：如帳戶名稱、號碼及現有餘額，用於新用戶上線、詐欺預防及設定交易限制。
  • 交易歷史：包括時間戳、交易描述、商家代碼、借記與信用標誌及當時可動用餘額。
  • 身份驗證數據：如銀行核准號碼、護照號碼、出生日期、電子郵件及手機號碼。
  • 銀行賬戶生成：通常以PDF或JSON格式提供，供授信公司風險評估。
  • 支付起始有限制但仍可用：如借助尼日利亞銀行機構或被授權的支付平台合作。

金融科技API整合的局限性是什麼？

儘管金融科技在台灣的金融生態系統中取得了顯著進展，但它們在銀行數據存取方式上仍有嚴重挑戰。這影響了產品的可靠性、用戶信任、運營成本及法律地位。

主要痛點包括：

安全問題

憑證搜集中蛤唬影是即將到來的災難。金融科技公司當要求用戶提供銀行登錄詳情以窺取數據時，會破壞核心網路安全原則，且對詐欺、帳戶篡改及數據洩露開放了便捷之門。這也把金融科技公司放在了法律的危險位置上。

API標準缺失

每家銀行使用自己不同的技術語言，也意味著每次集成都變成了專案，工程師們花無數時間解析變異的API回應、調控不同的JSON結構並標準化不一致的數據格式。不具備普遍檔案或標準化方法的情況下，進行擴展成為噩夢。此處沒有結束的版本問題，但同時也是工程上的一場災難。

高昂整合與維護成本

由於連結非常脆弱且容易失效，金融科技系必須持續監視及修補整合問題，這表示必須投入大量工程時數並留給補丁既有功能。

用戶數據存取受限且不可預期

銀行對金融科技的數據存取多加控管，通常範圍狹隘，例如只有部分交易歷史、舊賬戶餘額或某些帳戶類型沒有數據存取權。

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

因金融科技從多個來源提取的數據，各種格式與更新時間附不同，最終用戶經常看到衝突的信息。