Mobile banking and finance app testing

What mobile banking app testing covers

Sources in this section were checked on 2026-09-16.

Biometric login and step-up

• Keys bound to the enrolled biometric. A payment approval must unlock a key in the iOS Keychain or the Android Keystore; a prompt success flag alone can be forced true by hooking. Apple states that a Keychain item protected with biometryCurrentSet "is invalidated if fingers are added or removed for Touch ID, or if the user re-enrolls for Face ID". On Android, a key that requires user authentication and has no positive validity duration is valid for biometric authentication only, and by default is irreversibly invalidated when a new biometric is enrolled or when all existing biometrics are deleted, unless the app calls setInvalidatedByBiometricEnrollment(false). Tests reproduce the failure pattern: a person who knows the device passcode enrols their own face and approves transfers.
• Sensor class on Android. The Android 17 Compatibility Definition, section 7.3.10 [C-6-2], states that in order for device implementations to allow access to keystore keys to third-party applications, they "MUST present only Class 3 biometrics when the authentication requires BIOMETRIC_STRONG, or the authentication is invoked with a CryptoObject". Tests run step-up on devices with Class 2 face unlock and check that the app requests BIOMETRIC_STRONG or a CryptoObject.
• Fallback and lockout. Under PSD2 RTS Article 4(3)(b), consecutive failed attempts after which the actions referred to in PSD2 Article 97(1) are "temporarily or permanently blocked" "shall not exceed five within a given period of time". Device cases cover biometric lockout, the in-app PIN fallback, a cancelled prompt, and backgrounding during the prompt; the counter across channels is covered on the PSD2 SCA testing requirements page.
• Step-up triggers. MASVS-AUTH-3 states that "the app secures sensitive operations with additional authentication". Step-up is checked before a new payee, a card details reveal, a raised card limit, and a phone number or email change.

Push-based approvals and SCA on the device

• Dynamic linking on the approval screen. RTS Article 5(1)(a) requires that the payer is made aware of the amount and the payee. Tests change the amount or payee on the server after the push is sent; under Article 5(1)(d), that change invalidates the authentication code, so the approval must fail.
• Delivery faults. Cases deliver the push after challenge expiry, twice, to a second device of the same customer, and after logout or device unbinding. A double tap must not create a second payment.
• Notification content. MASVS-PLATFORM-3 lists OTP codes in notifications as sensitive UI data. Tests read the lock screen preview for one-time codes, balances, and full account numbers.
• Device integrity. RTS Article 9(3)(b) requires "mechanisms to ensure that the software or device has not been altered by the payer or by a third party". Login and approval run on rooted and jailbroken devices, with a repackaged app binary, and with Frida attached (MASVS-RESILIENCE-1, 2, and 4).

Screens, local data, and deep links

• Card details and balances. Test builds use synthetic cards, so no real cardholder data reaches a test device. Tests look for the revealed card number and security code in the app switcher snapshot, screen recordings, the clipboard, local databases, and device logs (MASVS-STORAGE-2 and MASVS-PLATFORM-3).
• Deep links into payments. A payment link that prefills amount and payee is opened with altered parameters, while logged out, and from a second app registering the same custom URL scheme. The app must show the confirmation screen and ask for step-up before execution.
• Traffic. For MASVS-NETWORK-2 identity pinning, the proxy CA is trusted in the system store on a rooted Android device, or fully trusted on iOS, and the app must still refuse the connection. Full penetration tests of the app and its API sit in security testing.

App store rules for financial apps

• Apple. The App Review Guidelines state in 5.1.1(ix) that banking and financial services apps "should be submitted by a legal entity that provides the services, and not by an individual developer". Guideline 3.2.2(ix) states that loan apps "may not charge a maximum APR higher than 36%, including costs and fees, and may not require repayment in full in 60 days or less". Guideline 3.1.5(iii) allows apps to facilitate cryptocurrency transactions "on an approved exchange", provided they are offered only in countries or regions where the app has appropriate licensing and permissions.
• Google Play. The Financial Services policy states that any app with financial features "must complete the Financial features declaration form within Play Console". Personal loan apps must disclose the minimum and maximum repayment period, the maximum APR, and a representative total cost example in app metadata. The pre-submission check compares these values with the loan offer screens for consumer lending apps.