Introduction
Modern mobile banking applications must do two things: secure sensitive financial data and provide a consistent and easy experience.
This may seem like an easy balance to strike, but it can be quite challenging.
If your application has a weak login, then it is a potential security risk. If your application has a strict, demanding login that frustrates the user, they will abandon their task and look to support for help with issues related to poor user experience. Therefore, biometric user authentication, device binding, session management, secure storage methods, encryption, and re-authentication flows must work together; they should be regarded as one security system, and not discrete technical features.
For organizations developing a mobile banking application for the first time, they are not simply adding a feature such as “Face ID” or enabling fingerprint login; they are creating a security system that protects users’ accounts, provides for their compliance, and gives them confidence in using your application.
This article you’re about to read will cover the core layers of security every banking application should include and how to approach them from a product perspective, along with examples of user experience decisions that could make or break adoption.
The Importance of Security UX in Building Mobile Banking Applications
Mobile banking apps are used within a highly trusted context. Users rely on their mobile banking apps to check account balances, transfer funds, manage their debit and/or credit cards, approve payments, review transactions, and enter their personal information. Any minor confusion when using these types of applications can be perceived as significant.
For example:
- If a user attempts to log in but the process is delayed, they may be left with the impression that the mobile banking app is not functioning as expected.
- If a user suddenly receives a prompt for re-authentication, they may react with suspicion.
- A user may believe that a particular mobile banking app is blocking their device when, in fact, the user has been locked out of the bank’s system.
- Vague security messages associated with mobile banking applications may increase the number of customer service tickets, as opposed to decreasing the number of risks.
For these reasons, it is important for fintech companies to not only implement controls designed to secure their customer’s accounts, but to communicate clearly with their customers.
Good mobile banking app development combines technical security protections with a clear user journey to provide a strong security experience that answers three very specific questions for the user.
1) Why am I being asked to verify who I am?
2) What do I need to do next?
3) Is my money and personal information safe?
At Appricotsoft – where we pride ourselves on producing simple, useful, and highly innovative products – the focus of the company is on quality, innovation, and providing solutions to genuine issues as opposed to simply checking boxes.
Biometrics: Convenient, But Not a Security Strategy on Their Own
Biometric authentication is a prominent security feature of mobile banking apps that offers a convenient means of accessing accounts using Face ID, Touch ID, fingerprint unlock, and facial recognition, all of which users currently take advantage of on their phones.
However, there is one critical difference between biometric authentication and other forms of authentication. While biometric authentication verifies the identity of the person using the device by verifying their credential with the device-level biometric transaction, this does not necessarily mean that each request made to the server is also authenticated.
For example, Apple’s LocalAuthentication framework allows developers to use device-level authentication within applications without providing access to any of the user’s fingerprint or face data. The actual sensitive biometric data is stored and managed by secure platform components, which are not directly exposed to the application itself.
From a product and architecture standpoint, biometric authentication should be part of a larger multi-factor authentication solution. Biometric authentication typically works best when combined with other security measures in banking applications, including but not limited to the following:
- Strong initial account authentication
- Device binding
- Secure token storage
- Server-side session validation
- Risk-based reauthentication
- Clear fallback option
- Transaction-level confirmation for sensitive actions
Therefore, biometric authentication is not considered “completed” security; it remains a user-friendly authentication layer.
Where Biometrics Work Best
Biometrics are especially useful for frequent, low-to-medium-risk actions such as:
- Opening the app
- Checking account balances
- Viewing recent transactions
- Accessing saved beneficiaries
- Confirming app unlock after short inactivity
- Approving low-risk actions based on your risk model
They reduce friction and make the app feel modern. For many users, biometric login is faster and easier than typing a password or PIN in public.
Where Biometrics Need Extra Controls
For higher-risk banking actions, biometrics may need to be paired with additional checks. These can include transaction signing, step-up authentication, server-side risk scoring, one-time passwords, passkeys, or confirmation screens.
Examples include:
- Adding a new payee
- Changing contact information
- Resetting security settings
- Increasing transfer limits
- Sending a high-value payment
- Logging in from a new device
- Disabling biometric login
OWASP’s mobile security guidance highlights risks such as biometric authentication bypass, weak fallback flows, missing step-up authentication, and authentication material stored insecurely on the device. These are exactly the areas banking teams should treat carefully during design, development, and QA.
Connecting an Account with a Trusted Mobile Device
Device binding plays an essential role in security in mobile banking software applications. Access to your account should not just be determined through your credentials alone, but through several layers of security as well.
Simply put, device binding provides the connection between a customer’s account and a trusted mobile device after they have completed an enrollment process that secured their information. Therefore, once the customer’s account and their mobile device are configured as trusted, the application can use device-specific encryption keys, secure storage, or validation processes on behalf of the user to help mitigate unauthorized access.
An example of an effective device binding process might involve the following:
- Authentication through secure verification at initial user login,
- Backend registration of the device being bound to the user,
- Generating cryptographic keys specific to the device being bound to the user,
- If hardware-backed storage is available, the user inserts their private keys into the secure hardware-backed storage.
- Tracking by the server (backend) of the device to ensure whether it is still valid,
- A procedure for removing a device that is lost or has been compromised,
Re-enrollment based on changes in device security.
Once the user has completed the device binding process, it should seem simple for them to understand: “Is this device trusted?” or “You have linked this phone to your banking profile.”
Device Binding UX
The best UX for device binding should be transparent to the user, not overwhelming. The user does not need a complete understanding of cryptography, just that:
- Their device will be registered to access your account more securely.
- They can remove any old/unwanted devices,
- If they log in with a different device, further verification will be required; and,
- If they have lost or had their device stolen, they must re-enroll.
A good mobile banking app should include a “Trusted devices” or “Devices and sessions” screen where users can review active devices, see approximate login history, and revoke access. This builds confidence and reduces panic when something looks unfamiliar.
The Importance of Session Management: How to Secure and Thank Your Users Without Hassling Them
Security and usability come together at session management.
When your sessions are too long, if a user accesses an application through an unsecured mobile device (for example, if they lose it, share it, or forget to lock it), then there can be sensitive data exposed through the application. If sessions are too short, then logging back in creates user frustration, decreases user engagement, and also results in a high number of logins.
Session management for mobile banking applications needs to have risk-based session management to meet the needs of users.
Some examples of risk-based session management include:
- A short inactivity timeout for sensitive screens
- Longer remembered device sessions for trusted devices
- A background lock when the application is minimized
- Re-authenticating a user after a set amount of time of inactivity
- Re-authenticating a user for a sensitive transaction
- Revoking user sessions on the server side
Terminating user sessions if a user resets their password or exhibits suspicious behaviour.
There should not be a one-size-fits-all solution, as viewing a balance versus sending a large transfer will require different session requirements.
Risk-Based Re-Authentication
Risk-based re-authentication allows application users to authenticate again based on the context in which they log into the application.
For instance, when a user logs into the application 5 minutes after they previously checked their balance, they will only be required to perform a biometric unlock. Conversely, if a user is adding a new recipient, changing their number, or sending a large amount of money, they will likely need to perform biometric authentication again.
This improves both security and UX. Instead of annoying users with constant prompts, the app creates meaningful security checkpoints.
NIST’s digital identity guidelines cover authentication and lifecycle management for users interacting with systems over networks, which is a useful context for teams designing authentication policies and re-authentication rules.
Jailbreak and Root Detection: Useful Signal, Not a Silver Bullet
Detecting jailbroken iOS devices and rooted Android devices is just one piece of a large risk signal puzzle. Jailbreaking or rooting gives attackers more control of an iOS or Android device’s runtime environment, as well as app memory, local storage, network traffic, and/or the way an app behaves when it is being used by the authorized user.
Jailbreak/root detection can be useful to identify risky environments, but should never be considered an absolute answer when making risk-based decisions. An advanced attacker could hide either jailbreak/ root status, and false positives can certainly occur.
The Most Practical Approach to Using Jailbreak/Root Detection is to Combine the Jailbreak/Root Signal with other risk signals, such as:
- Detecting Debugging/Instrumentation
- Detecting Tampering with the App
- Detecting Emulators
- Detecting Suspicious Network Configurations
- Detecting Certificate Trust Changes
- Employing Device Integrity APIs as Appropriate
- Performing Anomaly Detection on Backend Systems
- Monitoring Transactional Risk
According to OWASP’s guidelines regarding mobile security, while mobile security issues such as root/jailbreak detection and runtime resiliency continue to be a part of OWASP’s mobile security recommendations, OWASP emphasizes that mobile security should use a “layering” approach to mobile application security instead of relying on a single line of defense.
So What Should Happen When A Device Appears To Be Compromised?
There is a security decision and product decision element to this question as well. In response, possible options could include:
- Warn the user and limit their ability to perform sensitive transactions.
- Block login attempt entirely, sending notification to the user with an explanation of why the login was blocked.
- Provide view-only access to the app until the device has been verified as secure.
- Require some form of additional verification for the user.
- Direct users to contact the support team for help if their device cannot be verified as secure.
- Log the signal that the device is compromised.
For banking products, blocking all access may be appropriate in some cases. But the message must be clear and calm. Avoid vague errors like “Security issue detected.” Instead, explain what happened in plain language:
“Your device appears to have security settings that may put your banking data at risk. For your protection, payments and profile changes are currently unavailable on this device.”
The exact policy depends on your risk appetite, regulatory environment, and customer support model.
Rest Encryption and Transit Encryption
All banking Bit Wallets require Encryption.
When it comes to encryption, two elements are particularly important: ‘Rest Encryption’ and ‘Transit Encryption’.
Rest Encryption
‘Rest encryption’ protects sensitive information that is on the target device (Mobile) or on their backend systems. On the mobile and in general, you should avoid saving sensitive data; if you need to save sensitive data on the device, the data should be reduced to the least amount for storage, as well as being ‘encrypted’ and secured using the platform’s security methodology.
When saving sensitive data locally to a mobile device,e the following “local” data would qualify as sensitive:
- Access Tokens
- Refresh Tokens
- Account Identifiers
- Cached Balances
- User Profiles
- App Configurations
- Transaction Demographics
In general, save your secrets in a secure storage area as provided by the platform. Do not save them in plain app preferences or as general local files. Android has a ‘Key Store’ designed to protect those cryptographic key materials and also assert constraints on the use of those keys (for example, must authenticate user before the completion of a key action).
iOS typically uses KeyChain and system authentication to provide security for banking apps.
Transit Encryption
Transit encryption protects information that is being transferred between the mobile app and the backend systems. This typically means implementing TLS with strong validation of the certificate, as well as implementing API security with a great deal of attention.
When designing your APIs and mobile apps for banking applications, you should consider:
- Only allow HTTPS communications.
- Disallow cleartext communications.
- Ensure all certificates are validated appropriately.
- Do not use sensitive data within the URL.
- Secure your APIs with the most robust security possible.
OWASP’s mobile testing guidance includes checks for data encryption on the network, endpoint identity verification, cleartext traffic, insecure TLS protocols, and certificate validation issues.
Encryption should not be treated as a late-stage QA item. It should be designed into the architecture from the start.
Secure Storage: How to Organize What Can Be Stored On Your Device
One of the biggest problems with designing Fintech and banking applications is making sure that you don’t collect too much data that is stored locally.
Accessing local storage allows your app to create a better experience while offline and improves the speed of your application. Adding additional local storage will create additional risk. Here is a framework of questions that can help determine if data should be kept on a customer’s mobile device:
- Do you need to keep this data on the device?
- How sensitive is this data if it gets compromised?
- How long will you keep data on the device?
- Will you be able to regenerate this data from the back end of your application?
- Should you be wiping data from the device when a user logs out?
- Do you need to back up this data to the cloud?
- Will the customer be required to use their biometric or device passcode to access the data?
To create a secure storage strategy, segregate your data into categories.
Do Not Store Locally Unless Absolutely Necessary
Avoid storing:
- Simple passwords
- Complete primary account numbers
- CVV numbers
- Complete authentication secrets
- Unencrypted tokens
- Any sensitive documents
- Private keys outside of a secure storage facility
Any personal information that is not required for the proper functioning of your application
Data is stored safely and securely
Some types of data may be stored locally if storing the data enhances the user experience or increases performance; however, stored securely with appropriate controls:
- Session tokens
- Device keys
- User preference settings
- Masked Account Number Information
- Transaction Cache Limited in Nature
- App Lock Setting
- Not trusted Device Identifiers
User experience related to local data storage
Your users should have the ability to manage their data. There are some examples of what would help your user manage their data:
- Option to Remove Device
- Clear Local Data Upon Logout
- Wipe Data After Too Many Failed Login Attempts.
Security should feel manageable, not mysterious.
Re-authentication UX: How to Prompt Users Appropriately
The area of re-authentication is incredibly sensitive in banking applications. If you require your users to re-authenticate too frequently, they will likely become frustrated with the application. Conversely, if you do not require re-authentication frequently enough, the application can become less secure and put users at risk.
A contextual re-authentication approach will be the best method to employ.
Low-Risk Actions
You typically will not need to ask users to re-authenticate if they have an active session. Common examples of low-risk actions are:
- Viewing the Dashboard
- Checking Balances
- Reading Educational Content
- Viewing non-sensitive Settings
- Browsing Offers
Medium Risk Action
Depending on how long the user’s session has gone on, you may require the user to biometrically unlock or enter their app PIN before allowing them to perform medium-risk actions such as:
- Viewing transaction details
- Accessing Statements
- Changing Notifications
- Viewing Saved Recipients
High-Risk Action
You should prompt users to re-authenticate regardless of how long their session has lasted for high-risk actions. Some examples of high-risk actions are:
- Sending Money
- Adding a New Recipient
- Changing User ID and App PIN
- Updating User Phone Number or Email Address
- Changing User’s Biometric Settings
- View a user’s Personal Information
- Increasing a User’s Limits
- Exporting Users Statements
- Closing a User’s Account
Make Re-Authentication Part of the Experience
Give the user an explanation of why they are being asked to re-authenticate before issuing the re-authentication request. For example, you could say, “Please confirm it is you who is adding a new payment recipient,” vs. “Re-authenticate”. Or “Please re-authenticate to continue the transaction,” vs. “Re-authenticate.” Or “Verify your identity to proceed” vs. “Re-authenticate”. By changing the example phrases, you will help to reduce confusion and will also help to make security part of the service.
Fallback Solution for Biometric Authentication
Sometimes biometrics just does not work…
Wet hands, low-light conditions (face recognition), sharing devices amongst family members, changing a biometric enrollment, broken sensors, and varying needs for accessibility mean that multiple means of fallback are very important.
For example, in the banking app, a secure alternative should include:
- App Pin
- Verify Device Passcode
- Log in using Password plus OTP
- Passkey Based Login
- Help for Login Recovery
- Verify New Device
However, fallbacks should not be too easy to exploit, or hackers will target the fallback instead of the biometric login. An example of this is if biometric login is strong, but the fallback is simply a PIN with no additional protective measures, the attacker will only focus on the Fallback Method.
Fallback experience should be:
- Simple to use
- Secured at least as much as action taken
- Rate limited
- Monitored for abuse
- Well explained
- Available to all
For higher value transactions that require a return to a reason for performing a transaction, fallbacks should have more stringent requirements than for lower value transactions or app unlocking.
Notifications and Sensitive Data
Mobile banking apps often use push notifications for payment alerts, card activity, balance updates, fraud warnings, and authentication prompts.
Notifications are useful, but they can leak sensitive information on a locked screen. A secure mobile banking app should avoid exposing too much in push notifications.
For example:
Better: “New transaction detected. Open the app to review.”
Riskier: “€1,240.00 spent at Merchant Name from Account 1234.”
Users should also be able to manage notification preferences. Some may want detailed alerts. Others may prefer privacy-first notifications.
This is part of trust. Users should feel that the app protects them even outside the app interface.
Banking Application Testing and Quality Assurance for Security
It is imperative that security feature testing be conducted through user journeys versus independent technical tasks.
When testing Biometric login the following items should be included in your suite of test cases.
First time set-up, successful biometric unlock, failed biometric attempt, fallback flow, changed biometric enrollment, disabled device lock, application re-installation, logging into a new device, lost device scenarios, session timeout and confirming sensitive actions.
When testing Device Binding the following items should be included in your suite of test cases.
Device registration, duplicate registration, revoked device logins, multiple devices, device change, Token refresh, backend session invalidated, suspicious device signal.
When testing Secure Storage the following items should be included in your suite of test cases.
Log-out behaviour, app backgrounding, back-up behaviour, behaviour on a rooted/jailbroken device, inspecting the local cache, token expiration, re-authentication triggers.
This is where a disciplined delivery process is imperative. The Unison Framework provided by Appricotsoft has been developed around predictable progress, visible risk, weekly demos, clear artifacts, defined quality standards, decision log, risk register, and release checklists. It also incorporates responsible AI to assist with execution while holding individuals accountable for the outcomes.
The above mentioned framework is especially valuable for banking applications because security decisions must be visible, recorded, tested and aligned with the bank’s business priorities.
A Practical Security Checklist for Mobile Banking Apps
Here is a founder-friendly checklist you can use when planning or reviewing a mobile banking product.
Authentication and Biometrics
- Does the app support biometric login?
- Is biometric access optional and clearly explained?
- Are biometrics combined with secure device storage?
- Are sensitive actions protected with step-up authentication?
- Is fallback secure and rate-limited?
- Are biometric enrollment changes handled safely?
Device Binding
- Is each trusted device registered securely?
- Can users view and revoke trusted devices?
- Are device keys stored in secure platform storage?
- Is new device enrollment protected?
- Are lost/stolen device flows clear?
Session Management
- Are sessions validated server-side?
- Does the app lock after inactivity?
- Are high-risk actions protected by re-authentication?
- Are sessions revoked after a password reset or suspicious activity?
- Is the timeout policy user-friendly?
Jailbreak and Root Detection
- Does the app detect risky device environments?
- Is detection treated as one risk signal, not the only control?
- Is the user message clear if access is limited?
- Are suspicious signals logged for monitoring?
Encryption and Storage
- Is all network traffic encrypted?
- Is cleartext traffic blocked?
- Are sensitive values excluded from logs?
- Are tokens stored securely?
- Is local data minimized?
- Is sensitive cached data cleared on logout?
UX and Communication
- Do security prompts explain why they appear?
- Are error messages calm and helpful?
- Can users recover access without support overload?
- Are accessibility needs considered?
- Are privacy settings easy to find?
The Way in which Appricotsoft Handles the Security of Mobile Banking Applications
When Appricotsoft develops mobile banking applications, we see them as a challenge of trust and product development rather than just coding.
From day one of our engagement with a client, we consider how we will incorporate security into the design of the application. This means looking at the overall business model and how customers will be using it before we determine what technology stack is best suited for the final architecture.
We have a few core principles that guide our work:
Real-World User Behavior Is the Basis of Security Design:
A secure banking application must address the needs of consumers in real-life situations, such as forgotten passwords, having their phone stolen, being unable to connect to a network, or making an urgent transfer, etc. Therefore, we always begin designing the application by mapping the user journey(s) so that security issues don’t delay application delivery.
Visible Trade-Offs In Security Decisions:
Every security decision made during the development process affects the product. For example, using a shorter timeout for banking sessions would reduce risk but add friction. Similarly, implementing strict jailbreak detection may protect the institution at the cost of having to deal with a higher number of customer service calls; implementing a detailed push notification method may improve clarity but sacrifice user privacy.
We walk clients through the various security trade-offs so that there are no surprises.
Quality Assurance Embedded in All Deliveries:
In order for security features to be successful, they must have defined acceptance criteria, test cases, QA coverage, and/or release checks. By using Unison for delivery, we can maintain visibility into the entire delivery process through shared project artifacts, demo units of production code, tracking project risk(s), and validating progress on development and testing tasks.
We Keep It Practical for Founders and C-Level Teams:
You do not need to become a cryptography expert to make good product decisions. You need a team that can explain risks clearly, recommend practical options, and build software responsibly.
That reflects Appricotsoft’s values: honesty, responsibility, quality, ownership, and curiosity
Conclusion
Biometric solutions add modernity and performance to a mobile banking app, yet biometrics alone don’t mean security. Security lies in the integration of biometrics together with such technologies as device binding, secure session management, jailbreak/root protection, encryption, secure storage, and proper re-authentication experience.
The main point for founders and C-levels here is clear: security shouldn’t become a burden to the legitimate user. It should provide him or her with the needed level of trust.
In other words, a good banking app provides its users with adequate data protection, minimizes risks of fraud, complies with regulatory requirements, and informs the user about everything significant.
If your team is looking for a tech expert who would be able to develop a high-quality and scalable mobile application or fintech app in particular, then turn to us! At Appricotsoft, we help startups design their future by developing fintech and mobile apps. Our services include mobile app development services, custom mobile app development, React Native app development, fintech app development, and more!
Let’s create a banking app worthy of a user’s trust!