Akande Simpa
Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

What automated scanners are good at

Let me be clear: automated scanners are useful tools. We use them ourselves as part of our testing methodology. Nessus identifies missing patches, outdated TLS configurations, and known CVEs in infrastructure components. Qualys maps your external attack surface and flags services running vulnerable software versions. Burp Suite's scanner detects reflected XSS, SQL injection in form inputs, and insecure HTTP headers. These are legitimate findings that need attention.

The problem is not that scanners exist. The problem is when a vendor runs a scanner, reformats the output, and sells it as a penetration test. That is a vulnerability assessment, not a penetration test. The distinction is not semantic. It determines whether your security review catches the vulnerabilities that actually threaten your business.

What scanners structurally cannot find

Scanners operate on pattern matching. They send known attack payloads to known input vectors and check responses against known vulnerability signatures. They are excellent at finding technical misconfigurations. They are structurally incapable of understanding your business logic.

Broken object-level authorisation (BOLA)

Your transfer API returns a transaction record when called with a valid ID. A scanner confirms the endpoint responds with HTTP 200. A manual tester logs in as User A, captures a transaction ID belonging to User B, replays the request, and discovers that the API returns User B's transaction data without any ownership check. The scanner sees a working endpoint. The tester sees a data breach waiting to happen. This is the single most common vulnerability class we find in Nigerian fintech applications. For a deep technical breakdown, see our article on BOLA vulnerabilities in payment APIs.

Authentication chain bypass

A lending platform requires OTP verification for loan disbursement. The scanner tests the OTP input field for injection vulnerabilities. A manual tester discovers that the disbursement endpoint does not actually validate whether the OTP step was completed. By calling the disbursement API directly with a valid session token, they skip OTP verification entirely. The scanner tested the form. The tester tested the flow. Your authentication chain has a gap that only a human would find.

Payment flow manipulation

A payment gateway processes a ₦50,000 transfer. Between initiation and confirmation, there is a window where the amount parameter can be modified client-side. A scanner does not know that the amount field at step three should match the amount confirmed at step one. A manual tester who understands payment flows will intercept the request mid-flow, modify the amount, and check whether the backend validates consistency across the entire transaction lifecycle.

Race conditions in disbursement logic

A mobile money platform processes wallet-to-wallet transfers. A manual tester sends 20 simultaneous transfer requests for the full wallet balance. If the balance check and deduction are not atomic, multiple transfers succeed, and the platform has disbursed more money than the wallet contained. No scanner tests for this because race conditions require understanding of the specific business operation being performed.

Real-world pattern

Business logic flaws account for the majority of critical findings

Across our fintech engagements, business logic vulnerabilities (BOLA, auth bypass, payment flow manipulation, race conditions) consistently account for the majority of critical and high-severity findings. These are the vulnerabilities that lead to actual financial loss. None of them appear in scanner output.

The false confidence problem

The real danger of scanner-only testing is not that it misses vulnerabilities. It is that it creates false confidence. Your team receives a report showing 12 medium-severity findings, all configuration-related, all easily fixed. Leadership concludes that the platform is secure. The CBN audit box is checked. And the critical business logic flaw in your payment API remains undiscovered until an attacker finds it.

We have seen this pattern repeatedly. A fintech runs quarterly automated scans for two years, fixes every finding diligently, and then engages us for their first manual penetration test. Within the first week, we identify authorisation bypasses that have existed since launch. The scanners never flagged them because scanners cannot flag what they cannot conceptualise.

Where scanners fit in a proper security programme

Automated scanning belongs in your CI/CD pipeline and in your continuous monitoring stack. Run DAST scanners against staging on every deploy. Use infrastructure scanners monthly to catch drift and missing patches. Feed SAST tools into your code review process. These are hygiene measures. They catch the low-hanging fruit continuously and cheaply.

But once or twice a year, before a major launch, before a fundraise, or before a regulatory audit, you need a human with fintech domain expertise to test your application the way an attacker would. That means understanding your payment flows, your authorisation model, your business rules, and probing the seams that scanners do not know exist. That is what penetration testing is.

Want to see what a manual pentest finds that your scanner missed?

Request a Manual Test

How to evaluate what you are actually buying

When a vendor offers a "penetration test," ask these questions:

If the answers are vague, you are buying a scanner report. For a comprehensive evaluation framework, see our guide on evaluating pentest companies in Nigeria. For understanding price differences, see our breakdown of cheap scans vs real penetration tests.

Related reading

Blog: Cheap scan vs real pentest · BOLA vulnerabilities in payment APIs · How a Simpa Labs pentest works

Guides: Assessment vs pentest · Tools & methodology · Security checklist

Services: Penetration testing · API security · Vulnerability assessment