On 10 September 2026, at the 19th Annual Banking and Finance Conference of the Chartered Institute of Bankers of Nigeria in Abuja, Dr Rakiya Yusuf — Director of Payments System Supervision at the Central Bank of Nigeria and Chairperson of the Nigeria Electronic Fraud Forum — told banks, fintechs and other financial institutions to treat cybersecurity and third-party technology risk as critical financial stability issues, not IT problems.
The reasoning she gave is the part worth reading twice: the sector's growing reliance on fintechs, payment service providers, cloud operators and other technology vendors has created new channels through which a failure in one institution can cascade across the system. In other words, the regulator is no longer looking only at your perimeter. It is looking at your dependency graph.
Let us be precise about what this is and is not. This was a supervisory speech at an industry conference, not a circular. No new circular name, reference number or compliance deadline was announced. But CBN supervisory speeches are how examination priorities get telegraphed, and "we are now thinking of vendor concentration as systemic risk" is about as clear a signal as this kind of speech gets.
What the CBN actually asked for
Six things, in substance:
1. Treat cyber and third-party technology risk as financial stability issues — escalated to the same level as capital and liquidity risk, not delegated downward.
2. Continuously assess dependencies, third-party relationships and technology partners, with a view to understanding how a disruption propagates through the ecosystem.
3. Extend cybersecurity and risk-management oversight to third-party service providers, including evaluating their capacity to withstand a cyberattack.
4. Report incidents and vulnerabilities to regulators early, so intervention can happen before an isolated breach becomes a systemic one.
5. Strengthen data governance — know where critical data is stored, who can access it, and confirm that the institution retains effective control over it.
6. Build real monitoring capability, specifically stronger Security Operations Centres capable of monitoring threats in real time.
Five of those six land on an engineering team.
What this means in practice
The gap between "we have a vendor risk policy" and what is being asked for here is mostly a gap between a document and a system. Concretely:
Build a dependency inventory that is actually complete. Most institutions have a procurement list of contracted vendors. That is not the dependency graph. The real one includes your cloud provider and its region, your PSPs and their upstream switches, your KYC and BVN/NIN verification providers, your SMS and email gateways, your observability vendor, and the transitive open-source dependencies in your build. An SBOM plus a SaaS inventory plus a payment-rail map is the minimum, and it needs an owner and a refresh cadence, because it is wrong within a month of being written.
Find the single points of failure, then say them out loud. The question the regulator is implicitly asking is: if provider X is down for six hours, what stops? For most Nigerian fintechs there are two or three providers where the honest answer is "settlement" or "onboarding," and the concentration is invisible because three of your four vendors resolve to the same upstream. Map it once and the conversation changes from abstract to specific.
Get contractual reach over the vendors that matter. Point 3 asks you to evaluate a third party's resilience, which you cannot do without a right to audit, a right to receive their incident notifications within a defined window, and evidence of their own controls — SOC 2, ISO 27001, penetration test summaries. Renewal time is when this gets added; it rarely gets added mid-term.
Write the incident disclosure runbook before you need it. "Report promptly to the regulator" is an operational commitment with a clock on it. The runbook needs to name who decides it is reportable, who writes the notification, what goes in the first message when facts are still thin, and how you communicate with customers in parallel. A team improvising this at 2am will be slow, and slowness is what point 4 is aimed at.
Answer the data governance questions with queries, not assertions. Where is critical data stored, who can access it, does the institution retain effective control? Those should be answerable from your infrastructure — an access review you can regenerate, a data inventory tied to your schema, region pinning you can prove. If the answer lives in a spreadsheet maintained by one person, you do not have the control you think you have.
On the SOC: real-time monitoring is the expensive item on this list, and building a 24/7 in-house SOC is out of reach for most institutions below tier one. Managed detection and response is the pragmatic answer, but only if you have done the inventory work above — an MDR provider watching an incomplete asset list produces the appearance of monitoring rather than the substance.
Context: the regulatory direction is consistent
This is not an isolated remark. The NDPC expanded its data privacy enforcement earlier in 2026, issuing compliance notices to over 1,300 organisations for suspected breaches. The CBN published a Fintech Policy Insight Report in February 2026 setting out a Standing Engagement Forum and a Compliance-as-a-Service model — an attempt to make regulation workable rather than adversarial. And the sector spent 22–23 September at Nigeria Fintech Week 2026, themed "Legacy in Motion: Powering the Digital Renaissance."
The consistent thread is that Nigerian financial services regulation is maturing from rules about products to rules about operational resilience. Vendor risk, incident response and data governance are where that maturity shows up first.
What this changes
If you run engineering at a Nigerian bank or fintech, one thing moves to the top of the list this quarter: produce an honest dependency inventory and a single-point-of-failure map, and take them to your risk committee. Everything else on the CBN's list is downstream of that document, and you cannot extend oversight to third parties you have not enumerated.
If you are a technology vendor selling into Nigerian financial services, expect the diligence to get sharper. Questions about your own subprocessors, your incident notification commitments and your attestation evidence are going to start appearing in deals where they did not before. Having those answers ready is a sales advantage for the next year or two, and then it becomes table stakes.
We build compliance-sensitive systems for Nigerian financial services — related reading: cybersecurity threats facing Nigerian fintech in 2026, building NDPR-compliant software in Nigeria, and CBN open banking APIs for developers. If you need help turning this into an actual engineering plan, that is what we do.