Open banking is transforming the competitive landscape for Nigerian financial services. The CBN's open banking regulatory framework creates structured pathways for fintechs to access customer financial data through APIs, enabling better credit decisions, more personalised products, and reduced friction in financial services delivery. But the compliance implications of open banking are still poorly understood by many of the fintechs building on top of these capabilities. Data access, liability allocation, and customer consent create compliance risks that do not exist in traditional closed banking architectures.
What the CBN's Open Banking Framework Actually Requires
The CBN's regulatory framework for open banking in Nigeria establishes a tiered approach to data access, with different levels of access requiring different levels of regulatory authorisation. Tier 1 covers publicly available information and requires minimal credentials. Tier 2 involves product information and basic customer data, requiring API registration. Tier 3 and Tier 4 involve increasingly sensitive customer financial data and require full licensing as a payment initiation service provider or account information service provider. Many fintechs accessing banking data through third-party aggregators are operating under Tier 3 or 4 data access regimes without fully understanding the compliance obligations those tiers impose on them.
Customer Consent as a Compliance Foundation
Open banking data access is consent-driven. A fintech can only pull a customer's financial data from a bank if the customer has explicitly authorised that access. This seems straightforward but creates significant compliance complexity in practice. Consent must be specific in scope, meaning you cannot obtain consent to view transaction history and then use it to run a credit score without the customer understanding that connection. Consent must be revocable and your systems must respect revocation promptly. And consent obtained through unclear or misleading language is not valid, exposing you to data protection liability under the NDPR and the Data Protection Act 2023.
Third-Party API Security and Liability
When a fintech accesses customer data via an open banking API, it takes on responsibility for securing that data once it has received it. A data breach affecting customer financial information accessed through an open banking connection creates liability for the fintech, not just the bank that provided the API. The security requirements for storing, processing, and transmitting this data are stringent. API credentials must be protected with the same rigour as any authentication secret. Data must be stored only for as long as necessary and encrypted at rest. Third-party API aggregators used to access multiple banking data sources introduce an additional layer of risk: a breach at the aggregator level affects all the fintechs using their services simultaneously.
AML Implications of Open Banking Data Access
Open banking data access gives fintechs visibility into a customer's broader financial behaviour that was previously unavailable. This creates both opportunities and obligations for AML purposes. If a fintech can see that a customer has multiple accounts at other institutions showing suspicious patterns, does that trigger a SAR obligation? The answer is not yet settled in Nigerian regulatory guidance, but the trajectory is clear: fintechs with access to broader financial data will increasingly be expected to use it for risk management. Incorporating open banking data into your AML risk assessment and into your customer due diligence process is the prudent approach now, before regulators make it mandatory. Compliance platforms with open banking integrations can automate this enrichment so that every customer profile benefits from the fuller financial picture.
