Open Banking Nigeria: What the CBN Framework Means for Your Business Software
Most Nigerian business owners have not read CBN's open banking framework. The licensed aggregators are live, the APIs are available, and the opportunity to build payments and financial data workflows that reduce friction and cost is real now.
Disclaimer
This article is for educational purposes only and does not constitute legal, financial, or professional advice. Compliance requirements vary by industry and jurisdiction. Consult a qualified professional for guidance specific to your organisation. Information was accurate at the time of writing — verify current regulations with the relevant authorities.
Open Banking Nigeria: What the CBN Framework Means for Your Business Software
The Central Bank of Nigeria published its Operational Guidelines for Open Banking in February 2021¹ and has progressively licensed aggregators to operate under the framework since then. The licensed intermediaries — including Mono, Okra, OnePipe, and Stitch — are live and processing production transactions. The regulatory infrastructure exists. The APIs exist.
What most Nigerian businesses lack is clarity on what the framework actually permits and how it translates to software capability.
The Three-Tier Framework
CBN's open banking framework organises data and payment access into three tiers, each with different licensing requirements and access scope.
Tier 1 — Product and Service Information: Public data about financial products — rates, terms, branch locations, product features. No customer authentication required. The lowest-risk tier, primarily useful for comparison tools and product aggregation.
Tier 2 — Customer Information: Customer financial data accessed with explicit consent. Bank statements, account balances, transaction histories, identity-linked data. Requires customer authentication through the bank's consent mechanism. Useful for credit scoring, KYC, financial management, and affordability assessment.
Tier 3 — Payment and Transaction Initiation: The ability to initiate payments from a customer's bank account with their consent. Account-to-account transfers, direct debit, and payment collection without routing through a card network. Requires the highest licensing level and the most rigorous compliance requirements.
Most commercially valuable applications are Tier 2 (financial data access) or Tier 3 (payment initiation). Understanding which tier a use case falls under determines the licensing path and the integration approach.
The Licensed Aggregator Ecosystem
CBN does not require every business to obtain its own open banking licence. Licensed Open Banking Aggregators are intermediaries that hold the required licences and provide API access to businesses built on their platforms.
The major licensed aggregators serving the Nigerian market:
Mono specialises in financial data access (Tier 2). Their Connect product enables bank statement retrieval, balance checks, identity verification, and recurring data access with customer consent. Integration is through a JavaScript widget (for web) or a React Native SDK (for mobile) that handles the bank authentication flow. The aggregated result is structured JSON data.
Okra covers financial data access and has expanded toward transaction services. Offers similar connect flows with a broader bank coverage in some regions.
OnePipe focuses on Tier 3 payment products — virtual accounts, collections, and disbursements — with bank connectivity through their licence.
Stitch (primarily South Africa, expanding into Nigeria) offers payments and financial data with strong developer tooling.
The practical integration decision: evaluate which aggregator covers the banks your customers actually use at the coverage percentage your use case requires, then build against their API. Switching aggregators is a moderate effort migration; do not over-engineer for multi-aggregator flexibility at the design stage.
Tier 2 in Practice: Financial Data Applications
Credit Scoring Without a Credit Bureau
Traditional credit bureau data in Nigeria has significant gaps — many individuals and small businesses have limited formal credit histories. Open banking financial data — bank statement analysis, cash flow patterns, income verification — fills the gap with forward-looking behavioural data rather than backward-looking credit history.
An affordability engine built on Mono Connect retrieves the past twelve months of bank statements for a credit applicant, extracts monthly inflows and outflows, identifies salary-like regular credits, calculates average monthly disposable income, and produces an income-confidence score and debt-service capacity estimate.
This does not replace credit bureau checks — it supplements them. Combined, the picture is more accurate than either alone, and for the significant population of applicants with thin credit files, the bank statement analysis is the only quantitative input available.
Technical implementation: Customer authenticates with their bank through the Mono Connect widget → Mono returns a customer_id and account data → polling or webhook delivers transaction history as structured JSON → your scoring engine processes the data → score returned to the originating workflow.
Data refresh can be set to automatic (Mono retrieves updated data on a schedule with customer consent) or on-demand (customer triggers refresh at each application point). For recurring credit assessment this is significant: you can underwrite a line of credit increase monthly using fresh bank data without requiring the customer to re-authenticate each time.
KYC Acceleration
Manual KYC involves the customer uploading identity documents, a back-office team verifying them, and a delay of one to three business days. Open banking KYC supplements document verification with bank identity confirmation: the bank has already KYC'd the account holder; the aggregator can confirm that the person authenticating matches the bank's records.
A hybrid KYC flow: customer authenticates with their primary bank through Mono Connect → bank identity data (name, date of birth, BVN-linked attributes) pre-fills the application → customer uploads supporting documents → document verification runs in parallel with bank data cross-check → KYC complete in minutes rather than days.
The bank identity layer does not replace regulatory KYC requirements, but it significantly reduces the manual verification burden and enables straight-through processing for clean cases.
Tier 3 in Practice: Payment Initiation
Account-to-Account Collections
Card payments carry a processing fee of 1.5% (capped at ₦2,000 on most Nigerian card transactions).² Account-to-account payments using open banking initiation have fees set by the aggregator and are typically lower per transaction, with no cap variation.
For high-value B2B transactions — supplier payments, enterprise invoicing, real estate transactions — the fee difference is material. A ₦5M transaction on a card-based gateway costs approximately ₦2,000 (fee cap). The same transaction via A2A payment costs a flat aggregator fee, typically ₦200–₦500 depending on the aggregator and volume pricing.
For consumer-facing businesses with high average order values: the same logic applies. Property rent collection, school fees, bulk purchasing — these are the use cases where A2A payment initiation produces meaningful cost savings.
Technical implementation: Invoice generated in your system → payment link or in-app payment flow sends customer to aggregator's authentication widget → customer authenticates and approves debit from their bank → aggregator debits sending account and credits your receiving account → webhook confirms settlement → your system updates payment status.
The key operational difference from card payments: A2A payments settle in finalised form, not in pending authorisations. Chargebacks do not exist in the same way. The customer has irrevocably authorised the debit once confirmed; the dispute mechanism is a bank enquiry rather than a card chargeback.
Virtual Accounts for Reconciliation
Virtual accounts are unique bank account numbers assigned to individual customers or transactions, enabling automatic payment reconciliation without manual reference matching.
When a customer makes a bank transfer to pay an invoice, matching the transfer to the invoice is normally a manual reconciliation task: the finance team checks bank statements against invoice references and updates each record. At scale — forty, fifty, a hundred invoices per day — this consumes significant accounts receivable time.
With virtual accounts: each customer or each invoice gets a unique virtual account number. Every transfer to that number is automatically associated with the customer or invoice it belongs to. Your accounts receivable system processes reconciliation automatically; zero manual matching.
The OnePipe and Flutterwave virtual account products both support this pattern. Integration is a webhook that fires on each transfer credit, delivering the amount and the virtual account identifier, which your system maps to the appropriate record.
Integration Patterns
Customer consent lifecycle: Open banking requires explicit customer consent for each data access. Consents expire (typically 90 days for recurring access, with renewal required). Your application needs consent state management: which customers have active consents, when consents expire, and re-authentication flows that are minimal friction.
Webhook reliability: Payment and data webhooks must be processed idempotently. If the aggregator webhook fires twice (retry after a non-200 response), processing it twice must not create two credits or two reconciliation records. Implement event ID deduplication before processing any webhook.
Bank coverage varies by aggregator. A fintech targeting SMEs in Lagos may find adequate coverage with primary commercial banks. One targeting agricultural businesses in the north may find coverage gaps with regional banks. Evaluate coverage against your actual customer bank distribution before committing to integration depth.
Error handling for authentication failures: Bank consent flows can fail at several points — the bank's authentication service may be down, the customer may not complete the flow, or MFA may fail. Your flow needs graceful fallback (return to manual payment option or document upload) for authentication failures. Do not make open banking the only path for critical workflows.
What to Build First
For businesses not yet using open banking APIs, the highest-value first integration is typically Tier 2 financial data for credit or KYC acceleration if the business is in financial services, or Tier 3 virtual accounts for reconciliation if the business has significant invoice volume.
Both integrations can be implemented against a single aggregator in three to six weeks of engineering time, with production licensing and compliance review adding two to four weeks depending on the business's existing KYC/AML procedures.
The framework is not future infrastructure. It is live infrastructure. The businesses building on it now are reducing payment costs, accelerating onboarding, and improving underwriting while competitors wait for clearer regulatory signals that are already available.
Related Articles
- Integrating Paystack and Flutterwave Beyond Basic Checkout — Payment integration patterns
- Fraud Detection Architecture for Nigerian Financial Applications — Security in financial services
- Nigerian Tech Regulatory Landscape 2026 — Complete regulatory reference guide
Sources
- CBN, Regulatory Framework for Open Banking in Nigeria (February 2021)
- CBN, Payment System Vision 2025
- Nigeria Inter-Bank Settlement System (NIBSS) — nibss-plc.com.ng