實現開放式 API 願景：美國銀行的發展藍圖

如今，美國大型銀行在談到開放式 API 對他們手頭上的資產可能造成的轉型影響時，大多都抱持相同的肯定看法。無論是縮短產品上市時間，或是透過個人化的核心服務與附加加值服務來協助重塑客戶體驗，銀行都瞭解也重視開放式 API 許下的各種潛在可能性。

不僅如此，許多美國貸款機構也開始身體力行，透過推出應用程式介面 (API) 來與第三方分享客戶資料。美國銀行 (Bank of America) 近來宣佈計畫與兩間資料整合商達成資訊共享協議，在客戶同意此協議的前提下以 API 導向的方式分享資訊。富國銀行 (Wells Fargo) 與摩根大通 (JPMorgan Chase) 也和 Finicity、Xero 及 Intuit 等第三方服務供應商/資料整合商合作，允許後者匯入自家客戶的資料。

去年 11 月，花旗集團 (Citigroup) 推出全球 API 開發者中心，讓第三方服務供應商得以打造創新的解決方案，協助優化帳戶管理、點對點支付、機構轉帳和帳戶授權等領域。此外，康百士銀行 (BBVA Compass) 在 5 月為外部程式設計師佈建了八個專屬 API，讓他們使用客戶的財務資料，並針對創造放款、支付管理和身分驗證等方面開發新服務。

這些計畫在在顯示，銀行業已認清現實，知道自己必須迅速顛覆過往的作法，否則就可能因為全球靈活創新的金融科技而面臨去中介化的風險。畢竟，在 Uber 和 Airbnb 這類企業廣受歡迎的現代，消費者渴望立即獲得滿足，因此會尋求經濟實惠、順暢無阻且內容切要的解決方案。消費者也想要進一步掌控自己的銀行資料，因為他們會想要使用自己偏好的非銀行工具來追蹤個人財務，包括支出、轉帳和稅務。

當前挑戰

只不過，即使開放式 API 仍處於剛萌芽的階段，美國的銀行仍為採用這類系統傷透了腦筋。第一個要考量的問題就是身份盜用。許多業界人士仍對「螢幕抓取」(screen scraping) 的安全性感到擔憂，目前許多第三方供應商都採用這項資料共享技術，而這會使消費者必須分享他們真正的銀行帳戶憑證。

銀行也對於部分第三方供應商 (TPP) 採用符記化授權和其他透過直接饋送 API 資料進行之驗證方法的可行性抱持懷疑態度。許多貸款機構主張，採用這類方法來代替螢幕抓取，可能會使資料不一致的問題更加嚴重，並限制整個系統的互通性。

此外，許多銀行仍在使用舊有的企業 IT 基礎架構和應用程式，使他們實行和管理開放式 API 的能力受限。再者，要將這些銀行以大型主機為中心的架構與互相連結的應用程式透過網路與第三方服務連線，仍是一項艱鉅的任務。

銀行業開放式 API，賦予更強大的 IT 能力

首先，貸款機構必須設計一個能有效管理不同 API 之間相依性的架構。他們也應該確保介面設計簡潔，讓第三方開發人員能輕鬆上手。

 再者，測試這些 API 的效能與安全性也同等重要，且若考量到當前的資料遮罩與限制會導致難以將即時資料導入測試環境，這類測試的重要性便更加不容忽視。

在實際工作環境中部署 API 後，銀行必須確保這些軟體閘道能夠隨著動態需求而快速調整規模。這點非常重要，因為銀行會與許多合作夥伴往來，而這些合作對象都必須應對其各自的聲譽和監管風險。因此，銀行需要對開放式 API 的可用性、效能、安全性和其他面向進行全面主動的監控。

未來，銀行應以首重可獨立建置、測試、部署且鬆散耦合之服務的微服務框架作為其主軸。這種由新一代自動化技術驅動的框架，能協助銀行以靈活的方式推出強大的開放式 API 功能。

與此同時，銀行應善用不同 IT 廠商和雲端平台所提供的第三方工具，在不犧牲安全性的前提下，縮短開放式 API 的上市時間。如此一來，他們將能專心推展其專屬平台上最獨到的應用層面，並透過開放式 API 展現其最具特色的功能。

最後，若要在遵守相關法規的同時，確保客戶資料標準化與完整性到位，銀行將必須採行業界通用的資料互通性標準。

儘管如此，作風靈活的競爭者已對銀行的付款和借貸等既有核心服務構成嚴峻挑戰，且客戶忠誠度正逐步下降，因此銀行勢必需要採用開放式 API，來推動破壞式創新。否則，他們將會應驗美國知名企業家 Marc Andreessen 五年多前的所做出的經典預言：「世界將被軟體給吞噬殆盡」。

作者

Rahul Singh 

金融服務與數位流程營運總裁

HCL Technologies