Why neobanks are structurally more exposed than traditional banks
A traditional Nigerian bank has an internet banking portal, a mobile app, and a core banking system that sits behind a private network. The attack surface from the public internet to the core system is filtered through multiple network layers. A neobank has a mobile app and a cloud backend — typically a set of microservices on AWS, GCP, or Azure — with no private network boundary between the app and the core banking logic. The API that creates accounts, initiates transfers, and queries balances is the same API that is exposed to the public internet.
This architecture is not inherently less secure. But it requires every security control to be implemented at the application layer rather than relying on network isolation. When a neobank ships fast, these application-layer controls are where gaps appear first.
1. Account opening and KYC bypass
Neobanks compete on frictionless onboarding. The CBN tiered KYC framework allows Tier 1 accounts to be opened with only a phone number and BVN — no physical address verification, no face-to-face confirmation. This design decision, mandated by the regulator to drive financial inclusion, creates a known attack surface: Tier 1 account farming using valid BVNs that were leaked or purchased from data brokers.
Beyond Tier 1, we test the upgrade pathway to Tier 2 and Tier 3. The upgrade requires additional document submission and sometimes a liveness check. We test whether the liveness check can be bypassed using recorded video or a static image, whether the document verification API can be confused by borderline-quality fake documents, and whether the tier upgrade is processed asynchronously in a way that creates a window where a Tier 2 account has Tier 2 transaction limits before the verification is actually confirmed.
2. Core banking API exposure and transaction authorization
Neobank backends typically expose a set of internal microservice APIs: one for account management, one for transactions, one for KYC, and one for notifications. These services communicate with each other and sometimes with the BaaS provider's API. We look for internal service endpoints that are unintentionally exposed on the public-facing API gateway — a common misconfiguration when service-to-service communication is moved behind an API gateway without restricting public access to internal routes.
We also test the transaction authorization model in depth. The specific question is: if an attacker compromises one user's session token, which transactions can they initiate without triggering a step-up authentication requirement? For a neobank operating to CBN standards, transfers above a certain amount should require biometric or PIN confirmation. We test whether these thresholds are enforced server-side or whether they can be bypassed by calling the transfer endpoint directly without going through the authentication step-up flow.
3. BaaS integration security boundary testing
When a neobank uses Wema, Sterling, or Providus as its banking backbone, the integration is typically a REST API that the neobank's backend calls to perform actual banking operations. We audit this integration for: API key storage (is the BaaS API key stored in an environment variable, a secrets manager, or hardcoded?), the validation of callbacks from the BaaS provider (does the neobank verify that the callback is genuinely from the BaaS provider and not a spoofed request?), and the error handling on BaaS API failures (does a BaaS timeout cause the neobank to credit a wallet before confirming that the underlying bank transaction succeeded?).
4. Savings and investment product logic
Most Nigerian neobanks offer savings vaults, fixed deposits, or investment products alongside the current account. We test these products for: premature withdrawal without penalty (can the lock period be bypassed by calling an internal liquidation endpoint?), interest rate manipulation (is the interest rate computed server-side from a static configuration or can it be influenced by client-submitted parameters?), and early maturity exploitation (can a user trigger the maturity payout before the lock period expires by manipulating the maturity date in a request?).
Internal account management endpoint exposed via API gateway misconfiguration
During a penetration test of a Nigerian neobank, we discovered that the internal account status management endpoint used by the customer support team was accessible on the public API gateway. The endpoint accepted a user ID and a new account status value. Without authentication beyond a basic API key that was embedded in the support team's web dashboard JavaScript, we deactivated and reactivated test accounts, changed account tiers, and modified transaction limits. Fix priority: critical. Remediated by moving all internal support endpoints to a separate private gateway with VPN-restricted access and removing the API key from the client-side dashboard entirely.
Operating a neobank or digital microfinance bank in Nigeria? Book a security assessment before your next CBN IT Risk Assessment.
Book a Neobank PentestFrequently asked questions
What CBN regulations apply to neobank security?
Nigerian neobanks holding a Microfinance Bank licence or operating under a commercial bank's CBN licence must comply with CBN's Risk-Based Cybersecurity Framework, the CBN IT Standards Framework, and the Consumer Protection Regulations. CBN conducts annual IT Risk Assessments and expects neobanks to have documented, tested security controls including annual penetration testing.
How is neobank security testing different from testing a traditional bank?
Neobanks are entirely API-driven, mobile-first, and cloud-hosted. There are no branch systems, no mainframe integrations, and no physical security components. This concentrates the entire attack surface into the mobile app, the backend API, the cloud infrastructure, and the third-party BaaS and banking partner integrations. The attack surface is narrower but completely externally exposed.
What is the risk of neobanks built on BaaS infrastructure?
Many Nigerian neobanks use Wema, Sterling, or Providus as their banking backbone through a BaaS arrangement. The security boundary between the neobank's own code and the BaaS provider's API is where the most critical vulnerabilities appear. Misunderstanding which party is responsible for which security control creates gaps that neither the neobank nor the BaaS provider tests.
Related reading
Blog: BaaS virtual account exhaustion · CBN IT audit preparation · KYC and BVN security
Services: Penetration testing · API security