How to build a mobile banking app

There is a particular kind of banking app project that goes wrong in a predictable way. It starts with a design sprint, produces something that genuinely looks better than what the bank has, and then spends eighteen months discovering what the core banking system will and will not do. By the time it ships, the design is dated and the budget conversation has become difficult.

The avoidable part is not the integration work. It is finding out about the integration work in month six.

You are not a fintech startup, and that changes everything

If you are building a wallet, a lending product or a neobank from scratch, compliance genuinely is the hard part — you are acquiring a posture you do not yet have. We wrote that version separately: how to build a fintech app covers compliance-first architecture for that reader.

A bank's position is close to the opposite. You have the licence. You have KYC, AML and transaction monitoring running. You have a security function with opinions and an audit trail going back years. Those are constraints to satisfy, not problems to solve, and the difference matters because it changes what the project is actually about.

What you have instead are three things a startup does not:

• A core banking system that predates the project, was not designed for a mobile channel, and cannot be changed quickly.
• Other channels — branch, ATM, net banking, call centre — that share that core, so changes ripple well past the app.
• Existing customers with an existing app, which makes migration a larger risk than launch.

The core decides your timeline

The first serious question is not what the app should do. It is what the core will let you ask it, how fast, and through what.

In practice a bank's integration surface is rarely one clean thing. It is usually a mix: some published REST, some older SOAP, an enterprise service bus in the middle that someone configured years ago, a few operations only available as overnight batch, and at least one capability that exists solely as a screen in a terminal emulator. Planning as though it is a modern API estate is the single most common source of slippage.

The integration layer is the single most valuable architectural decision available. It gives the app clean, versioned endpoints, absorbs the core's awkwardness in one place, and means a future core upgrade does not become an app rewrite. It is also the thing most often cut in the first budget round, on the grounds that the app could just call the core directly. It could. It will cost more later.

One thing to settle early rather than late: what happens when a call times out mid-transaction. If the app asks for a transfer and the response never arrives, did the money move? A core without idempotent operations turns that into a reconciliation problem, and reconciliation problems in a banking app become customer complaints.

Channel parity, and the trap inside it

"The app must do everything net banking does" sounds like a sensible scope. It is usually the sentence that adds a year.

Net banking accumulated a decade of features, many of them used by almost nobody. Porting all of them to a small screen is expensive and produces a worse app. The useful exercise is pulling actual usage data per feature before scoping, and being willing to say that something with forty users a month does not need a mobile equivalent in release one.

The trap runs the other way too. Because channels share the core, a change to shared logic — a new validation rule, a changed limit — affects the branch and the call centre as well. A mobile team that assumes it owns the rules will break something a teller depends on. This is the single largest cultural difference between a bank app project and a product team used to owning its whole stack.

Migration is riskier than launch

If customers already have an app, the hard day is not launch day. It is the day you ask them to move.

Three things consistently help:

• Plan for both apps to coexist. They will anyway, because a proportion of customers simply will not update. Decide for how long and what the old one does at the end of that window.
• Move cohorts, not everyone. New customers first, then the digitally active, then the rest. Each wave tells you something before it reaches the customers least able to absorb a problem.
• Make re-enrolment as close to frictionless as the security posture allows. Every additional step costs you active users, and the ones you lose are disproportionately the ones who were already marginal.

The failure mode is forcing the whole base to re-register on a single day. That converts a technical cutover into a call-centre incident, and the call centre is the channel least able to absorb one.

What the first release should contain

Balance. Transaction history. A transfer that works every time.

That is an unfashionable answer, and it is what people actually open a banking app for. Breadth in a first release almost always comes at the cost of reliability in those three, and a banking app that is occasionally wrong about a balance loses trust in a way that is very hard to earn back. Card controls, statements, service requests and the rest are better as fast follow-ups against a stable base.

Two things to schedule, not assume

Security review and penetration testing are milestones with calendar time attached, not a sign-off at the end. Book the testers before you need them, and budget for a remediation round, because there will be findings.

App store review is stricter for financial apps. Reviewers need working credentials to exercise real flows, so prepare a demo account with a funded balance and plausible transaction history, document any region-locked behaviour, and leave a buffer. A rejection two days before a launch date that marketing has already committed to is an avoidable kind of bad week.

A sequence that holds up

1. Map what the core actually exposes, and how, before design starts.
2. Stand up the integration layer and prove one real end-to-end call against a genuine test environment.
3. Pull per-feature usage from net banking; scope release one from evidence rather than parity.
4. Build balance, history and transfer properly, including the timeout and reconciliation cases.
5. Security test, remediate, test again.
6. Migrate in cohorts with both apps live.

Step one is the one that gets skipped, and it is the one that decides whether the rest of the plan is fiction.

Questions we get asked

If you are at the start of this, the most useful first week is spent on the core rather than the design — mapping what it exposes, how fast, and where the gaps are. That is where we begin every banking engagement, and on Oracle estates specifically it usually runs through OBDX.