Banking app development is mostly not differentiated work. Roughly four fifths of a banking app is table stakes defined by regulation rather than product strategy, and it is the same at every bank. The budget question is not how to build one, but which parts you should be building at all.
Table of contents
- What a banking app actually contains
- The part worth building once
- What it costs, and what drives the number
- The compliance surface nobody quotes for
- What we learned deploying one framework across several banks
- Payment apps are a different problem
- How to scope a banking app build
- What goes wrong
- How Wow Labz works in banking and payments
- Frequently asked questions
Every guide on this subject walks through the same feature list and then offers a cost range wide enough to be useless. The more interesting question, and the one a bank’s product team actually argues about internally, is which parts of the app are worth their own engineering effort at all.
About Wow Labz. Wow Labz is an AI-native custom software development company based in Bengaluru, India. Since 2011 it has shipped 400+ products across 15+ years, won 30+ awards, and touched 100M+ lives, for clients including Coca-Cola, AB InBev, HDFC, Emaar and UCSF. It holds a 5.0 rating across 23 verified Clutch reviews and is ISO 27001 certified.
What a banking app actually contains
Sort the functionality into two piles before doing anything else. The split is more lopsided than most teams expect.
The first pile is commodity: authentication and device binding, KYC and onboarding, balances and statements, transfers and beneficiaries, card controls, notifications and consent, dispute raising, accessibility, audit logging, fraud signals and step-up challenges. Every bank needs all of it, and it looks broadly the same everywhere because regulation rather than product strategy defines most of it.
The second pile is where a bank competes: segment-specific journeys, proprietary credit and pricing logic, partner and ecosystem offers, advice and money management, and the brand and service experience around it.
None of the first pile wins a customer. All of it loses one if it is wrong, slow or unavailable. And that asymmetry is exactly why it absorbs budget disproportionately, because getting it wrong is visible and getting it right is invisible.
The part worth building once
If four fifths of the app is the same at every bank, rebuilding it per bank, or per programme, is a choice worth examining rather than an inevitability.
The framework approach separates the commodity layer from the bank-specific layer: a shared, certified, maintained core carrying authentication, transaction services, card controls and audit, with configuration and extension points where a bank differs. The commodity layer gets built and hardened once. The differentiating fifth is where the bank’s own team and budget go.
The practical argument for it is not engineering elegance. It is that a bank building all of the commodity column from scratch has usually spent the budget, the calendar and the organisational appetite before reaching the part customers would actually notice. Teams end up shipping a competent, undifferentiated app and calling the programme complete.
The reframe. The question is not how much a banking app costs to build. It is how much of it you should be building at all, and whether the money is going to the fifth that makes any difference to a customer.
What it costs, and what drives the number
Published ranges for banking app development span an order of magnitude and are close to meaningless, because they mix a small credit union’s mobile app with a tier-one bank’s multi-year platform. What is more useful is knowing what moves the figure.
- The state of the core banking integration. A bank with modern APIs over its core is a different project from one integrating against a mainframe through a middleware layer built in 2009. This single factor can double an estimate.
- How much of the commodity layer you build yourself. Rebuilding what already exists in a framework or a platform is the largest avoidable cost in the category.
- The compliance and certification surface. Certification, assessment and audit are real work on calendars you do not control. Covered in the next section.
- Number of products and jurisdictions. Products, currencies, languages and regulators multiply the testing matrix rather than adding to it.
- Internal stakeholder count. A bank is not a startup. Risk, compliance, security, legal and brand all have approval rights, and the coordination cost is a real line item even though it never appears as one.
- Ongoing ownership. Banking apps are maintained under obligation, not discretion. Budget annually for re-certification, patching, regulatory change and OS updates.
The compliance surface nobody quotes for
This is the difference between a banking app and an ordinary consumer app, and it explains most of the timeline gap between what a bank expects and what it experiences.
Some obligations arrive before you ship: security assessment and penetration testing, card scheme and payment network certification where relevant, regulator notification or approval depending on jurisdiction, and internal risk, audit and model governance sign-off.
Others shape the architecture and cannot be added afterwards: data residency and cross-border restrictions, an immutable audit trail on every material action, strong customer authentication rules, and retention, deletion and customer data rights.
And some are permanent: re-certification when anything material changes, incident reporting within regulated timeframes, accessibility conformance maintained over time, and vulnerability response obligations.
The scheduling consequence is the one that catches teams out. Several of these run on calendars you do not set. An assessment slot booked late can delay a release by longer than the feature took to build, and no amount of engineering speed recovers it. Book the certification slots at kickoff rather than when the build is finished.
This is general guidance rather than legal or regulatory advice. Actual obligations vary by jurisdiction, licence type and product, and your compliance function is better placed to determine them than we are.
What we learned deploying one framework across several banks
We built a payments application framework for Wibmo, a PayU company. It is in production with HDFC Bank, IDBI Bank and Bank of Baroda.
Building something intended for multiple banks rather than one teaches you which parts are genuinely bank-specific, and the answer is less than anyone assumes going in. The commodity layer held across all three institutions. What varied was configuration, branding, product catalogue, and the integration into each bank’s own core and fraud systems.
Three observations worth generalising.
- Banks overestimate how different they are. Each bank believed its requirements in the commodity layer were distinctive. Mostly they were not. They were habits inherited from a previous system, and distinguishing a genuine requirement from an inherited one is a large part of the early work.
- The certification carries over, and that is the real saving. The framework’s value was not the code. It was that the security assessment, the certification and the hardening had already been done once, which is the expensive and slow part.
- Integration is where the per-bank cost actually lives. Every bank’s core, fraud engine and customer master is different, and that is where per-deployment effort concentrates. The app layer generalises; the integration layer does not.
Other work in the sector reinforced the same pattern. We built the JFS banking portal for Jana Finance Bank, and for Karmeq a platform operating under FINRA and SEC obligations as a broker dealer. Different regulators, different products, same structural split between a commodity core and a thin differentiating layer.
Payment apps are a different problem
Banking apps and payment apps get discussed together and they are not the same build.
| Banking app | Payment app | |
|---|---|---|
| Core dependency | Core banking system | Payment rails and processors |
| Dominant obligation | Banking licence conditions and prudential rules | Card scheme rules, PCI scope, money transmission |
| Hardest integration | Core, fraud engine, customer master | Acquirers, networks, settlement and reconciliation |
| Failure mode that matters | Availability and data accuracy | Failed and duplicate transactions, reconciliation breaks |
| Where budget goes | Commodity layer and certification | Reconciliation, exception handling, dispute flows |
The line most often underestimated in a payment app is reconciliation. Taking a payment is straightforward. Knowing with certainty which payments succeeded, which are pending, which were duplicated and which need reversing, across processors that each report differently, is where the engineering actually goes.
How to scope a banking app build
- Sort the functionality into commodity and differentiating. Do it as a written exercise with the product team before any supplier conversation. It usually reveals that the differentiating list is shorter than expected and the commodity list is longer.
- Decide what you are not building. For the commodity layer, establish what a framework or platform covers before committing to build it. Rebuilding what already exists and is already certified is the largest avoidable cost here.
- Audit the core integration honestly. Modern APIs or a mainframe behind middleware. This sets the estimate more than the feature list does.
- Book certification and assessment early. Find out the lead times and reserve the slots at kickoff. This is the most common single-cause delay in the category.
- Identify every approver by name. Risk, compliance, security, legal and brand. Get them into the architecture review while it is still a sketch rather than presenting to them at the end.
- Budget the ongoing obligations. Re-certification, regulatory change, patching and OS updates. A banking app is maintained under obligation rather than discretion.
What goes wrong
| What happens | The early warning sign |
|---|---|
| Budget exhausted before differentiation | No commodity-versus-differentiating split was ever made |
| Release delayed by months at the end | Certification slots not booked at kickoff |
| Core integration doubles the estimate | Nobody assessed the core’s API maturity before quoting |
| Compliance rework late in the build | Risk and audit scheduled as a review rather than a participant |
| Reconciliation breaks after launch | Payment exception flows treated as edge cases |
| App degrades within eighteen months | No budget line for re-certification and regulatory change |
How Wow Labz works in banking and payments
We have built a payments framework running in production at HDFC Bank, IDBI Bank and Bank of Baroda, a banking portal for Jana Finance Bank, and a platform operating under FINRA and SEC obligations for Karmeq. We are ISO 27001 certified, which in this sector is a starting condition rather than a differentiator.
What that experience produces is a specific bias: we will argue against building the commodity layer unless there is a reason, and we will ask about your core integration and your certification calendar before discussing features. Both conversations are unwelcome early and considerably cheaper than having them in month four.
For the broader sector view, our guide to AI in fintech covers where AI genuinely fits in financial services and the regulatory position on it, and the custom software development guide covers the build-or-buy decision in general terms. Our fintech app development team handles the engagements themselves.
Planning a banking or payments build?
The two questions that decide your budget are what you should not be building and how mature your core integration is. Both are answerable in two weeks. In a Discovery Sprint we sort your functionality into commodity and differentiating, assess the core integration, map the certification calendar, and give you a fixed estimate. Talk to us about your banking project and we will tell you which parts to buy or reuse.
Frequently asked questions
How do you develop a banking app?
Start by separating the functionality into commodity features, which are largely defined by regulation and are the same at every bank, and the smaller differentiating set where the bank competes. Decide what you will not build, assess how modern your core banking integration is, book certification and assessment slots at kickoff, and involve risk and compliance while the architecture is still a sketch.
How much does it cost to develop a banking app?
Published ranges span an order of magnitude and are not useful, because they mix small institutions with tier-one platforms. The figure is driven by core banking integration maturity, how much of the commodity layer you build rather than reuse, the certification surface, the number of products and jurisdictions, internal stakeholder count, and ongoing obligations. The largest avoidable cost is rebuilding commodity features that already exist and are already certified.
Which company develops mobile banking apps?
Several categories exist: large systems integrators, specialist banking software vendors, product studios, and platform providers offering a pre-certified core. The right choice depends on whether you need the commodity layer built, licensed, or extended. Ask any supplier what they would advise you not to build, and how they have handled core banking integration and certification before.
What is the difference between a banking app and a payment app?
A banking app depends on a core banking system and is shaped by licence conditions and prudential rules, with availability and data accuracy as the failures that matter. A payment app depends on payment rails and processors, is shaped by card scheme rules and PCI scope, and its hardest engineering is reconciliation: knowing with certainty which transactions succeeded, duplicated or need reversing.
How long does banking app development take?
Longer than the build itself, because several obligations run on calendars you do not control. Security assessment, certification and regulator processes have lead times, and an assessment slot booked late can delay a release by longer than the feature took to build. Book those slots at kickoff rather than when development finishes.
Should a bank build its own mobile banking app from scratch?
Rarely in full. Roughly four fifths of a banking app is commodity functionality that is the same at every institution and already exists in frameworks and platforms that carry their certification with them. Building it again consumes the budget before reaching the differentiating fifth that customers would actually notice.
