The scale of the problem
In 2024, NIBSS processed over ₦390 trillion in electronic payments across Nigeria. That volume makes the Nigerian fintech ecosystem one of the highest-value targets on the African continent. And the losses reflect it: Flutterwave publicly confirmed a ₦2.9 billion loss to coordinated fraud in 2023. Interswitch reportedly suffered losses estimated at ₦30 billion in a breach that exploited weaknesses in its payment switching infrastructure. These are the numbers that made headlines. Dozens more incidents never reach the press because the companies involved settle quietly, absorb the losses, and pray regulators do not find out.
The CBN's Risk-Based Cybersecurity Framework now mandates that licensed payment service providers conduct annual penetration testing and maintain incident response plans. But compliance paperwork does not stop attackers. Understanding the specific technical mechanisms they use is what lets you build defences that actually work. Here are the seven attack patterns we see most frequently in the Nigerian ecosystem.
1. Business logic abuse: race conditions in disbursement APIs
This is the single most expensive attack pattern in Nigerian fintech. It exploits a fundamental timing flaw in how disbursement and withdrawal APIs process concurrent requests.
How it works technically: A user has ₦100,000 in their wallet. They initiate two simultaneous withdrawal requests for ₦100,000 each. Both requests arrive at the API within milliseconds of each other. The first request checks the balance: ₦100,000 is available, so it passes validation. The second request also checks the balance - but the first request has not yet deducted the funds from the database, so the balance still reads ₦100,000. Both requests pass validation. Both process. The user withdraws ₦200,000 from a ₦100,000 balance.
This is a classic Time-of-Check to Time-of-Use (TOCTOU) race condition. In more sophisticated variants, attackers use automated scripts to send dozens of concurrent requests, draining wallets or disbursement pools of millions of naira in seconds. One Nigerian payment startup lost over ₦45 million in a single weekend to this exact pattern before their monitoring systems flagged the discrepancy on Monday morning.
How testing prevents it: A penetration tester would send concurrent API requests to every financial endpoint - withdrawals, transfers, disbursements, refunds - and verify that the system correctly serializes transactions using database-level locking (SELECT FOR UPDATE), optimistic concurrency control, or idempotency keys. For a deep technical breakdown of this class of vulnerability, see our analysis of business logic flaws in Nigerian payment platforms.
2. Credential stuffing using leaked BVN databases
Nigeria has experienced multiple large-scale data breaches involving personally identifiable information - including BVN fragments, phone numbers, email addresses, and passwords. This stolen data circulates on Telegram channels and dark web marketplaces, often sold in bulk for as little as $50 for 100,000 records.
How it works technically: The attack pipeline is straightforward. Step one: an attacker purchases a database of leaked credentials from a previous Nigerian data breach - these regularly appear on dark web forums and Telegram channels specializing in Nigerian data. Step two: the attacker feeds these credentials into an automated tool that attempts to log into your fintech platform using each email-password pair. Step three: because roughly 65% of people reuse passwords across services, a significant percentage of these automated login attempts succeed. Step four: the attacker accesses the compromised accounts, changes notification settings to suppress alerts, and initiates unauthorized transfers.
A single credential stuffing campaign can attempt hundreds of thousands of login attempts per hour. Without rate limiting and account lockout policies, your login endpoint becomes an open door. For technical implementation guidance on blocking these attacks, read our guide on rate limiting for payment APIs.
How testing prevents it: A penetration tester would evaluate your login endpoint's resistance to automated attacks: does it implement rate limiting? Does it trigger account lockout after failed attempts? Does it detect and block credential stuffing patterns (multiple accounts targeted from the same IP range in rapid succession)? Does it enforce MFA that cannot be bypassed?
3. SIM swap, OTP interception, and account takeover
This attack pattern is devastatingly effective in Nigeria because it exploits the weakest link in most fintech authentication chains: SMS-based One-Time Passwords (OTPs) sent to a mobile number that the attacker has already hijacked.
How it works, step by step:
- Step 1 - Social engineering the telecom: The attacker visits a telecom retail outlet or calls customer service, posing as the victim. Using personal data obtained from previous breaches (name, date of birth, address, sometimes even NIN), they convince the telecom staff to port the victim's phone number to a new SIM card. In some documented cases, telecom staff are directly bribed - ₦5,000 to ₦20,000 per swap.
- Step 2 - Number control: The victim's original SIM goes dead. All calls and SMS messages - including OTPs - now route to the attacker's device. The victim typically notices within minutes to hours, but by then the damage is done.
- Step 3 - OTP interception: The attacker initiates a password reset or login on the fintech platform. The SMS OTP is sent to the phone number on file - which the attacker now controls. They enter the OTP, gain full access to the account.
- Step 4 - Account drain: The attacker changes the account's linked email address and phone number to their own, transfers all available funds to mule accounts, and disappears. Average time from SIM swap to account drain: under 30 minutes.
NCC data indicates that SIM swap fraud complaints increased by over 400% between 2020 and 2024. For a comprehensive look at testing defences against this attack, read our dedicated analysis of SIM swap fraud defence testing.
How testing prevents it: Penetration testers evaluate whether the application uses SMS OTP as the sole second factor (vulnerable) versus authenticator apps or hardware tokens (resistant). They test whether critical actions like password resets and beneficiary changes require additional verification steps beyond a single OTP. They verify that the platform detects SIM change events via network APIs where available.
How many of these attack patterns would succeed against your current infrastructure?
Find Out With a Pentest4. Insider threats at agent banking networks
Agent banking is the backbone of financial inclusion in Nigeria, with over 1.4 million registered agents processing billions in daily transactions. But agent networks are also the least-controlled attack surface in most fintech architectures. The agents are not your employees - they are independent operators with access to your transaction systems.
How it works technically: Rogue agents manipulate float balances through unauthorized reversals. Here is the pattern: an agent processes a legitimate customer deposit of ₦50,000. The funds are credited to the customer's account. The agent then initiates a reversal on the transaction, claiming it was an error. The reversal returns the ₦50,000 to the agent's float - but the customer's account is not debited because the reversal logic and the credit logic are handled by different services that are not properly reconciled in real time. The agent pockets the ₦50,000. Repeat this 20 times a day across a network of colluding agents, and losses compound to millions monthly.
In other variants, agents exploit batch processing delays to process withdrawals against float that has already been committed elsewhere, or they create phantom customer accounts to receive and then extract funds. Insider threats at Nigerian financial institutions grew by 92% recently, correlating with economic pressure on low-wage workers in the agency banking ecosystem.
How testing prevents it: A penetration tester with access to the agent portal would test for reversal abuse, float manipulation, and reconciliation gaps. They would verify that maker-checker controls require a second authorized party to approve reversals above a threshold, and that real-time reconciliation catches discrepancies before they can be exploited at scale.
5. API parameter tampering to modify transaction amounts
This attack exploits the assumption that client-side validation is sufficient. If your payment API accepts a transaction amount as a parameter in the request body and your server does not independently validate that amount against the originating order, an attacker can modify it in transit.
How it works technically: A customer initiates a payment of ₦50,000 for a product. The frontend application sends a POST request to your payment API with the amount field set to 50000. The attacker intercepts this request using a proxy tool and changes the amount field to 500 - or even to a negative number like -50000. If your server trusts the client-submitted amount without verifying it against the original order record in your database, the payment processes for ₦500 instead of ₦50,000 - or worse, a negative amount triggers a refund to the attacker.
This is a Broken Object-Level Authorization (BOLA) pattern combined with insufficient input validation. We have seen Nigerian e-commerce platforms lose millions to this attack because their payment integration passed the amount directly from the frontend to the payment gateway without server-side verification against the order's stored price.
How testing prevents it: A penetration tester would systematically modify every parameter in every financial API request - amounts, currency codes, recipient accounts, fee fields - and verify that the server validates each one independently against its canonical source of truth. This is core API security testing that automated scanners cannot perform because they do not understand business logic.
6. Webhook replay attacks to fake payment confirmations
Payment gateways like Paystack, Flutterwave, and Monnify notify your application of successful payments via webhook callbacks. If your application does not properly validate these webhooks, an attacker can replay a captured webhook payload to trick your system into marking unpaid orders as paid.
How it works technically: The attacker makes one legitimate small payment (say ₦100) and captures the webhook payload that your payment gateway sends to your server. This payload contains transaction details including a reference ID, amount, and status. The attacker then replays this exact payload - or a modified version with a higher amount and different order reference - against your webhook endpoint. If your server does not verify the webhook's signature against the payment gateway's secret key, does not check whether this transaction reference has already been processed, and does not independently confirm the payment status with the gateway's API, the replayed webhook is accepted as a genuine payment confirmation.
The result: the attacker receives goods or services worth ₦500,000 by replaying a ₦100 webhook payload. We have documented cases where Nigerian e-commerce and lending platforms processed millions in fake confirmations through this exact mechanism. For implementation guidance on securing webhooks, see our technical guide on webhook security for payment platforms.
How testing prevents it: A penetration tester would capture legitimate webhook payloads, replay them, modify their contents (amount, reference, status), and verify that the application rejects invalid signatures, prevents duplicate processing, and independently confirms transaction status with the payment gateway's verification API.
7. Session hijacking via public Wi-Fi
Lagos, Abuja, and Port Harcourt co-working spaces, hotel lobbies, and airport lounges are hunting grounds for session hijacking. When your fintech's internal admin tools or customer-facing application transmit session tokens over unencrypted connections or fail to implement proper session security, attackers on the same network can intercept and reuse those tokens.
How it works technically: The attacker sets up a rogue Wi-Fi access point with a convincing name ("WeWork-Guest" or "Radisson-Free-WiFi") or passively monitors traffic on a legitimate shared network. When a fintech employee or customer connects and accesses your application, the attacker captures their session token or JWT from the network traffic. If the token does not include IP binding, device fingerprinting, or short expiry, the attacker can use it from their own device to impersonate the legitimate user.
For admin sessions, this is catastrophic - the attacker inherits whatever permissions the employee has, potentially including access to customer data, transaction controls, and system configuration. See our analysis of JWT token security mistakes for the specific implementation flaws that make this possible.
How testing prevents it: A penetration tester would evaluate your session management implementation: are tokens transmitted exclusively over HTTPS? Do they expire within a reasonable timeframe? Are they invalidated on logout? Is there protection against concurrent sessions from different IP addresses? Can a captured token be reused from a different device? These checks form a core part of any authentication security review.
Every attack here exploits a testable weakness
None of these seven attack patterns require zero-day exploits or nation-state resources. They exploit race conditions, missing validations, weak authentication factors, and business logic assumptions. Every single one is detectable and preventable through thorough penetration testing that goes beyond automated scanning. The ₦2.9 billion Flutterwave loss, the ₦30 billion Interswitch incident, the ongoing SIM swap epidemic - all of these had specific, testable preconditions that a competent security review would have flagged.
What you should do now
Map your exposure against these seven patterns. Start with the highest-impact areas: your disbursement and withdrawal APIs (race conditions), your login endpoint (credential stuffing), your webhook handlers (replay attacks), and your session management (token security). If you have agent banking operations, audit the reversal and reconciliation logic.
Then test them. Not with an automated scanner - with engineers who understand payment flows, Nigerian telecom infrastructure, and the business logic of financial applications. For a transparent look at what professional testing looks like and what it costs, see our pentest process walkthrough and pricing guide.
Want to know which of these attack patterns your platform is currently vulnerable to?
Get a Security AssessmentFrequently asked questions
What is the most common way hackers steal money from Nigerian fintechs?
Business logic abuse - particularly race conditions in disbursement and withdrawal APIs - is the most common and most damaging attack vector. Unlike technical exploits that require specialized skills, business logic flaws can often be exploited by anyone with a basic understanding of how the API works and the ability to send concurrent requests.
How much money do Nigerian fintechs lose to cyberattacks annually?
Documented losses run into tens of billions of naira annually. Flutterwave disclosed a ₦2.9 billion loss in 2023. NIBSS data shows electronic fraud losses exceeding ₦18 billion in recent years. The true figure is likely much higher, as many fintechs do not publicly disclose breaches to avoid reputational damage and regulatory scrutiny.
Can penetration testing prevent these types of attacks?
Yes. Every attack pattern described in this article has specific, testable indicators. A thorough penetration test would identify race conditions in disbursement APIs, test for BOLA/IDOR vulnerabilities, verify webhook signature validation, and assess session management controls. The key is testing business logic, not just running automated scanners.
How do SIM swap attacks work against fintech customers in Nigeria?
Attackers social-engineer telecom staff (or bribe them directly) to port a victim's phone number to a new SIM card. Once they control the number, they intercept SMS OTPs sent by the fintech during login or transaction authorization. With the OTP, they complete account takeover and drain the wallet. This is why SMS-based OTP alone is not a secure second factor.
Related reading
Blog: 12 signs your backend is compromised · Business logic flaws in payment platforms · Webhook security for payment platforms · Rate limiting for payment APIs
Guides: Breach risk assessment for Nigeria · OWASP for fintechs · Penetration testing pricing
Services: Penetration testing · API security · Payment gateway security