在奈及利亞即將於八月正式啟動的開放銀行框架，將根本性地改變金融科技公司與銀行交換金融資料的方式，以及用戶認證、同意管理和產品設計的運作。

那些提早準備的團隊將在未來幾年中占據顯著的競爭優勢。為了做好準備，你需要檢視當前的架構，提升團隊對新安全協議的技能，重新設計資料管線，並重新思考產品如何處理用戶同意問題。

本文將為工程及產品團隊提供一個實用的轉型操作藍圖，幫助他們成功管理這場變革。

工程團隊的準備

對工程師來說，最顯著的變化將是認證和授權方面的改造。目前，大多數金融科技公司都是透過要求用戶提供銀行登入資訊並代為抓取數據的方式獲取金融資料。其他一些擁有強大個人網絡的公司則是獨立與不同銀行資料庫整合。然而，這並不是長期的可持續方法。

隨著開放銀行的推出，工程團隊將需運用基於 OAuth2 的流程，讓用戶透過安全轉向明確授權。團隊必須建立或整合強健的 token 管理系統來處理存取令牌，並謹慎地刷新 token 及 scope，以維持無縫且安全的用戶會話。

此外，後端系統同樣需要升級。從用戶端的同意管理將不僅僅是一個選項框選，而是一個持續並可審核的過程。因此，基礎設施必須能追蹤哪位用戶何時為哪些資料給予授權，亦及授權的時效性。這些同意記錄對於合規、用戶信任以及故障排除至關重要。

此外，您需要重新審視資料處理管線和流程邏輯。由於資料格式將在各銀行間標準化，您的資料輸入流程可以得到簡化和自動化，但只能在重新設計以消化和解譯這些一致的架構後實現。這是減少工程師多年來拼湊起來的自訂映射和轉換層的良好機會。

開放銀行還揭示了新的數據類型，例如直接扣款授權或實時支付通知。這可能需要您更新數據庫、修改事件驅動架構，或者擴展數據模型以處理更豐富的金融資訊。

最後，你的團隊需要在 API 整合 中嵌入監控並管理服務等級協議，因為銀行有契約義務維持其端點。這意味著要設計警示系統和故障回退邏輯，以優雅地處理故障或性能下降。

產品團隊的準備

從產品的角度看，開放銀行要求用戶同意和透明度方面的思維改變。您需要重新設計授權流程，讓用戶充分了解將與您分享哪些數據以及分享的目的。這不僅僅是法律形式上的表述，而是建立信任和教育用戶的一次機會。明確且直觀的用戶界面與同意管理（包括簡便撤銷授權的方法）將成為競爭優勢。

隨著現實時間數據變得更加豐富及可用，產品計劃也需要演化。那些之前很難構建的特性，如跨多個銀行的實時淨值聚合、基於現有交易數據的即時信用評分、或能夠根據消費模式反應的自動化儲蓄計劃都成為可行的方案。

產品團隊需要與工程團隊密切合作設計 API 合約和數據需求。由於開放銀行 API 提供了標準藍圖，產品可預測性及互操作性增強。然而，這需要在開發週期初期進行仔細的協調，以確保 API 功能與用戶需求及商業目標一致。

此外，開放銀行讓金融科技公司重新思考其商業模式和合作關係。產品可以從孤立的數據孤島轉變為互聯的金融生態系統，整合如支付發起、帳戶聚合及個人化財務建議等服務，創建出無縫的用戶體驗。

以下是您可以參考的操作藍圖。

檢視當前的架構

首先要徹底盤點現狀。您目前從何處提取金融資料？查明每個整合點，無論是直接的銀行合作關係，或是混合如 Mono 或 Okra的資料聚合機制，還是自訂的資料抓取工具。

特別注意您如何處理用戶憑證。您在任何地方儲存了原始的登入詳情嗎？這些憑證在服務間如何傳遞？此步驟很重要，因為從基於憑證的存取方式轉為使用OAuth令牌的過程中，可能需要重新設計之前基於不太安全假設構建的系統部分。

另外，文件記錄您的整體資料流。資料如何從銀行或資料聚合商進經後端轉入資料庫，然後到最終產品？這種可見性將有助於突出開放銀行標準將揭露的舊技術債務和整合風險。

熟悉奈及利亞的開放銀行標準

奈及利亞開放銀行的 API 規範是公開和全面的。這不只是一些技術文件供你瀏覽；團隊需要了解數據架構、認證流程（特別是帶有 FAPI 增強的 OAuth2）、同意模型和錯誤處理指導。

深入了解範圍定義：允許訪問的數據種類，以及授權的細緻程度如何？了解這些問題將塑造您的產品同意 UX 和工程需求。

讓這成為團隊努力的產物。產品經理、工程師和合規負責人都應該早早熟悉這些標準。這種共同知識將降低返工並幫助您在法規框架內找到創新機會。

重新構建資料輸入及處理管線

如果您仍依賴於拼湊的解決方案來清理和正規化銀行資料，現在是投資進行徹底革新改造的時候。開放銀行提供標準化、結構良好的數據，這意味著您的資料輸入層可以被簡化，但前提是您重新設計以來利用這些標準。

您需要：

  • 建立新解析器和驗證器，與開放銀行架構對齊。支援可用的實時數據流
  • 改進您的存儲模型以適應更豐富的數據集，比如直接扣款授權、支付發起狀態或多貨幣餘額
  • 設計穩定的錯誤處理，以防銀行無法履行服務級別協議(SLA)

把這看作是建設專為金融數據而設的可擴展、可維護且可審計的 ETL（提取、轉換、加載）系統的機會。這種投資將減少工程負擔並提升數據可靠性。

增益工程團隊在新協議和安全需求方面的技能

開放銀行是一個全新的範式。您的後端工程師必須熟練應用 OAuth2 和 OpenID Connect，特別是增強的金融級 API (FAPI) 形象設計，這能在認證和授權上實施必要的安全層。了解 token 生命週期、 scope（授權範圍）、更新 token 及安全存儲是不可避免的。

除了協定本身，工程師應學會如何實施可靠的同意記錄，以時間戳、用戶 ID 及授權範圍追蹤每個數據訪問事件。這不僅關乎合規，同時對用戶信任及故障排放也至關重要。

考慮專門的訓練課程，邀請專家，或者甚至安排資深工程師帶領缺乏經驗的工程師在安全性及身份管理方面的成長。與其在開放銀行全面實施前手忙腳亂，還不如現在開始增強實力。

制定合規、可審計和數據管理為基礎的設計

用戶同意不是一個選項框或一次性提示；而是一個必須透明、可撤銷且可審計的過程。這意味著與法律和信息安全團隊密切合作，制定滿足 NDPR（奈及利亞數據保護條例）及CBN 的開放銀行指南的政策和系統。

您的系統必須記錄誰授權分享了哪些數據，什麼時候、授權多長時間。此外，還應實施讓用戶可輕松撤銷同意的工作流程，並確保您的後端系統立即尊重這些撤銷。

另外，您還需要重新審視您的數據保存政策。您保留用戶數據的時間有多長？如何安全銷毀這些數據？這些問題都有法律、道德及運營層面的後果。

積極投身於開放銀行生態系統

奈及利亞的開放銀行體系仍在發展之中。這不是一次性完事的事件。

參與到行業工作小組、試點項目及諸如 Open Banking Nigeria 主辦的論壇中，與監管機構、銀行、同行金融科技及技術供應商交流。這種參與將讓你的團隊及早獲得未來變化、實施挑戰及最佳實踐的洞見。

參與談判也意味著你的公司可以影響框架的發展，幫助制定符合您產品需求的標準、安全策略及操作規範。

最後，這些網絡能成為寶貴的合作渠道，在生態系統成熟之際激發新的業務機會。

結論

現在是時候重新評估您的系統運作方式。

拋棄那些速成解決方案，構建安全、標準化及易維護的整合方式。

開放銀行即將到來。您準備好做出必要的變革並適應這個新環境了嗎？