Mobile FinTech Apps
Native & cross-platform fintech apps
We design and build mobile banking, payments and wealth apps that clear store review and audit.
Why teams bring us in
The same three problems show up in most mobile briefs we are handed.
The app cannot see the core
A mobile team ships a tidy account screen, then discovers the core banking system exposes a nightly batch and nothing else. We build the integration layer alongside the app, caching what has to be cached and marking values that came from a stale read, so support stops fielding calls about a balance nobody can explain.
Onboarding still ends at a branch
Signup looks finished until the compliance sign-off arrives and a chunk of applicants get routed to a branch visit. We wire document capture, liveness and sanctions screening into the same decision path the back office already accepts, then instrument each drop-off point so the abandonment argument runs on data rather than opinion.
Release keeps slipping in review
A build waits in App Review because the reviewer cannot get past login, or because account deletion is missing from the app. We handle submission with demo credentials, reviewer notes and the privacy declarations, and we keep a rollback path ready so a bad build does not become a bad month.
Experience and onboarding
The parts a customer touches decide whether the rest of the programme gets credit.
Onboarding and identity verification
Account opening runs as a flow with a resume point, so a customer who abandons at the selfie step returns to that step instead of the start. Document capture, liveness and device signals feed the same KYC provider and rules the branch and back office already use. Edge cases get designed too, including manual review, expired documents and applicants who cannot pass the automated path.
The everyday account experience
Balance, transactions and card controls are the screens people open twice a day, so they carry the load. We keep the transaction list fast with pagination and local caching, show pending against posted clearly, and reconcile against the ledger on refresh. Search, statements, standing orders and card freeze sit where a customer expects them rather than three taps deep in a menu.
Accessibility and localisation
Financial apps get used by people with low vision, tremor and old devices, and a screen reader that reads a balance as a bare number is a support ticket. We test with VoiceOver and TalkBack, respect dynamic type, and hold contrast to WCAG AA. Currency, date and number formats come from locale data, and right-to-left layouts are checked on device before launch.
App engineering
Platform choice, security work and payment plumbing get decided together, because each one constrains the others.
Native iOS and Android
Swift and Kotlin earn their keep when the app leans on platform features, including push provisioning for cards, Apple Wallet and Google Wallet, widgets, App Intents and the newer biometric APIs. We build with SwiftUI or UIKit and Jetpack Compose, keep the architecture testable, and share the domain contract across both teams so the two apps behave the same way under a slow network.
Cross-platform with React Native or Flutter
One codebase makes sense when the roadmap is wide and the team is small, and it stops making sense when a wallet feature needs a rewrite per platform anyway. We map that boundary early, then build the shared app with native modules where the platform demands them. Typed API clients, a single design system and CI for both stores keep the saving from evaporating.
Secure storage and biometric auth
Session tokens belong in Keychain and Keystore with hardware backing, since a rooted device reads shared preferences without much effort. We put Face ID and Android BiometricPrompt in front of step-up actions, pin certificates against the API, and run jailbreak and root detection with a documented response. Re-auth timing, device binding and fallback to passcode get agreed with your security team, then tested.
Payment and wallet flows
Card data does not have to touch your app. Hosted payment fields and tokenised SDKs from the acquirer hold PCI DSS scope down to SAQ A or SAQ A-EP in most setups, and your assessor confirms the final scope. We build transfers, scheduled payments, open banking consent and card provisioning with idempotency keys, so a retry on a dropped connection does not move money twice.
Release and operations
Mobile programmes lose weeks at release, so we treat it as engineering work rather than paperwork.
Store submission and review
App Review turnaround is usually short, and it stretches without warning when a reviewer cannot reach the account screen. We submit with working demo credentials, reviewer notes covering regulated features, privacy manifests and Data Safety declarations, plus in-app account deletion where the stores require it. Financial apps also draw questions about licensing, so we keep that paperwork attached to the submission.
Phased rollout with feature flags
Mobile gives you little rollback once a build is installed, which is why risky changes ship behind a flag. We use staged rollout on Google Play and phased release on the App Store, hold the new flow to a small cohort first, and watch crash-free sessions before widening. A kill switch turns off a broken payment path server side without a new submission.
Crash monitoring and performance budgets
A crash-free rate that drifts below target on one Android OEM is invisible until someone sets the budget and the alert. We instrument with Crashlytics or Sentry, put numbers on cold start, ANR rate and screen render time, and fail the pipeline when a build breaks them. Release notes, dSYM upload and symbolicated stacks land in the same dashboard your team watches.
How we work
A fintech app has two review boards. Designing for one of them is how releases slip.
Presales engineering
We establish the constraints first: which regulations apply, what the identity story is, and whether native or cross-platform actually serves the product. That choice is made on evidence, not preference.
Security in the increment
Certificate handling, secure storage and biometric gates are built with the feature, not added in a hardening sprint the week before release.
Release discipline
Store submission, staged rollout and rollback are part of the pipeline from the first build rather than the last.
One app the auditors and the stores accepted
We build wallet apps where biometric step-up, tokenised cards and offline-tolerant sync are agreed with your security team before the first screen is coded.
What you get
An app that agrees with the ledger
Balances, pending items and transaction history come from a defined contract against your core, with caching rules written down and stale reads labelled in the interface. Support stops guessing which number is right, and finance stops hearing about differences that came from a client-side workaround.
A security story you can hand to an auditor
Threat model, data-flow notes, storage decisions, pinning configuration and pen-test findings with fixes, packaged as documents rather than tribal knowledge. When the assessor asks where card data lives or how a session is bound to a device, the answer already exists in writing.
A release pipeline your team can run
Signed builds, provisioning, CI for both stores, staged rollout configuration, flag management and the submission checklist, handed over with a dry run. Your engineers ship the next version without us in the room, and the reviewer notes get updated rather than rewritten each time.
Numbers on quality instead of opinions
Crash-free session targets, cold start and ANR budgets, accessibility test results and a device matrix that reflects what your customers hold. Regressions surface in the pipeline, and the argument about a slow-feeling app turns into a chart someone can act on.
Where this works best
Some apps are worth building. We will tell you which.
Talk to the team who would build itGood fit
A regulated mobile product where security review and store review both decide whether it ships.
Not a fit
A wrapper around an existing web app, which we would say is not worth building as an app at all.
Questions
The questions that come up on the first call, answered without hedging.
Native or cross-platform for a banking app?
Both ship regulated apps today. React Native and Flutter fit a broad roadmap with one team, and they cost you native module work around wallet provisioning, some biometric edge cases and new OS features on release day. Native pays off when the app is the product and platform features carry the experience. We decide with your roadmap and hiring plan in front of us, then write the reasoning down.
Does the app put us in PCI DSS scope?
That depends on where card data goes. Hosted fields, an acquirer SDK and tokenisation keep primary account numbers out of your app and servers, which usually lands the assessment at SAQ A or SAQ A-EP. Card display, provisioning and stored card records change the picture. We map the data flows early, write the scope argument, and your QSA or acquirer confirms it.
How long does app store review take, and what gets rejected?
Apple publishes typical turnaround in days, and financial apps hit extra scrutiny more often than most categories. Common blockers include a reviewer who cannot log in, missing in-app account deletion, privacy declarations that do not match the SDKs, and unclear licensing for a regulated service. We prepare the submission package with the build and treat a rejection as a normal step with a same-week reply.
Can you work with our existing app and team?
Yes, and that is most of the work we pick up. We start with a read of the codebase, the crash data and the release process, then agree a short list of changes worth making before feature work resumes. Our engineers join your ceremonies and your repo. Where the existing architecture holds, we keep it and document why.
What does offline-tolerant mean for a banking app?
A customer on a train should still read the last known balance and queue a card freeze. We cache read models with a timestamp on screen, treat writes as idempotent commands with a local queue, and resolve conflicts against the server as the authority. Money movement stays online by design, since a queued transfer that lands hours later is worse than a clear error.
Part of Payments
Acceptance, orchestration, and settlement, engineered to stay up and keep approvals high.
Ready to make payments
a product you control?
Tell us where money gets stuck: routing, approvals, reconciliation, a PSP you've outgrown. We'll come back with the build, not a brochure.