Secure banking solutions in Nigeria

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

Building a secure banking solution in Nigeria is uniquely difficult. You are not just fighting random hackers. You are fighting highly organized, well-funded local syndicates who understand the NIBSS Instant Payment (NIP) infrastructure better than most senior developers. You are also fighting a complex regulatory landscape enforced by the Central Bank of Nigeria (CBN) and the Nigeria Data Protection Commission (NDPC).

When a Nigerian fintech startup claims they offer a "secure banking solution," they usually mean they bought an SSL certificate and use HTTPS. That is not security. Security means your business logic cannot be tricked into double-spending. Security means an insider threat cannot dump your customer BVN database. Security means when the CBN auditors arrive, you hand them a manual penetration test report that proves your transaction engine is bulletproof.

At Simpa Labs, we audit and penetration test the core banking systems that move billions of Naira daily. We know what fails. We know how the money gets stolen. Here is the blueprint for actually securing a banking product in Nigeria.

The Nigerian banking security baseline

Nigerian financial products operate under a specific regulatory framework. This framework defines the absolute minimum security requirements you must meet to avoid losing your licence. It includes the CBN Risk-Based Cybersecurity Framework, the Nigeria Data Protection Act (NDPA), and for card-processing businesses, the Payment Card Industry Data Security Standard (PCI DSS).

Understanding which requirements apply to your specific licence tier (Payment Solution Service Provider, Mobile Money Operator, Microfinance Bank) is the mandatory starting point. Ignorance of the framework is not a defence when customer funds go missing.

CBN Cybersecurity Framework requirements

The CBN Risk-Based Cybersecurity Framework applies to all CBN-regulated financial institutions. It is not a suggestion. It is a strict mandate. The key security controls it demands are aggressive, and failure to comply results in massive fines or licence suspension. The core mandates include:

• Annual penetration testing: A manual penetration test of all customer-facing systems. A 200-page automated Nessus scanner report does not count. The CBN specifically looks for manual business logic testing.
• Biannual vulnerability assessments: You must scan your infrastructure at minimum every six months. If you make high-risk changes to your payment flows, you must scan immediately.
• Incident response plan: A documented, tested policy capable of detecting and responding to active breaches within strictly defined timelines.
• Data breach reporting: You must notify the CBN Director of Banking Supervision within 24 hours of detecting a breach affecting customer financial data.
• Multi-factor authentication: Mandatory for all customer-facing services (e.g., OTP for web login) and strictly enforced for all internal administrative access (e.g., hardware keys for database admins).
• Privileged access management: Strict controls on exactly who can access production databases. Developers should never have direct write access to the live customer database.

What "secure" means for core banking operations

Compliance is just the baseline. The real work is securing the engineering architecture that moves the money. Attackers do not care about your compliance PDFs. They care about your API endpoints. Here is how you secure the core operations.

Transaction authentication

Every financial transaction should be authenticated independently of the web or mobile session. A valid session token allows a user to browse their account balance and view their history. A transaction that moves money should require absolute re-authentication. This means a transaction PIN, a biometric FaceID check, or an SMS OTP.

This is fundamentally different from just checking if the JWT token is valid. If an attacker steals a session token via Cross-Site Scripting, they can view the account. But they cannot drain the account without the transaction PIN. The specific implementation for Nigerian banking requires strict server-side validation:

// Transaction authentication flow
// Session auth is not sufficient for transactions

async function initiateTransfer(req, res) {
  const { amount, recipient, pin } = req.body;
  const userId = req.user.id; // Already authenticated via session

  // Verify transaction-level authentication separately
  const pinValid = await verifyTransactionPin(userId, pin);
  if (!pinValid) {
    await auditLog.record(userId, 'TRANSFER_PIN_FAILED', { amount, recipient });
    return res.status(403).json({ error: 'Transaction PIN incorrect' });
  }

  // Rate limit PIN attempts (3 strikes, 30-minute lockout)
  const attempts = await pinAttempts.get(userId);
  if (attempts >= 3) {
    return res.status(429).json({ error: 'Transaction PIN locked. Try again in 30 minutes.' });
  }

  // Proceed with transfer
  await transfer.execute({ userId, amount, recipient });
}

BVN and NIN data handling

The Bank Verification Number (BVN) and National Identity Number (NIN) are biometric-linked identity markers. The Nigeria Data Protection Act (NDPA) classifies this as highly sensitive personal data. If your database leaks 10,000 BVNs, the regulatory fallout will end your company. Best practice for Nigerian fintechs is aggressive data minimization:

• Store only the verification status (true/false) after confirming the identity with NIBSS or NIMC, do not store the raw BVN/NIN unless absolutely legally mandated.
• If you must store the BVN for regulatory reporting, encrypt it at rest using column-level encryption separate from your primary application database encryption key.
• Implement strict access logging on any internal admin query that returns BVN or NIN data. You must know exactly which customer support agent viewed which BVN.
• Never log BVN or NIN numbers in application logs (e.g., Datadog, AWS CloudWatch). Mask them instantly.
• Aggressively audit any third-party vendors who receive BVN or NIN data from your systems for secondary verification.

NIP transaction security

NIP (NIBSS Instant Payment) transfers are irreversible. Once the money hits the destination bank, it is gone. Attackers focus entirely on tricking your system into sending a valid NIP transfer. The controls that matter for NIP security are deeply behavioral:

• Beneficiary name display must come directly from the NIBSS name enquiry API, not from user-supplied input on the frontend.
• Enforce strict transfer velocity limits per user, per day, and per transaction. A new account should not be able to move NGN 10,000,000 in ten seconds.
• Introduce friction for new beneficiaries. If a user adds a new bank account, require a strict confirmation step and enforce a short cooling-off delay for large amounts.
• Implement device-based trust. A transfer requested from a device the user has held for two years is safer than a transfer requested from a device registered five minutes ago. Influence transfer limits based on device maturity.
• Deploy real-time fraud scoring before executing high-value NIP transfers. If the score is too high, suspend the transfer for manual administrative review.

API security for core banking integrations

If you integrate with a core banking system via API (whether a Tier-1 bank's internal API or a modern Banking-as-a-Service provider like Woodcore or Appzone), the integration credentials are the highest-value target on your entire system. If an attacker steals your BaaS API key, they own your ledger.

You cannot store these keys in plaintext environment variables. You cannot commit them to GitHub. You must use hardware-backed secret managers:

# Secure credential management for core banking API keys
# Never store in environment variables in plaintext in your codebase

# Use AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault
# Example: retrieve at runtime, not at build time

# AWS example
aws secretsmanager get-secret-value \
  --secret-id prod/core-banking/api-key \
  --query SecretString \
  --output text

# Rotate credentials:
# - On any suspected compromise
# - On any developer departure who had access
# - At minimum annually for compliance
# - Log every rotation event with timestamp and reason

NDPA data protection requirements for banking products

The Nigeria Data Protection Act (NDPA) applies to any Nigerian entity processing personal data. For fintechs, the requirements are heavily scrutinized by the Nigeria Data Protection Commission (NDPC). The specific requirements relevant to banking products include:

• Data Processing Impact Assessment (DPIA): Mandatory for the processing of financial data at scale. You must formally document the risks to customer data and how you mitigate them.
• Data retention limits: Customer data should not be retained indefinitely on active servers. You must define and enforce strict retention periods, moving old transaction data to cold storage.
• Data subject access rights: Customers can legally request a copy of their data, request correction of errors, and in specific non-regulatory cases, request deletion. Your architecture must support these queries.
• Cross-border transfer restrictions: Customer financial data must be hosted in Nigeria. Using AWS Lagos, Azure Nigeria, or local data centers like MDXi or Rack Centre is mandatory unless you obtain a specific exemption.
• Compliance Audit Return filing: You have an annual legal requirement to file an audit return proving your compliance with the NDPA. Failure to file results in public sanctions.

Building a secure banking solution in Nigeria requires a paranoid engineering culture. You must assume your network is hostile. You must assume your developers will make mistakes. You must assume attackers are actively probing your NIP integration right now. The only way to prove your controls work is to hire professionals to break them.

Related reading

Guides: CBN compliance security guide · NDPA compliance guide · Fintech security checklist

Blog: KYC and BVN data security · Nigerian fintech threat landscape 2026

Services: Penetration testing · Live fintech security review · NDPA compliance