How to build a mobile banking app: the core, the compliance floor, and the plan

Mobile banking is the rare product category where the hard part is invisible in every screenshot. The screens, balances, transfers, a card that can be frozen with a tap, are a few dozen views a competent team designs in weeks. What separates a banking app that ships from one that dies in review is everything behind the glass: the connection to a regulated ledger, the identity and onboarding machinery that satisfies know-your-customer law, the security posture that survives both penetration testers and app store review, and the operational rhythm that keeps fraud, compliance and releases running after launch.

This guide builds the topic in the order the decisions actually arrive: the three situations a banking app gets built in and how each one changes the plan, the feature baseline users now assume, the security and compliance floor with the specific controls auditors look for, the integration architecture that keeps the app team productive, a phased build plan with a realistic offshore budget, and the post-launch operations that most cost estimates quietly omit.

It sits inside a fintech cluster: the e-wallet build guide covers the lighter-regulation sibling many teams ship first, and the ZaloPay and MoMo case studies show where wallet-first strategies in Vietnam actually led.

The three situations a banking app gets built in

The first situation is the incumbent bank replacing or extending its channel. The license, the core banking system and the compliance function all exist; the problem is that the core was designed for branch tellers and batch files, not for a phone asking for a real-time balance at midnight. These projects live or die on the integration layer: the team that treats the core as an API it can call synchronously discovers latency cliffs and maintenance windows the hard way, while the team that builds a middleware with its own read models ships an app that feels instant even when the core is slow. The politics are also real: the app team needs a standing seat with the core team, because every feature eventually needs something the core does not yet expose.

The second situation is the fintech without a banking license building on a banking-as-a-service provider. The provider holds the license, runs the ledger, and exposes accounts, payments, cards and KYC as APIs; the fintech builds the brand, the experience and the customer relationship. This compresses time to market from years to months and converts a licensing project into a vendor selection, but the trade is permanent: the provider's uptime is your uptime, the provider's compliance rulings constrain your roadmap, and the per-account economics that looked negligible at a thousand users become a board topic at a million. Diligence the provider like a cofounder, because operationally that is what it becomes.

The third situation is the wallet graduating into banking, the dominant path in Southeast Asia. The product already has users, a stored-value ledger and payment flows under an e-money license; the project is upgrading the ledger, the compliance program and the capital structure to offer regulated accounts, and often the technical system is the readiest part. Teams in this situation should read the ledger they built with fresh suspicion: a wallet ledger that tolerated eventual consistency and manual reconciliation will not survive a banking audit, and the migration of live balances onto stricter rails is a project with no acceptable failure mode.

Which situation you are in decides the budget shape more than any feature choice. The bank spends on integration and change management, the fintech spends on the provider and differentiation, and the graduating wallet spends on compliance and ledger hardening. The feature backlog, the part everyone wants to discuss first, is nearly identical across all three, which is why this guide treats it as a baseline to clear rather than a strategy.

Three build situations, three different projects

Situation	Who holds the ledger	Schedule driver	Where the money goes
Incumbent bank channel	The existing core banking system	Core integration and release windows	Middleware, read models, core team coordination
Fintech on banking-as-a-service	The licensed provider	Provider onboarding and certification	Provider fees, differentiation, compliance mapping
Wallet graduating to banking	Your ledger, upgraded to bank grade	License process and ledger hardening	Compliance program, reconciliation, migration

The screens are the same. The risk, the schedule and the budget live in different places in each situation.

The feature baseline users now assume

Authentication sets the tone for the whole product and is where banking apps most often feel a decade old. The modern baseline is device binding at enrollment, the app registers a cryptographic key in the phone's secure hardware, followed by biometric unlock for daily use and a step-up ceremony, a PIN plus biometric or a fresh one-time code, for sensitive actions like adding a payee or raising limits. Passwords typed at every open, SMS codes as the only second factor, and sessions that expire mid-task are the patterns users screenshot and mock. The security section below covers the mechanics; the product point is that authentication is a feature users evaluate daily, not a compliance box.

Accounts and transactions are the most used screens in the app and the most punishing to get wrong. The balance must be real, not last night's batch: users check before paying, and a stale number that allows an overdraft destroys trust faster than any outage. Transactions need merchant names cleaned into something recognizable, instant search, and running balances; pending and posted states must be visually honest about which is which. This is the screen where the middleware read models earn their budget, because the core will not answer a paginated, filtered transaction query at phone speed, and pretending it will is the most common architecture mistake in the category.

Payments are where the money and the risk concentrate. The baseline covers internal transfers, domestic payments over the local instant rail, scheduled and recurring payments, and payee management, each wrapped in a confirmation ceremony proportional to risk: a small transfer to an existing payee confirms with one biometric, a large first payment to a new payee gets a deliberate, slow ceremony with the amount and recipient restated. QR payments are table stakes in Southeast Asian markets. Every payment flow needs an unambiguous terminal state, success, failure, or an honest in-progress with a reference number, because the support tickets that swamp new banking apps are overwhelmingly about payments that vanished into ambiguity.

The remainder of the baseline is card controls, freeze and unfreeze, limit changes, online and contactless toggles, which users rank absurdly high relative to build cost; in-app support with a secure message channel so sensitive conversations never leak to email; and notifications for every money movement, delivered within seconds, because the transaction push is both a security control and the single most retention-positive feature in the product. Beyond the baseline live the differentiators, savings pots, spending analytics, shared accounts, investments, and the correct plan builds none of them until the baseline is boringly reliable.

The launch baseline, as a checklist

• Device-bound enrollment and biometric unlockKey in secure hardware at enrollment, biometrics daily, step-up ceremony for sensitive actions.
• Real-time balances and honest transaction statesLive balance, cleaned merchant names, search, and a visually clear pending-versus-posted distinction.
• Payments with proportional confirmationInstant rail support, payee management, ceremonies scaled to risk, and no ambiguous terminal states.
• Card controlsFreeze, limits, channel toggles. Cheap to build, disproportionately valued, and a genuine security control.
• Secure in-app supportA message channel inside the authenticated session, so account conversations never move to email.
• Instant money-movement notificationsEvery debit and credit pushed within seconds. Retention feature and fraud alarm in one.

A first release that clears this list is credible. A first release that trades items here for differentiators is a support queue.

The security and compliance floor

Know-your-customer onboarding is the first regulated flow a user touches and the one that decides your acquisition economics. The modern flow captures a government identity document with on-device quality checks, runs a liveness-checked selfie match against it, screens the applicant against sanctions and politically exposed person lists, and routes uncertain cases to a human review queue with an audited decision trail. Nearly every team buys this from a specialist vendor rather than building it, and the integration work is still substantial: the drop-off curve through onboarding is the single most optimized funnel in the product, and every retry loop, unclear error and slow verification is measurable lost money.

The application security floor is specific and testable. Data encrypted in transit with certificate pinning so a compromised network cannot impersonate your API; secrets and tokens in the platform's hardware-backed keystore, never in application storage; runtime application self-protection that detects rooted and jailbroken devices, debuggers and overlay attacks and degrades gracefully rather than pretending nothing happened; obfuscation on the release build; and screen-capture suppression on sensitive views. None of this is exotic, all of it appears on the checklist your penetration testers and your regulator will both use, and each item retrofitted after launch costs a multiple of building it in.

The compliance workstream is broader than the app and must run in parallel with engineering rather than after it. Transaction monitoring rules that flag structuring and unusual patterns feed a case queue your compliance officers work; suspicious activity reporting has statutory deadlines; data residency law in many markets constrains where your databases physically live; and card programs pull the relevant systems into PCI DSS scope, which is an argument for tokenizing early and keeping raw card data out of your infrastructure entirely. The practical advice: hire or contract the compliance lead before the first sprint, because their requirements are cheaper as design inputs than as change requests.

The artifact that ties it together is the evidence trail. Auditors do not ask whether you take security seriously; they ask for the access review log, the deployment approvals, the incident timeline from the last outage, the data flow diagram, and the record of who could touch production and when. Teams that generate this evidence as a byproduct of normal engineering, immutable audit logs, change management in the deployment pipeline, access through a reviewed and logged gateway, pass audits in days. Teams that assemble evidence retroactively lose a quarter to every audit and eventually lose something worse.

Compliance vocabulary the project will use daily

KYC

Know your customer: the identity verification and screening a regulated institution must perform before opening an account.

AML monitoring

Anti money laundering: continuous transaction surveillance that flags suspicious patterns into a human-worked case queue.

PCI DSS

The card industry security standard. Any system touching raw card numbers is in scope; tokenization is how you keep that scope small.

Banking as a service

A licensed institution exposing accounts, payments, cards and KYC as APIs so unlicensed companies can offer banking products.

E-money license

The lighter license class behind wallets: stored value and payments, but not lending or interest, with lower capital requirements.

Five terms that appear in every banking build conversation, defined without the legal padding.

Architecture: the middleware is the product

The load-bearing decision in banking app architecture is refusing to couple the app to the core. Between them sits a middleware layer, sometimes called a digital banking platform when a vendor sells it, that owns three jobs: translating the core's batch-era interfaces into clean APIs, maintaining read models that answer phone-speed queries the core cannot, and orchestrating multi-step operations like payments that must survive timeouts and retries without double-spending. The app team then builds against a stable, versioned API that they control, and the core can be slow, scheduled for maintenance, or eventually replaced without the app noticing.

Read models deserve specific attention because they are where the app's perceived quality is manufactured. The middleware subscribes to core events, or polls where it must, and maintains its own query-optimized copies of balances and transactions: cleaned, indexed, paginated, and served in tens of milliseconds. The engineering discipline is honesty about staleness, the read model tracks its own lag against the core and the app renders accordingly, and reconciliation, a scheduled job proving the read models and the core still agree, with a loud alarm when they do not. Reconciliation is unglamorous and non-negotiable; it is also the control your auditors will ask about by name.

Payment orchestration is the hardest module in the middleware. A payment is a saga across the core, the instant rail, the fraud engine and the notification pipeline, and any step can time out ambiguously. The orchestrator owns idempotency keys so a retried request cannot debit twice, state machines with explicit terminal states, compensation paths for partial failures, and an operations view where a human can see any payment's exact state. Teams that model payments as simple request-response calls ship a system that works in the demo and generates irate tickets in production, because networks fail mid-payment as a matter of statistics.

On the client side the choice between native and cross-platform is less theological in banking than elsewhere. The secure hardware APIs, biometric ceremonies and runtime protections are all platform-specific whichever framework renders the screens, so a cross-platform codebase still carries substantial native modules. Strong teams ship excellent banking apps both ways; the honest criteria are the team you can hire and the depth of platform security work you are prepared to maintain, and the decision matters far less than the middleware it talks to.

Middleware discipline

Do this

• Version the app-facing APIUsers update apps slowly. Every API must serve versions of the app that are months old.
• Track and display read-model lagThe read model knows how stale it is. Render honestly rather than presenting stale as live.
• Idempotency keys on every mutationRetries are certain. A retried payment request must be recognized, not re-executed.
• Reconcile on a schedule and alarm loudlyProve the middleware and the core agree. The alarm that fires is the audit answer.

Not this

• Call the core synchronously from the app pathYou inherit its latency, maintenance windows and batch cycles in every screen.
• Treat payments as request-responseAmbiguous timeouts become double debits or vanished transfers, and support drowns.
• Let the app parse core data formatsCore migrations then require app releases, coupling the two schedules you separated.
• Skip the operations viewWhen a payment sticks mid-saga, someone must see its state without querying databases by hand.

The patterns that separate a banking backend that survives production from one that survives the demo.

The build plan: phases that front-load the risk

Phase one, roughly the first quarter of the schedule, builds the spine and deliberately ignores the screens: environments with the audit logging and access controls compliance will need, the middleware skeleton, the first working integration with the core or the banking-as-a-service sandbox, and the KYC vendor wired end to end. The exit test is unglamorous and decisive: one real test user passes onboarding, opens an account, and sees a real balance from the real backend on a phone. Teams that instead spend phase one on design systems and polished mockups discover the integration risk in phase three, which is the expensive place to discover it.

Phase two builds the baseline in vertical slices, each slice a feature complete from screen to core: transactions with search and honest states, internal transfers, then external payments over the instant rail with the full orchestration saga, then card controls and notifications. Vertical slices keep the riskiest integrations under continuous test and give compliance something real to review monthly rather than a big reveal. This phase is also when the fraud engine's rules get tuned against staged attack scenarios, because tuning them against real customers is how new banking apps end up in the news.

Phase three is hardening, and the schedule must treat it as load-bearing rather than as buffer to raid. An external penetration test with time to actually fix the findings; performance work against realistic data volumes, a test account with eight transactions proves nothing about a screen paginating eight thousand; failure drills that kill the core connection mid-payment and verify the saga recovers; the compliance evidence dry run; and the app store review cycle, which for financial apps involves extra scrutiny and documentation and reliably takes longer than teams plan. A pilot cohort, employees and friendly users with real money, runs through this phase and surfaces the ambiguity bugs no test plan writes down.

Team shape stays compact longer than most stakeholders expect: a banking baseline is two squads, one owning the middleware and integrations, one owning the apps and experience, plus the compliance lead, a security engineer at least half-time, and product and design shared across both. Roughly ten to fourteen people through the build. The instinct to accelerate by adding a third and fourth squad founders on the same rock every time: the core integration and the payment orchestrator are sequential bottlenecks, and more people around a bottleneck is more coordination, not more speed.

A ten-month first release, phase by phase

1. SpineMonths one to three

   Environments, middleware skeleton, core or provider integration, KYC end to end

   Done when A real test user onboards and sees a live balance on a phone

2. BaselineMonths three to seven

   Transactions, payments with orchestration, cards, notifications, in vertical slices

   Done when Every baseline flow demo-complete against the real backend

3. HardeningMonths seven to nine

   Pen test and fixes, performance, failure drills, evidence dry run, store review

   Done when Pilot cohort transacting real money without ambiguous states

4. LaunchMonths nine to ten

   Staged rollout by cohort, fraud rules live, on-call and case queues running

   Done when Public availability with rollback rehearsed and monitoring green

Durations for a two-squad offshore build in the banking-as-a-service situation. Core-integration builds stretch phase one and two; wallet graduations compress them.

What it costs, honestly

The build budget for a credible first release runs roughly 120,000 to 350,000 dollars with an offshore team, and the previous section's chart shows why the range is wide: the ledger situation, not the feature list, is the variable. Within any situation, the estimate discipline that works is bottom-up by workstream, middleware and integrations, KYC and onboarding, payments, apps, security and compliance evidence, with the integration workstream given the widest uncertainty band, because it depends on systems and teams outside your control. Estimates built top-down from screen counts land at a third of reality with distressing consistency.

The recurring costs start before launch and never stop. The KYC vendor charges per verification, typically one to three dollars, which quietly couples your acquisition cost to your funnel quality. A banking-as-a-service provider charges platform fees plus per-account and per-transaction pricing that must be modeled at your year-three volume, not your launch volume, before signing. Infrastructure for a compliant, redundant, monitored stack runs one to three thousand dollars monthly at launch scale. Penetration testing recurs annually at minimum. None of these numbers is alarming alone; together they are a five-figure monthly floor the business case must carry.

The cost that surprises boards is the operating team. Fraud and compliance case queues need trained humans on a daily rhythm, two to four people even at modest scale. The release train needs engineers permanently: OS updates break biometric flows, the instant rail publishes mandatory scheme changes with deadlines, and regulators issue new requirements with the force of law, so the notion of a finished banking app is a category error. A realistic steady state for a small digital bank is a product and engineering group of eight to twelve plus the operations staff, and a budget that pretends otherwise is planning an abandonment, not a product.

Against all this stands the reason the category exists: a banking relationship is the highest-retention product in software, the deposit and interchange economics compound, and the app is the branch network you did not have to build. The cost discipline that matters is not minimizing the build but refusing to spend it on differentiators before the baseline is boring, because in banking, boring is the brand.

The numbers that shape the business case

$120k to $350k First release build Two squads, six to ten months; the ledger strategy sets the point in the range

$1 to $3 Per KYC verification Vendor pricing; funnel quality decides how many verifications a signup costs

6 to 10 months To public launch Including hardening and financial-app store review, which teams underplan

8 to 12 people Steady-state product and engineering Plus fraud and compliance operations; banking apps are never finished

Illustrative planning figures for an offshore-built digital banking product. Ranges reflect the ledger situations described above.

Launch and the operations that follow

Launch a banking app in cohorts, never all at once. A staged rollout, employees, then a waitlist tranche, then percentage ramps, keeps the blast radius of the unknown small while the fraud rules meet real adversaries and the support queue reveals which flows confuse real users. The fraud engine in particular needs this ramp: rules tuned in staging are always either too loose, and the losses arrive immediately, or too tight, and legitimate users get blocked at the exact moment they are forming their first impression. The first month's daily rhythm is reading the false-positive and false-negative queues and tuning, with someone empowered to change rules the same day.

The operational core after launch is the case queue discipline. Fraud alerts, KYC review escalations, transaction monitoring flags and suspicious activity reports each need a queue with a named owner, a service-level target, and resolution codes that feed back into rule tuning, the same exception-queue pattern that makes fleet fuel programs work, applied to money movement. Regulators evaluate exactly this: not whether your monitoring fired, but whether a human worked the alert inside the deadline and documented the disposition. A queue nobody works is, from the regulator's chair, indistinguishable from no monitoring at all.

The release train is the last discipline and the one app teams from other categories underestimate. Banking apps ship on a fixed cadence, typically every two to four weeks, because the backlog of scheme mandates, OS changes and regulatory updates arrives on external clocks that do not negotiate. Each release carries the full ceremony, regression suite across the payment sagas, staged rollout, rollback rehearsal, because a bad banking release is not a bug, it is an incident with a report. Teams that build this rhythm during the pilot phase carry it naturally; teams that launch without it learn it during their first incident, in public.

The first ninety days after launch

1. 1

   Ramp cohorts against the fraud queuesWeeks one to four

   Expand access only as fast as the false-positive and false-negative rates stay workable. The ramp schedule belongs to the risk team, not marketing.

2. 2

   Instrument the support themesWeeks two to eight

   Tag every ticket to a flow. The top three themes are your next sprint, and in every new banking app at least one is a payment state ambiguity you can fix.

3. 3

   Run the first live compliance cycleWeeks four to twelve

   File the first regulatory reports from production data, work the monitoring queues to their service levels, and fix the evidence gaps the first real cycle exposes.

4. 4

   Lock the release cadenceWeeks six to twelve

   Two consecutive on-schedule releases with rehearsed rollback. This is the muscle every future mandate and incident will use.

The operating rhythm that decides whether the launch compounds or unravels.

Frequently asked questions

When the banking build needs a team that has shipped regulated fintech, AgileTech is a trusted software house in Hanoi with payment and wallet systems in production across Southeast Asia.