The shared infrastructure problem
Nigerian financial institutions do not operate in isolation. They share critical infrastructure in ways that create systemic exposure far beyond what any individual institution's risk register captures.
Remita handles payment settlement for the majority of government-to-bank and institution-to-institution transactions in Nigeria. Interswitch processes the switching layer that routes card transactions between banks. NIBSS provides the clearing and instant payment backbone through NIP. These are not optional integrations — they are the plumbing that makes Nigerian banking function.
This creates concentration risk, which is a category more dangerous than standard third-party risk. When a single vendor serves as the connective tissue between dozens of financial institutions, a compromise of that vendor is not an isolated incident. It is a sector-wide event.
The problem compounds because these shared service providers also depend on each other. Remita connects to NIBSS for settlement. Payment processors connect to Interswitch for routing. Banks connect to all of them simultaneously. The dependency graph is not a tree — it is a web, and a break at any central node propagates outward to every connected institution.
Most risk frameworks treat third-party relationships as bilateral: your institution and your vendor. That framing misses the reality that your vendor's other clients are now part of your attack surface. When a payment processor is compromised, the threat actor does not need to attack your bank directly. They already have access to your transaction data, your API credentials, and your settlement instructions through the shared platform.
This is not a theoretical concern. The events of early 2026 proved it.
How the chain breaks
The attack pattern against shared financial infrastructure follows a predictable sequence, and the Remita compromise illustrated every stage of it.
Stage 1: Initial access to the shared platform. The threat actor gains a foothold in the payment processor's environment — through a phishing campaign against staff, exploitation of an unpatched external-facing application, or compromise of a privileged vendor credential. The entry point is rarely sophisticated. It does not need to be. Shared platforms are high-value targets with broad attack surfaces.
Stage 2: Lateral movement within the processor. Once inside, the attacker maps the internal environment. Payment processors hold the keys to the kingdom: API credentials for connected banks, Hardware Security Module (HSM) keys used for transaction signing, settlement configuration data, and transaction logs spanning every connected institution. The attacker moves from the initial foothold toward these high-value assets.
Stage 3: Credential and key extraction. In the Remita scenario, 46 HSM keys belonging to major Nigerian banks were exposed. HSM keys are the cryptographic foundation of payment security — they authenticate and sign transactions. With these keys, an attacker can forge transactions, redirect settlements, or impersonate a bank in the payment network. The exposure of 46 keys in a single incident meant that dozens of institutions were simultaneously compromised through no failure of their own.
Stage 4: Exploitation across connected institutions. With extracted API credentials and HSM keys, the attacker can now interact with connected banks as if they were the legitimate payment processor. They can initiate transactions, modify settlement instructions, or exfiltrate customer data. The banks' own security controls — firewalls, intrusion detection, access management — are largely blind to this because the traffic arrives through a trusted channel.
Stage 5: Detection delay. Because the malicious activity originates from a trusted third party, detection is slow. Banks monitoring their own perimeters see normal traffic from a known partner. The processor, if it detects the breach at all, may delay notification to limit reputational damage. Days or weeks pass before the scope of the compromise becomes clear.
Each stage of this chain exploits the trust relationships that make shared infrastructure functional. The same API connections and cryptographic keys that enable legitimate payment processing become the attack vectors.
Current state of vendor assessments
The standard vendor assessment process at most Nigerian financial institutions is a compliance exercise that produces documentation, not security.
The typical cycle: once a year, the risk or compliance team sends a questionnaire to each vendor. The vendor self-reports its compliance status — yes, we have a firewall; yes, we encrypt data at rest; yes, we conduct annual penetration testing. The responses are filed. The vendor is approved for another year.
This process has specific, identifiable failures.
No technical validation. Self-reported compliance is not verified. If a payment processor claims to encrypt HSM keys at rest, no one from the bank inspects the encryption implementation, reviews the key management practices, or tests whether the encryption is correctly applied. The questionnaire answer is taken at face value.
No on-site assessments. Critical vendors that handle millions of transactions daily are assessed entirely through written questionnaires. The bank's security team never visits the vendor's data center, never observes operational practices, never interviews the vendor's engineering or security staff.
No penetration testing of third-party environments. Banks conduct penetration tests of their own infrastructure but do not require — or contractually cannot require — penetration testing of the third-party environments that connect directly to their core banking systems.
No continuous monitoring. The annual questionnaire creates a 12-month gap during which the vendor's security posture can deteriorate without detection. Staff turnover, infrastructure changes, new vulnerabilities, and configuration drift all occur between assessment cycles. The bank has no visibility into any of it.
No fourth-party awareness. Banks assess their direct vendors but have no visibility into their vendors' vendors. If a payment processor outsources its cloud hosting to a provider with weak controls, the bank's risk assessment does not capture that exposure.
The result is an assessment regime that satisfies an audit checklist while providing minimal actual assurance about the security of the third-party environment.
CBN's third-party risk framework
The Central Bank of Nigeria has issued guidance on outsourcing and third-party risk management that establishes clear expectations for regulated institutions. The framework, grounded in CBN circulars on outsourcing arrangements and the broader Risk-Based Cybersecurity Framework, includes specific requirements.
Due diligence before engagement. Institutions must assess a vendor's security posture, financial stability, and operational capability before entering into a contractual relationship. This due diligence must be commensurate with the criticality of the service being outsourced.
Contractual security requirements. Agreements with third parties must include defined security obligations: data protection standards, incident notification timelines, compliance with CBN regulations, and provisions for what happens at contract termination (data return, destruction, transition support).
Right-to-audit clauses. Contracts must give the institution — and by extension, CBN — the right to audit the third party's operations, security controls, and compliance posture. This includes the right to conduct on-site inspections and to commission independent assessments.
Incident notification obligations. Third parties must notify the institution of security incidents within defined timelines. The institution, in turn, must notify CBN. The framework envisions a chain of notification that enables coordinated response across the sector.
Ongoing monitoring. The framework requires continuous oversight of third-party relationships, not just initial due diligence. Institutions must monitor vendor performance, security posture, and compliance on an ongoing basis.
The gap between framework and practice is substantial. Few institutions have operationalized these requirements into functioning programs. Right-to-audit clauses exist in contracts but are rarely exercised. Incident notification procedures are defined but untested. Continuous monitoring is an aspiration, not an operational reality.
CBN's post-breach posture — including the mandatory Cybersecurity Self-Assessment Tool (CSAT) — suggests that regulatory tolerance for this gap is narrowing.
API security in the PSP ecosystem
The Payment Service Provider (PSP) ecosystem connects to banks through APIs that are, in many cases, the weakest link in the security chain.
Nigeria's open banking agenda, driven by CBN's regulatory sandbox and the growth of fintech integration, has dramatically expanded the API surface area. Every new fintech that connects to a bank's core system does so through an API. Every payment gateway, every mobile money operator, every lending platform that pulls account data or initiates transactions is an API consumer.
Common failures in this ecosystem are well-documented and persistent.
API keys stored in plaintext. Credentials that authenticate PSPs to bank systems are stored in configuration files, environment variables without encryption, or — in the worst cases — hardcoded in application source code. A compromise of the PSP's codebase or server environment immediately yields the keys to initiate transactions at connected banks.
No rate limiting. APIs that process financial transactions accept unlimited requests per second from authenticated clients. An attacker with stolen API credentials can initiate thousands of transactions before anyone notices anomalous volume.
No certificate pinning. TLS connections between PSPs and banks rely on certificate authorities for trust validation but do not pin specific certificates. This makes man-in-the-middle attacks feasible in environments where certificate authority compromise or DNS manipulation is possible.
Shared environments between testing and production. PSPs that maintain a single environment — or environments with shared credentials — create a path from test systems (which typically have weaker controls and broader access) directly into production payment infrastructure.
Inadequate token management. OAuth tokens with excessive scopes, long expiration windows, and no rotation policies give persistent broad access to bank systems. A single compromised token can provide weeks or months of unauthorized access.
The open banking agenda increases this exposure by design. More connections mean more API endpoints, more credential sets, more integration points to secure. The regulatory push for financial inclusion through fintech integration is sound policy, but it demands a corresponding investment in API security that has not materialized across the sector.
What a real third-party risk program looks like
A functioning third-party risk program is not a questionnaire. It is an operational capability with defined processes, technical controls, and organizational accountability.
Risk tiering. Not all vendors require the same level of scrutiny. A critical vendor — one that processes payments, holds customer data, or connects to core banking systems — demands a fundamentally different assessment than a vendor supplying office furniture. The first step is classifying every vendor by the severity of impact if that vendor is compromised. Critical vendors get the full program. Standard vendors get proportionate controls.
Initial security assessment with technical validation. For critical vendors, the assessment must go beyond questionnaires. It includes: review of the vendor's security architecture documentation, independent penetration testing of the vendor's external-facing systems, review of the vendor's incident response plan and evidence of testing, on-site assessment of physical and logical security controls, and validation of the vendor's own third-party (fourth-party) risk management.
Contractual security requirements. Security obligations must be specific and enforceable — not generic clauses about "industry best practices." The contract specifies: encryption standards, access control requirements, logging and monitoring obligations, incident notification timelines (measured in hours, not days), data handling and retention policies, and consequences for non-compliance including termination rights.
Continuous monitoring. Replace the annual questionnaire with ongoing visibility. This includes: automated monitoring for vendor credential exposure (dark web monitoring services), regular review of the vendor's external attack surface (exposed services, vulnerable software, misconfigured infrastructure), periodic reassessment against the initial baseline, and integration of vendor risk data into the institution's overall risk dashboard.
Incident response coordination. A documented, tested process for responding to vendor security incidents. This includes: predefined communication channels between the institution and critical vendors, joint incident response procedures, escalation criteria, and regular tabletop exercises that simulate a vendor compromise scenario.
Fourth-party risk awareness. Visibility into the critical subcontractors and service providers that your vendors depend on. If your payment processor hosts on a specific cloud provider, you need to understand the security implications of that dependency. Contractual requirements should include notification obligations when vendors change critical subcontractors.
Practical steps for 2026
For institutions that need to move from checkbox compliance to operational third-party risk management, these are the immediate priorities.
Inventory all third-party connections. Map every vendor that connects to your systems, handles your data, or processes transactions on your behalf. Include cloud providers, API integrations, managed service providers, and SaaS platforms. You cannot manage risk you have not identified.
Classify by criticality. Assign each vendor a risk tier based on: access to sensitive data, connection to core banking systems, transaction processing capability, and the impact of the vendor's unavailability on your operations. Payment processors, switching networks, and cloud infrastructure providers are automatically critical tier.
Require SOC 2 or equivalent from critical vendors. For vendors classified as critical, require an independent security assessment — SOC 2 Type II, ISO 27001 certification, or an equivalent third-party audit. Self-reported compliance is insufficient for vendors with direct access to your payment infrastructure.
Implement API gateway security. Place an API gateway between your core systems and all external integrations. Enforce rate limiting, request validation, certificate pinning, token rotation, and anomaly detection at the gateway layer. This creates a choke point where malicious activity from compromised third parties can be detected and blocked.
Establish vendor incident notification procedures. Define contractual notification timelines — 4 hours for confirmed breaches involving your data or systems, 24 hours for suspected incidents. Test these procedures annually. A notification clause that has never been exercised is a notification clause that will fail when needed.
Build contractual right-to-audit. Negotiate the right to audit critical vendors' security controls, either directly or through an independent assessor. Exercise this right at least annually for critical-tier vendors. The right-to-audit is meaningless if it exists only on paper.
Monitor for vendor credential exposure. Subscribe to dark web monitoring services that scan for exposed credentials, API keys, and internal documents belonging to your critical vendors. When your payment processor's credentials appear on a dark web marketplace, you need to know before the threat actor uses them against your institution.
The Remita compromise was a sector-defining event. It demonstrated that the security of Nigerian financial institutions is only as strong as the weakest vendor in the chain. Institutions that continue to treat third-party risk as a compliance checkbox are accepting a level of exposure that is no longer defensible — not to regulators, not to customers, and not to their boards.
The question is not whether another shared-infrastructure compromise will occur. It is whether your institution will be prepared when it does.