Fintech & Banking App Development

The Flows a Banking App Lives or Dies On

Most of the risk in a banking app sits in four or five flows. They are also the flows where a user decides whether to trust the app, so the security work and the product work have to land in the same screens.

• Registration and KYC: identity and document capture, the hand-off to your verification vendor’s SDK, and every state in between: pending review, more documents needed, rejected, approved. Personal data collected here stays out of logs, analytics and the app-switcher snapshot.
• Account linking: connecting an external account through an aggregator or the bank’s own API, with the user told plainly what is shared. Credentials for the other institution never touch your servers or the device’s storage.
• Payments and transfers: amount entry, payee selection, review and confirmation, with each submission carrying an idempotency key so a retry on a bad connection cannot send the money twice. New payees and transfers above a threshold trigger step-up.
• Sign-in and session: passkeys where the platform supports them, biometrics for return visits, short-lived tokens, auto-lock after a few minutes of inactivity, and a list of active devices the user can sign out from.

How Security Is Handled

I map the work to the OWASP MASVS control groups (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY), because that is the standard bank security reviewers and pen testers already use. Agreeing the MAS testing profile at the start means the review measures the app against a target both sides wrote down.

• Storage: refresh tokens and keys in the Keychain with a ThisDeviceOnly accessibility class or behind an Android Keystore key; access tokens in memory only; nothing sensitive in UserDefaults, SharedPreferences, caches or backups.
• Network: TLS everywhere with no App Transport Security exceptions, and certificate pinning on the public key with a backup pin and a rotation plan, so a routine certificate renewal does not become an outage.
• Authorization on the server: every decision about who can see an account or move money is made by the API. Jailbreak and root detection add friction and send a risk signal to the server; they never stand in for that check.
• Kill switches: remote feature flags, a server-controlled minimum build, and session revocation for one user or all of them, tested before launch.

The client side, control by control, is in the mobile banking security checklist. The server half, mapped to the OWASP API Top 10, is in the Laravel API security checklist, and the token model choice is in Laravel Sanctum vs Passport for mobile apps. Sign-in itself, from passkeys to step-up and recovery, has its own guide: secure authentication best practices for fintech apps.

The Backend Side

A hardened app in front of an API that trusts the client is still an open attack path, so I usually build or review both. On a Laravel backend that means per-device Sanctum tokens with short expiry and rotation, policies on every account and transaction route, rate limits on sign-in and transfer endpoints, idempotent transfer handling, and audit logs that record the event without the account number. Versioned routes keep older app builds working while a forced-update floor retires the ones that should not be running.

The per-device token handling is open source as laravel-device-tokens: one Sanctum token per device, with sign-out per device or everywhere. The rest of the API work is covered under backend API development.

How an Engagement Runs

1. Scope and threat model: which flows are in the first release, which vendors they depend on, which MASVS groups and testing profile apply, and who runs the security review.
2. Flow design with the server decisions marked: every screen that moves money or changes identity gets the server check written next to it, so the API and the app are built to the same contract.
3. Build in phases: storage, network and session controls go in with the first flow, rather than being added before the review. Each phase ships to TestFlight and an internal Play track.
4. Internal review against MASTG: static checks on the release build and dynamic checks on a test device, recorded per control, before the bank’s review or an external pen test.
5. Release and handover: kill switches tested, the incident runbook written, and either a clean handover to your team or a standing arrangement to keep releasing.

Work is billed at my contract rate of $120–$180/hr, or quoted as a fixed amount per phase once the scope is agreed. As a rough guide, a focused MVP takes four to eight weeks of build; the timelines of the sponsor bank, the KYC vendor and the review itself sit on top of that, and are usually outside either of our control.

Audits of Existing Banking Apps

If the app is already in the store, I usually start with a mobile architecture audit. For a banking app the security pass runs the checklist above against your release build: what ends up in the Keychain, Keystore, files, logs and the app-switcher snapshot, how pinning and token refresh behave, whether biometrics gate a secret or a boolean, and what a jailbroken device can reach. You get findings by severity and a prioritised fix plan your own team can work from, whether or not I do the fixes.