隨著尼日利亞中央銀行批准後，尼日利亞的開放銀行框架將於八月正式啟動。這項規範的實施將從根本上改變金融科技公司及銀行交換財務數據、管理用戶驗證、同意及設計產品的方式。正因如此，那些提前準備的團隊將在未來幾年中佔據顯著的優勢。為此，需要對現有的架構進行審核，提升產品和工程團隊在新安全協議上的技能，並重新設計數據管道及思考產品如何處理用戶同意的問題。本文將提供一個實用路線圖，幫助工程及產品團隊成功管理這一轉變。

工程團隊的應對策略

對工程師來說，最顯著的變化在於驗證和授權方式。目前，大多數金融科技公司透過讓用戶提供銀行登入資料來獲取財務數據，並代表用戶抓取數據。此外，還有一些金融科技公司藉由強大的人脈網絡，與不同銀行的資料庫進行集成，但這不是長遠之計。隨著開放銀行的推出，工程師需要處理基於 OAuth2 認證流程，透過安全的重定向用戶明確地授權。工程團隊必須建立或集成強大的令牌管理系統，處理訪問令牌，同時細心管理令牌和範圍的刷新，保持用戶會話的無縫安全。後端系統也需要升級，用戶授權不再只是一個勾選框，而是一個持續的、可審核的過程。因此，基礎設施必須追蹤哪些用戶在哪些數據上授權、何時及持續多久。這對合規、用戶信任及除錯至關重要。此外，數據管道和處理邏輯也需要重新檢視。由於數據格式將在所有銀行保持標準化，數據輸入流程可以簡化並自動化，但前提是要重新設計以便能夠消化及解讀這些一致的架構。這是減少工程師多年來拼湊的客製化映射及轉換層的好機會。工程師還需要容納開放銀行揭露的新數據類型，如直接扣款授權或實時支付通知。這可能需要更新數據庫，修訂事件驅動架構，或擴展數據模型以應對更豐富的財務信息。最後，您的團隊需要在 API 集成中嵌入監控和服務級別協議（SLA）管理，因為銀行在法律上有義務維護其端點。這意味著需要建立警報系統和回退邏輯，以優雅地處理中斷或性能下降。

產品團隊的應對策略

從產品角度來看，開放銀行要求在用戶同意和透明度方面進行思維轉變。需要重新設計同意流程，以便用戶完全了解與您共享的數據及其用途。這不是一個隱藏在條款和條件中的法律禮儀，而是一個建立信任和教育用戶的重要時刻。清晰、直觀的用戶體驗（UX）在授權管理方面將成為競爭優勢。隨著更豐富、實時的數據變得可用，產品路線圖也必須演進。以前難以構建的功能，如跨多家銀行的實時淨值聚合、基於活動交易數據的即時信用評分，或根據花費模式變動的自動儲蓄計畫，都變得可能。產品團隊還需要與工程團隊密切合作，共同設計 API 合同和數據需求。由於開放銀行 API 提供了標準藍圖，產品變得更加可預測和互通。然而，這需要在開發早期階段進行仔細協調，以確保 API 的能力與用戶需求及商業目標一致。此外，開放銀行讓金融科技公司可以重新思考商業模式及合作關係。產品可以從獨立的孤島轉向互聯的金融生態系統，把支付發起、賬戶聚合及個人化金融建議等服務整合到無縫的體驗中。以下是一條實用的路線圖：

審核您目前的架構

從全面的盤點開始。您目前從哪裡獲取金融數據？識別每個集成點，無論是直接的銀行合作、如 Mono 或 Okra 這樣的聚合器，還是自建的抓取工具。特別關注如何處理用戶憑證。您是否在任何地方存儲了原始的登入信息？這些憑證是在服務之間如何傳遞的？這一步很重要，因為從基於憑證的訪問轉為令牌化的 OAuth 流程意味著需要重新設計系統中的某些部分，這些部分也許是建立在較少安全假設基礎上的。此外，記錄從頭到尾的數據流程。數據從銀行或聚合器經過您的後台，進入您的數據庫，最終進入您的產品。在開放銀行標準之下，這樣的可見性將幫助發現技術債務及集成風險。

熟悉尼日利亞開放銀行標準

尼日利亞開放銀行的API規範是公開且全面的，這不僅僅是技術文件，需要您的團隊了解數據架構、驗證流程（尤其是含 FAPI 增強的 OAuth2）、同意模型和錯誤處理指南。深入了解範圍定義：允許了哪些類型的數據訪問，權限可以多細緻？了解這些將決定您產品的授權用戶體驗及工程需求。讓它成為團隊的努力。產品經理、工程師及合規官員需要早期熟悉這些標準。這種共享知識有助於減少重工，並幫助您在框架中發現創新機會。

重構您的數據攝取及處理流程

如果您仍依賴於拼接的解決方案來清理及規範銀行數據，那麼現在是時候投入重建。開放銀行提供標準化、結構良好的數據，這意味著如果您重新設計以利用這些標準，數據輸入層則可以簡化。您需要：

  • 建立與開放銀行架構對應的新解析器和驗證器，支持即時數據流
  • 增強您的存儲模型，以適應更多元的數據集，如直接扣款授權、支付發起狀態或多幣種餘額
  • 設計穩健的錯誤處理，以應對銀行未達到 SLA 的情況

把這視為為金融數據構建可擴展、可維護及可審計的ETL（抽取、轉換、加載）系統的機會。這項投資會減少工程師的負擔並提高數據可靠性。

提升工程團隊在新協議及安全需求上的技能

開放銀行是一個新的範例。您的後端工程師必須熟練掌握 OAuth2 和 OpenID Connect，尤其是添加了必要安全層的金融級 API（FAPI）配置文件，這圍繞驗證及授權進行保護。了解令牌的生命週期、範圍、刷新令牌及安全存儲是不容忽視的。不僅限於協議，工程師還應學習如何實施強大的授權日志，追踪每個數據訪問事件的時間戳、用戶 ID 與同意範圍。這不僅僅是合規問題；對於用戶信任及除錯同樣重要。考慮到專門的培訓課程、邀請專家，甚至在經驗豐富的安全及身份管理人員的指導下，與初級工程師配對學習。現在便開始建立這種能力，比起在開放銀行全面啟動後慌亂準備要好得多。

設計合規、可審核及數據治理的流程

用戶授權不是一個勾選框或者一次性提示；這是一個必須透明、可撤回及可審核的過程。這意味著必須與您的法律及信息安全團隊密切合作，制定出一套滿足 NDPR（尼日利亞數據保護法規）及 CBN 的開放銀行指引的政策及系統。您的系統必須記錄誰同意了哪些數據分享，何時及持續多長時間。此外，還應實施讓用戶容易撤回同意的流程，並確保您的後端立即尊重這些撤銷。您還需要重新檢視您的數據保留政策。用戶數據保留多久？如何安全地處理？這些問題有法律、道德及運營後果。

積極參與開放銀行生態系統

尼日利亞的開放銀行仍在發展中，這不是 "設立後即忘" 的時刻。參加行業工作小組、試點計劃和由開放銀行尼日利亞主持的論壇。與監管機構、銀行、其他金融科技公司及技術提供者互動。這種參與將讓您的團隊及早了解即將到來的變化、實施挑戰及最佳實踐。做對話的一部分，這也意味著您的公司可以影響框架的發展，有助於制定標準、安全政策及運營規範，以符合作品需求。最後，這些網絡可以成為合作及合作的寶貴來源，隨著生態系統的成熟，打開通往新商業機會的大門。

結論

現在是重新思考您系統工作方式的時候了。不要再依賴於快速解決方案；建立安全、標準化及易於維護的集成。開放銀行即將來臨，您是否準備好進行必要的改變並適應這個新環境？

作者

本文章由 Chigozie Madubuko 撰寫，他是 Kora 的後端工程主管，致力於構建安全、可擴展的金融解決方案。他專注於設計高性能系統，推動無縫的金融交易及集成。Chigozie 在影響尼日利亞的開放銀行 API 標準方面扮演了關鍵角色，與行業領導者一同努力提升尼日利亞的金融普惠性。