How to Build a Banking App in Nigeria

What a banking app is, and who can build one

A banking app is a mobile channel through which customers of a licensed deposit-taking institution open and operate accounts, move money, pay bills, manage cards and reach support. The institution's licence is what makes it a banking app rather than a wallet: balances shown in the app are real account balances held at the institution, and the institution carries the regulatory obligations. In Nigeria, that institution is typically one of:

• a commercial bank (deposit money bank) refreshing or replacing an existing app;
• a microfinance bank (MFB) adding a digital channel to a branch and agent network;
• a mortgage bank, finance company or cooperative-turned-MFB adding self-service;
• a licensed digital bank operating with few or no branches.

If you are not one of these, you cannot build a banking app in the strict sense; you can build a product on top of a licensed partner. As of 2026 the Central Bank of Nigeria (CBN) licenses and supervises these institutions and issues the guidelines that shape channel security and customer due diligence; confirm current requirements with the CBN or your compliance function before scoping.

Architecture: app, integration layer and core banking system

The difference between a banking app and most other apps is that the app never owns the data. The core banking system (CBS) is the source of truth for accounts, balances and postings. The app reads from it and requests actions through an integration layer, which is where most of the engineering effort goes.

Before choosing a vendor, establish what your core banking system exposes. Modern cores offer REST APIs; older ones expose SOAP services, database views or a vendor middleware product. The integration approach, and a large part of the budget, depends on this answer, so get it in writing from your core vendor first.

Core features of a banking app in Nigeria

A banking app in Nigeria needs a smaller launch set than most institutions assume, but each feature must work every time.

Nigerian customers judge a banking app on three things: whether transfers succeed quickly and show a receipt, whether failed transactions are reversed without a branch visit, and whether they can reach a human when something goes wrong. Build the receipt, the reversal status and the support channel with the same care as the transfer itself.

Security controls a Nigerian banking app must have

Security is not a feature list; it is layers that assume any single layer will fail. The CBN has issued risk-based cybersecurity frameworks for banks and other financial institutions, and your compliance team will map the app against the current version, but the engineering baseline is consistent:

• Device binding. Each customer is tied to a registered device; a new device requires re-verification (OTP to registered phone plus another factor). Device changes are logged and visible to the fraud team.
• Authentication layers. App PIN or password, biometrics (fingerprint or face, via the platform's secure hardware), OTP for higher-risk actions, and a separate transaction PIN.
• Transaction limits. Per-transaction and daily limits by KYC tier, enforced on the server, never only in the app.
• Session and transport security. Short sessions, certificate pinning, TLS everywhere, no sensitive data cached on the device.
• Tamper detection. Root and jailbreak detection, emulator detection, screenshot blocking on sensitive screens, and app integrity checks.
• Fraud monitoring. Velocity rules (many transfers in minutes, new beneficiary plus large amount), device and location anomalies, and a case queue for the fraud team.
• Audit and logging. Every request through the integration layer is logged with device, session and user identifiers, and logs are retained under a policy.
• Independent testing. Penetration testing by a third party before launch and after major releases, with findings closed before go-live.
• Secure development. Code review, dependency scanning, secrets management, and separation of test and production credentials.

Budget time for this. Security and compliance evidence commonly take as long as feature development on a banking app, and the release date is set by the sign-off, not the code freeze.

Transfers, bills and the rails behind them

The rails are what make a transfer in Lagos reach an account in Kano in seconds, and they are also where most customer complaints originate.

• Intra-bank transfers post directly on the core and should be near-instant.
• Inter-bank transfers in Nigeria run through NIBSS Instant Payment (NIP). Your app calls the bank's switch or NIP connection; the response may be success, failure or "pending", and your app must handle all three honestly. Name enquiry (showing the beneficiary's name before sending) is the single most trusted feature in Nigerian banking apps; get it right.
• Bills, airtime and data typically go through aggregators or direct biller integrations. Each has its own failure modes; design a status model (initiated, successful, failed, reversed) that support staff can see.
• Cards involve card management services from your processor: block, unblock, limit changes and virtual card issuing.
• USSD remains essential for customers on basic phones or without data. Where possible, keep app and USSD limits, beneficiaries and messaging consistent so customers can switch between them.

Design the reversal process explicitly. A failed NIP transfer that debits the customer and does not reverse within the expected window is a complaint, a regulator query and a lost customer. The app should show the status, the expected reversal timing and a way to escalate without calling the branch.

How to build a banking app: step by step

The first step is a written channel strategy signed off by the board or executive committee, because a banking app changes operations, risk and cost structure, not just marketing.

1. Define the channel strategy. Which customers, which transactions, and which branch or USSD processes the app should replace. Set targets in terms of transactions migrated, not downloads.
2. Audit the core and existing connections. Document what the core banking system exposes, how the bank connects to NIP and bill aggregators, and which vendors own each contract.
3. Engage compliance and risk early. Map the app scope against current CBN guidance on channels, cybersecurity and KYC tiers. Confirm data protection obligations under the Nigeria Data Protection Act 2023.
4. Choose the build route. In-house team, an app vendor building on your core vendor's APIs, or a white-label digital banking platform configured to your brand. The table in the cost section compares them.
5. Design the integration layer first. Authentication, limits, orchestration, logging and idempotency. This is the heart of the project and should be reviewed by security before app screens are designed.
6. Design the app with real customers. Test transfer, beneficiary and receipt flows with branch customers and agents on their own phones, including low-end Android devices.
7. Build in phases. Phase one: onboarding for existing customers, balances, transfers, airtime, bills, receipts, support. Phase two: digital account opening, cards, savings and loan products.
8. Build the admin and support console. Device resets, transaction lookup, dispute states, limit management and audit trails. Operations staff must be trained on it before launch.
9. Test against failure. Duplicate submissions, network drops mid-transfer, pending NIP responses, aggregator timeouts, and reversal flows. Automated tests plus manual test scripts signed by operations.
10. Commission penetration testing and close the findings. Assemble the compliance evidence pack.
11. Pilot with staff and a customer segment, watch support tickets daily, and fix before wider release.
12. Launch in stages and publish on the Apple App Store and Google Play under the institution's developer accounts, not a vendor's.
13. Operate. A release cadence, monitoring with alerts on failure rates, fraud rule tuning, and a maintenance agreement with defined response times.

What changes for banking apps in Nigeria

The Nigerian market shapes a banking app in ways an overseas template will not anticipate.

• Transfer success is the product. Customers compare banks by how reliably transfers go through at month-end and during network congestion. Capacity planning, queueing and clear pending states matter more than features.
• Low-end Android dominates. Many customers use budget devices with limited storage and older OS versions. Keep the app light, support the OS versions your customer base actually runs, and test on those devices.
• Data cost and connectivity. Screens should load with minimal data; transactions must survive a dropped connection without double-debiting.
• USSD is not going away. A large part of the customer base will keep using USSD for some transactions. The app should complement it, not fight it.
• Trust and fraud pressure. Social-engineering fraud is common. In-app education, confirmation prompts for new beneficiaries, and a fast card and account freeze option protect customers and reduce disputes.
• Identity infrastructure. BVN and NIN validation are central to onboarding and tiered KYC. Design for the case where a customer's records do not match and needs a branch or agent to resolve it.
• Agent networks. For microfinance banks especially, agents are where many customers deposit and withdraw. An agent mode or a companion agent app often delivers more value than consumer features.
• Regulatory reporting. Complaint handling, incident reporting and audit requirements are part of scope, not afterthoughts. Keep the compliance team in the project from the first workshop.

Example (hypothetical): a microfinance bank in Ibadan moves customers off the queue

Example (hypothetical): A microfinance bank with four branches in Ibadan and about 40,000 customers finds that most branch visits are for balance enquiries, small transfers and airtime. Its core banking system is a mid-market product with REST APIs, and it already connects to NIP through a partner. The board approves a channel project with one objective: move half of branch transactions to self-service within a year of launch. The scope chosen: an Android-first app (iOS follows six months later based on customer devices), onboarding for existing customers through BVN and OTP verification, balances and history, intra-bank and NIP transfers with name enquiry, airtime and data, a short bill list, receipts shareable to WhatsApp, card block, and an in-app support chat routed to the customer care team. A companion agent mode lets agents open accounts and accept deposits with receipts. The vendor builds an integration layer on the core's APIs with server-side limits by KYC tier, device binding and a support console. Penetration testing is commissioned before pilot. A pilot with staff and 500 customers at one branch runs for six weeks; the main findings are around pending transfer status and low-end device performance, which are fixed before the wider release. Indicative planning budget for this example: ₦10,000,000–₦15,000,000 for the build, plus penetration testing, SMS costs, hosting and a maintenance retainer. The bank measures success by branch transaction volume, not downloads.

How much does it cost to build a banking app in Nigeria?

Banking apps sit at the upper end of app costs because of integration, security and compliance work. The following are indicative 2026 ranges; actual quotes vary with scope, vendor, the state of your core banking system and exchange rate. Compare two or three written quotations on identical scope.

Beyond the build, plan for:

• Penetration testing and security reviews, typically quoted separately and often in USD.
• Integration and middleware licences from your core banking vendor, which can be significant and are easy to forget.
• SMS and OTP costs, which scale with customers and transactions.
• Hosting and infrastructure, on-premise or cloud in line with your regulatory and data policies (₦150,000–₦800,000+ per year is a floor for small deployments; banking-grade hosting is higher).
• Maintenance and support, commonly 15–25% of the build cost per year, plus an on-call arrangement for incidents.
• App store accounts: Apple Developer Program (a yearly fee, historically US$99) and Google Play registration (one-time, historically US$25); verify current fees.

Exchange-rate movement affects every USD-priced component, so budget with a margin.

Mistakes to avoid

• Starting with the app design instead of the core audit. If the core cannot expose what the app needs, the project stalls after the screens are approved.
• Enforcing limits and rules in the app only. Anything enforced on the device can be bypassed. Limits, validations and authorisation belong on the server.
• Treating security testing as a final step. Findings discovered a week before launch delay launch. Test early and again before go-live.
• Vague pending states. Telling a customer "transaction failed" when the transfer is pending causes double payments and disputes. Model and display pending honestly.
• No support console. If customer care cannot see what the customer sees, every issue becomes a branch visit.
• Publishing under the vendor's developer account. The institution must own its app store listings, code repositories and credentials.
• Ignoring low-end devices. A beautiful app that crashes on a budget Android phone will earn one-star reviews from the customers you most need to migrate.
• Under-communicating during incidents. Downtime happens; silence turns it into a trust problem. Plan in-app and social notices in advance.

Conclusion

A banking app in Nigeria is an integration and security project wrapped in a mobile interface. The decisions that determine its success are made early: what the core exposes, how the integration layer enforces limits and logs actions, which security layers are non-negotiable, and how pending transfers and reversals are shown to customers. Launch with a small set of features that work every time, give operations a console they can rely on, test with real customers on real devices, and treat compliance as part of the team rather than a gate at the end. If your institution is planning a customer app and wants a technical partner to assess your core banking integration options and scope a phased build, Linestech designs and develops secure financial applications for Nigerian institutions and can help you prepare a realistic plan before you go to tender.

Frequently asked questions

Can a company without a banking licence build a banking app?

Not a banking app in the regulatory sense. It can build a product on top of a licensed bank, microfinance bank or payment service provider through their APIs, which is how most Nigerian fintech apps operate. The licensed partner holds the accounts and carries the regulated obligations. See the fintech app guide for that route.

Should a banking app be native or cross-platform?

Both are used in Nigeria. Cross-platform frameworks such as Flutter or React Native reduce cost and keep Android and iOS in step, with native modules for biometrics and security features. Fully native builds suit institutions with large in-house teams or specific security requirements. The security controls matter more than the framework.

How does a bank connect its app to its core banking system?

Through an integration layer that calls the core's APIs (REST or SOAP, or a vendor middleware product), enforces authentication and limits, and logs every request. The approach depends on what the core exposes, so the first project task is documenting the core's interfaces with the core vendor.

Do we need USSD if we have an app?

Yes, in most cases. USSD serves customers on basic phones and those without data, and it serves as a fallback when the app or network is unavailable. Institutions typically keep both and align limits, beneficiaries and messaging across them.

How long does it take to build a banking app in Nigeria?

A lean microfinance bank app on a modern core typically takes six to nine months from scope to public launch, including integration, security testing and pilot. Full digital banking apps or projects on older cores can take twelve months or more. Compliance evidence and vendor dependencies drive the timeline more than coding.

Who owns the app code and the store listings?

The institution should. Contracts should state that source code, repositories, designs, credentials and app store accounts belong to the bank, with the vendor granted access to work on them. Verify this before signing, and see the article on app development contracts for what else to include.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Act 2023 — NDPC
• Central Bank of Nigeria (CBN)
• Apple Developer Program
• OWASP Top 10