The CBN Open Banking Regulatory Framework
The Central Bank of Nigeria has established clear operational guidelines for Open Banking, dictating how API Providers (API-P) and API Consumers (API-C) must interact. This framework establishes the Open Banking Registry (OBR) and mandates stringent security controls, classifying data into different tiers of risk.
Sharing high-risk data (like account balances or initiating payments) requires the highest tier of security controls, rendering traditional API architectures obsolete.
Mutual TLS (mTLS)
In standard TLS, only the server proves its identity to the client. In Open Banking, mTLS is mandated so both the API Provider and API Consumer cryptographically verify each other before exchanging data.
Consent Management
The framework requires granular, explicit user consent. The user must be able to authorize exactly which data fields are shared, with whom, and for how long, adhering to NDPA requirements.
FAPI Compliance
Financial-grade API (FAPI) profiles of OAuth 2.0 and OpenID Connect must be used to secure the authorization flow, preventing token interception and replay attacks.
Moving from Bearer Tokens to Sender-Constrained Tokens
The biggest shift for Nigerian engineering teams is abandoning the traditional JWT Bearer token model. In a Bearer token model, if an attacker steals the token (via an XSS attack or intercepting traffic), they can use it to access the API.
Open Banking requires sender-constrained tokens (typically implemented via MTLS or DPoP - Demonstrating Proof-of-Possession). These tokens are cryptographically bound to the client that requested them. If an attacker steals a sender-constrained token, the API gateway will reject it because the attacker's request signature won't match the certificate bound to the token.
Building an Open Banking API? Ensure your implementation meets CBN and FAPI standards.
Book an API Security AssessmentTesting Open Banking implementations
When we conduct an API security assessment on an Open Banking platform, we target the seams between the OAuth flow and the business logic:
- Authorization Code Interception: Can we intercept the OAuth authorization code and exchange it for a token without the original client secret?
- Consent Bypass: Can we manipulate the consent parameters during the OAuth flow to grant ourselves access to more accounts than the user intended?
- BOLA (Broken Object Level Authorization): If we successfully obtain a token for User A's account, can we manipulate the API endpoint to retrieve data for User B? BOLA remains a critical risk even with strong authentication.
Do not roll your own OAuth
Building a FAPI-compliant authorization server from scratch is a massive engineering undertaking fraught with security risks. We strongly recommend Nigerian fintechs utilize established, compliant Identity Providers (like Keycloak, Auth0, or Ping Identity) rather than attempting to implement the OAuth 2.0 specifications themselves.
Related reading
Blog: Secure Your Fintech API · Securing Microservices Architecture
Guides: CBN Compliance Guide
Services: API Security Testing
Frequently asked questions
{faq.q}
{faq.a}