Deconstructing the CBN Open Banking Regulatory Framework
The Central Bank of Nigeria (CBN) has established clear, legally binding operational guidelines for Open Banking. This framework dictates precisely how traditional banks, mobile money operators, and fintech startups must interact. It introduces a specific nomenclature, dividing the ecosystem into API Providers (API-P, typically banks holding the data) and API Consumers (API-C, typically fintech apps requesting the data).
Crucially, the framework categorizes data and API endpoints into different tiers of risk, each demanding a corresponding tier of security controls. While sharing "Tier 1" generic product information might require basic authentication, sharing "Tier 3" high-risk data (like account balances, KYC documents, or initiating direct payments) requires the highest tier of security controls, rendering traditional API architectures entirely obsolete.
Mutual TLS (mTLS)
In standard web TLS, only the server proves its identity to the client. In Open Banking, mTLS is mandated. Both the API Provider and API Consumer must cryptographically verify each other using certificates issued by a trusted root before any data is exchanged.
Consent Management
The framework requires granular, explicit, and revocable user consent. The user must authorize exactly which data fields are shared, with whom, and for how long. This must align perfectly with the Nigeria Data Protection Act (NDPA).
FAPI Compliance
Financial-grade API (FAPI) profiles of OAuth 2.0 and OpenID Connect must be used to secure the authorization flow. FAPI adds layers of cryptographic signing to standard OAuth, preventing token interception, tampering, and replay attacks.
The Role of the Open Banking Registry (OBR)
One of the most complex architectural components introduced by the CBN is the Open Banking Registry (OBR). The OBR serves as the centralized trust anchor for the entire Nigerian ecosystem.
Before an API Consumer (a lending app, for instance) can request data from an API Provider (a Tier-1 bank), the bank's API gateway must query the OBR. It checks if the lending app's license is currently valid, if it is authorized to access the specific tier of data it is requesting, and it fetches the app's public keys to verify the cryptographic signatures on the API requests. This means your API gateways must be capable of real-time, high-availability integrations with the CBN's registry infrastructure.
Moving from Bearer Tokens to Sender-Constrained Tokens
The biggest, most painful shift for Nigerian engineering teams adopting Open Banking is abandoning the traditional JWT Bearer token model. In a standard Bearer token model (used by 95% of startups today), the token is like cash: if an attacker steals the token (via an XSS attack, intercepting network traffic, or finding it in a log file), they can simply attach it to their own HTTP requests and access the API as the victim.
Open Banking frameworks consider Bearer tokens too risky. Instead, they require sender-constrained tokens. These are typically implemented via Mutual TLS (mTLS) or Demonstrating Proof-of-Possession (DPoP) at the application layer.
A sender-constrained token is cryptographically bound to the specific client that originally requested it. When the API Consumer makes a request, the API Provider verifies both the token and that the client presenting the token holds the private key matching the certificate bound to that token. If an attacker steals a sender-constrained token, the API gateway will immediately reject it because the attacker's network request signature will not match.
Building an Open Banking API? Ensure your implementation meets stringent CBN and FAPI standards before going live.
Book an API Security AssessmentArchitectural Challenges with Legacy Core Banking Systems
For Tier-1 and Tier-2 Nigerian banks acting as API Providers, the primary challenge is not just the API gateway, but the legacy core banking system sitting behind it. Core systems (like Finacle or Flexcube) were never designed to handle the massive volume of read requests generated by thousands of fintech apps constantly querying account balances.
To prevent Open Banking traffic from taking down the core banking ledger, architects must implement an event-driven, eventually consistent caching layer. The Open Banking API gateway queries this highly scalable read-replica or Redis cache, rather than hitting the core system directly for every balance check. Securing this middle-tier cache - ensuring data parity and preventing cache-poisoning attacks - becomes a critical new security boundary.
Testing Open Banking implementations: Attack Vectors
When Simpa Labs conducts an API security assessment on an Open Banking platform, we do not just look for SQL injection. We target the complex seams between the OAuth flow, the cryptographic verification, and the business logic:
- Authorization Code Interception: Can we intercept the OAuth authorization code during the redirect phase and exchange it for a token without possessing the original client's secret or PKCE verifier?
- Consent Bypass and Scope Escalation: Can we manipulate the consent parameters during the OAuth flow to grant ourselves access to more accounts, or higher-tier data, than the user explicitly intended?
- mTLS Termination Flaws: Does the API gateway correctly validate the client certificate against the OBR revocation list? If the load balancer terminates the mTLS connection, does it securely forward the client certificate details to the backend application, or can those HTTP headers be spoofed?
- BOLA (Broken Object Level Authorization): Even with perfect FAPI authentication, authorization often fails at the object level. If we successfully obtain a valid sender-constrained token for User A's account, can we manipulate the API endpoint parameter (e.g., changing
/accounts/UserAto/accounts/UserB) to retrieve data for User B? BOLA remains a critical, pervasive risk in open banking.
Do not roll your own OAuth or FAPI implementation
Building a FAPI-compliant authorization server from scratch is a massive engineering undertaking fraught with catastrophic security risks. The cryptography and state management required are exceptionally complex. We strongly recommend Nigerian fintechs and banks utilize established, certified Identity Providers (like Keycloak, Auth0, Ping Identity, or specialized open banking gateways) rather than attempting to implement the OAuth 2.0 and FAPI specifications themselves.
Frequently asked questions
What exactly is FAPI and why does the CBN require it?
The Financial-grade API (FAPI) is a highly secure, stringent implementation profile of OAuth 2.0 and OpenID Connect. It was designed specifically for high-risk financial data sharing. Unlike standard OAuth, FAPI mandates mutual TLS (mTLS), sender-constrained tokens, and robust cryptographic controls to prevent token interception and replay attacks.
Can we use standard OAuth 2.0 (like Google Login) for Open Banking?
No. Standard OAuth 2.0 (often using simple Bearer tokens) is generally considered insufficiently secure for open banking APIs that move money or expose sensitive KYC data. The CBN guidelines require the enhanced security controls provided by FAPI and sender-constrained architectures.
What is a sender-constrained token?
Unlike a standard Bearer JWT (which anyone who possesses can use, similar to cash), a sender-constrained token is cryptographically bound to the specific client that requested it. If an attacker steals the token, they cannot use it because they lack the original client's private TLS certificate required to prove possession.
What is the Open Banking Registry (OBR)?
The OBR is a centralized regulatory directory maintained by the CBN. It acts as the ultimate source of truth, verifying the regulatory status, identity, and cryptographic public keys of all licensed API Providers (API-P) and API Consumers (API-C) participating in the Nigerian open banking ecosystem.
Related reading
Blog: Secure Your Fintech API · Securing Microservices Architecture · Rate Limiting and Anti-Fraud
Guides: CBN Compliance Guide · NDPA Compliance
Services: API Security Testing · Penetration Testing