Why it matters
Mobile is where most retail banking and payments now happen. UPIUnified Payments Interface. NPCI's real-time system for paying from a bank account with a UPI ID, QR code or phone number, through apps on a phone. alone processed 24.51 billion transactions1Business Standard. UPI sets new record at 24.51 bn transactions in Aug, value at ₹29.82 trn. As of 31 August 2026. in August 2026, almost all of it started on a phone. The app must be fast and simple for customers, and must also hold up against fraud on a device the bank does not own, may be years old and may be compromised.
The landscape
| Approach | What it is | Typical use in Indian banking | Notes |
|---|---|---|---|
| Native Android (Kotlin) and iOS (Swift) | Separate apps written for each platform | Flagship retail banking apps | Best performance and platform features; two codebases |
| Flutter (Dart) | One codebase drawing its own interface on both platforms | New apps and journeys that must ship fast on both | Consistent look; plugins needed for some device features |
| React Native (TypeScript) | One codebase using native interface components | Apps built by teams with web skills | Large ecosystem; bridge to native code for sensitive parts |
| Kotlin Multiplatform | Shared business logic in Kotlin; native interfaces on each platform | Sharing rules and networking code while keeping native screens | Growing; interface still built twice |
| Mobile web and progressive web apps | Browser-based experiences | Low-friction journeys and onboarding | Limited device security features |
Typical uses are general patterns, not claims about named banks.
Design systems
A design system is a shared library of interface components, patterns and rules: buttons, amount fields, confirmation screens, error messages. For a bank it keeps every journey consistent and accessible, and it makes the security-critical screens, such as payment confirmation, the same everywhere so customers learn to trust them.
Device binding and app security
Device binding ties a customer’s registration to one phone, usually by verifying the SIM and registering the device, so that stolen credentials alone are not enough elsewhere. Common app protections include:
- detecting rooted or jailbroken devices and emulators;
- keeping keys in the phone’s hardware-backed keystore;
- certificate pinning, so the app talks only to the bank’s servers;
- obfuscation and runtime checks against tampering;
- blocking screen capture on sensitive screens;
- detecting overlay attacks, where malware draws a fake screen over the real one.
Authentication rules have recently changed. RBI's Authentication Mechanisms for Digital Payment Transactions Directions, 2025, issued on 25 September 2025, require at least two factors of authentication for domestic digital payments, with compliance from 1 April 2026.2The Tribune. RBI unveils new directions to strengthen digital payment security. As of 25 September 2025. For digital payments other than card-present transactions, at least one authentication factor must be dynamic, that is, unique to the transaction.3KPMG in India. RBI Authentication Mechanisms for Digital Payment Transactions Directions, 2025. As of 1 December 2025. The 2025 authentication framework encourages new authentication factors but does not require banks to stop using SMS-based OTP.4Business Standard. RBI issues Directions on Framework on Authentication Mechanisms for Digital Payment Transactions. As of 25 September 2025. For apps, this opens the way to stronger factors such as device-bound keys and biometrics, used together with a PIN.
SDKs and third-party code
Banking apps embed third-party software development kits (SDKs): payment libraries, identity verification, analytics, crash reporting. Each SDK runs with the app’s permissions and can see what the app sees. Banks therefore keep an inventory of every SDK, review what data each collects and where it sends it, and keep them updated.
App stores and updates
Banks do not control when customers update. A security fix can take weeks to reach most users unless the bank sets a minimum supported version and asks older apps to update. Changes are usually released in stages, to a small share of users first, with the ability to switch features off remotely if problems appear.
How to choose
Choose native where the app is the bank’s primary channel and needs the best performance and device security. Choose a cross-platform framework where speed across both platforms matters more and the team can still write native code for the sensitive parts. Whatever the choice, put the security-critical pieces, such as key storage, device binding and PIN entry, in well-reviewed native code.
Pitfalls
- Trusting the device. Treat every check done on the phone as advisory; confirm on the server.
- Secrets in the app package, such as APIApplication programming interface. A defined way for one system to request data or actions from another. keys, which attackers extract easily.
- Unreviewed SDKs collecting customer data.
- No forced-update path, leaving old, vulnerable versions in use for years.
- Inconsistent confirmation screens, which make fake ones easier to pass off.
Questions for a design review
- What stops stolen credentials being used on another phone?
- Which checks run on the device, and which are confirmed on the server?
- Which SDKs are in the app, and what data does each collect?
- How quickly can a security fix reach 90% of active users?
- Which authentication factors does each payment journey use, and is one of them dynamic?