FinTech Banking Mobile App Development
A mobile bank is an app that forgives no mistakes. Incorrectly displayed balance, a completed transfer without confirmation, session loss mid-transaction—each scenario costs user trust and potentially money. Architectural decisions here are dictated by security, not development convenience.
Authentication and Biometrics
Start with what happens on every app launch. The classic: JWT in Keychain (iOS, .whenUnlockedThisDeviceOnly) / EncryptedSharedPreferences via Android Keystore. On startup: BiometricPrompt (Android) / LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) (iOS).
Biometrics unlocks the encryption key protecting the refresh token—not the token itself. If someone steals an encrypted blob from Keychain without the private key from Secure Enclave, decryption is impossible. Essential for bank certification.
PIN as fallback: store the PIN hash in Keychain, never the PIN itself. Never transmit PIN to the server. Server authentication uses tokens; biometrics and PIN are local-only session unlocking.
Jailbreak/Root detection is mandatory for most banks. iOS: check for cydia://, mobile substrate, write access to /, successful fork(). Android: RootBeer library or SafetyNet Attestation API / Play Integrity API (current). Upon detection, the app doesn't launch or operates in restricted mode.
Transfers and Transactions
The transfer form is technically simple but UX-critical. After entering amount and recipient, show a confirmation screen with full details. The confirm button should have a 1–2 second artificial delay (prevents accidental double-tap). Require re-biometric/PIN authorization for large amounts.
Idempotency of transfers: each request includes a unique idempotency_key (UUID, generated on the client). On network loss and retry, the server returns the first result without duplicating. Critical—without idempotency, unstable internet users might send a transfer twice.
Transaction history: paginated list, cursor-based. Group by date. Search by description, amount, recipient. Detailed transaction page: all details, status, receipt as PDF (server-generated, downloaded to device).
PCI DSS and Data Protection
A mobile banking app never stores card PANs in plaintext anywhere. Even masked numbers (**** 1234) are display-only, never logged. Firebase Crashlytics and Analytics are disabled for PII collection: FirebaseCrashlytics.crashlytics().setCrashlyticsCollectionEnabled(false) until explicit consent.
Network traffic: Certificate Pinning. iOS: NSURLSession with URLSessionDelegate.urlSession(_:didReceive:completionHandler:), compare SHA256 of the certificate's public key. Android: OkHttp CertificatePinner. Protects from MITM even with compromised CAs.
Update SSL pinning during certificate rotation via OTA config updates (Firebase Remote Config or custom endpoint)—not via app store updates. Otherwise, all old app versions break once certificates expire.
Transaction Notifications
Push on every operation is standard. Requirements: delivery within seconds, not minutes. FCM with priority: high for Android, APNs with apns-priority: 10 for iOS. Critical: if push doesn't deliver (device offline), on next app open, sync unconfirmed transactions.
Rich push notification: amount, operation type, last 4 card digits. iOS: UNNotificationServiceExtension to decrypt end-to-end encrypted push payloads (banks often encrypt sensitive data).
Accounts and Cards
Main dashboard: list of accounts with balances. Card widget (physical or visual representation). Card management: lock, limits, view details (CVV only after biometrics, not stored in app memory longer than 30 seconds).
Apple Pay / Google Pay tokenization: PKAddPaymentPassViewController (iOS) / PushProvisioningActivity (Android) to add cards to Wallet. Not standard payment integration—requires special Visa/Mastercard agreement and certification. Takes months; start early.
Support Chat
In-app chat with bank staff. Stream Chat SDK or Sendbird are enterprise-ready with history, search, push on new messages. Messages encrypt in transit and store on provider servers—verify regulatory compliance.
Architecture
Native Swift (iOS) + Kotlin (Android) is preferred for fintech. Reason: maximum security control, native access to Secure Enclave, BiometricPrompt, Apple Pay provisioning. Easier to pass security audits.
Clean Architecture: Domain (Use Cases) / Data (Repository, API) / Presentation (MVVM, ViewModels). Layer testing is mandatory—unit tests on Use Cases, integration tests on Repository.
Flutter is acceptable for fintech with good Flutter developers. Limitations: flutter_secure_storage uses Keychain/Keystore through an abstraction layer that must be audited. local_auth for biometrics works correctly.
Process
Security architecture review → design → authentication and biometrics → accounts and balance → transfers with idempotency → transaction history → cards and Apple/Google Pay → push notifications → security audit → regulatory coordination → launch.
Timeline Estimates
FinTech MVP (authentication, accounts, transfers, history): 8–12 weeks. Full mobile bank with cards, Apple/Google Pay provisioning, support chat, investment module: 4–8 months. Cost determined after requirements and security scope analysis.