How to test a mobile banking app
Direct answer
Shipped untested, a mobile banking app charges overdraft fees on card purchases the balance already covered and lets a scam-coached customer add a new payee and send a Faster Payment that the bank then has to reimburse. 11 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with integration tests on card authorisation and settlement: a debit card purchase approved against the available balance settles later from a separate processor, and a mismatch charges an overdraft fee the account should not carry.
11 mandatory testsfirst: integration tests
What counts as a mobile banking app
A mobile banking app here is a bank's own iOS and Android app for accounts, transfers and cards, shipped through the iOS and Android app stores and reading balances from the bank's core ledger. It covers balance display, payee set-up, Faster Payments, card controls and statements. App-only banks that are the customer's primary account, browser-only online banking and card checkout for outside merchants are out of scope.
Adjacent product types not covered here
- neobank: A neobank onboards customers remotely with ID and selfie capture and holds funds at partner banks, so sign-up fraud and pooled-account reconciliation replace the overnight core banking batch.
- peer-to-peer payment app: A peer-to-peer payment app sends money to usernames from a linked card, so account takeover and reversals after delivery replace payee scams on a bank ledger.
- stock trading app: A stock trading app turns deposits into securities orders, so order conversion, buying power and market-open load replace balance batches and overdraft fees.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fraud or abuse by users fraud-abuse | money | primary | A customer coached by a scammer adds a new payee and sends a Faster Payment from the app; the sending bank reimburses the loss. | |
| Money leaves or fails to arrive money-loss | money | primary | A debit card purchase approved against an available balance settles later and the current account is charged an overdraft fee it should not carry. | |
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | A blind current account holder cannot read the balance or approve a transfer with a screen reader, and the European Accessibility Act names banking services. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | Prudential and conduct regulators fine the bank when a release or migration takes current account access offline and testing of the change cannot be shown. | |
| Personal or sensitive data exposed data-breach | data | primary | An app fault shows a logged-in customer another account holder's personal data. | |
| Records silently wrong data-corruption | data | practitioner single incident, no second source | An overnight core banking batch fails and is rolled back untested, so the app shows wrong balances, posts wrong interest and builds statements that do not match the ledger. | |
| Third-party dependency fails dependency-failure | outage | primary | A migration to an outsourced core banking platform goes live and customers cannot log in, see accounts or move money in the bank's app. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | By design analysis: the banking app update is held at review when the financial services declaration or the bank's licensing details do not match the listing. |
Mandatory tests (11)
Step 1: release smoke tests
Why:store-rejectiondata-breach
Done when: On every store build, a tester installs the app fresh, logs in to a test customer, sees only that customer's accounts and moves money between two of them.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: integration tests
Why:money-lossdependency-failure
Done when: A test debit card authorisation and its later settlement create one ledger entry, and no overdraft fee appears when the balance covered the amount at authorisation.
Tool class: API client. Who usually runs it: developer.
Step 3: end-to-end functional tests
Done when: A tester adds a payee, sees the name check result, sends a first transfer, and the receiving test account shows the exact amount once.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 4: penetration testing
Done when: An external tester logged in as customer A cannot open customer B's transactions, statements or payees by changing account identifiers in app requests.
Tool class: proxy. Who usually runs it: security specialist.
Step 5: data integrity and migration testing
Done when: After the overnight batch, balances, interest and statement lines for a seeded set of test accounts match the values worked out by hand in the reconciliation sheet.
Tool class: data validation. Who usually runs it: QA engineer.
Step 6: compliance checks
Why:fraud-abuse
Done when: A transfer to a new payee shows the scam warning, the customer's confirmation appears in the audit log, and the reimbursement claim opens from the transaction screen.
Tool class: test management. Who usually runs it: product manager.
Step 7: resilience and failure testing
Why:dependency-failureregulatory-penalty
Done when: With the core banking test service switched off, the app shows a service message, and a transfer submitted during the outage posts once after recovery.
Tool class: chaos tool. Who usually runs it: developer.
Step 8: accessibility testing
Done when: A screen reader user logs in, hears the balance of each account and completes a transfer to a saved payee without sighted help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 9: regression suite
Why:data-breachdata-corruption
Done when: Every app update replays the account switch, transaction list and statement download cases, and no screen shows a transaction belonging to another test customer.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 10: security scanning
Why:data-breach
Done when: Each release build is scanned and no open high finding remains on session storage, certificate checks or logged account numbers.
Tool class: SAST scanner. Who usually runs it: security specialist.
Step 11: device and browser compatibility
Why:store-rejection
Done when: The release build installs, logs in and shows the account list on the oldest iOS and Android versions named on the store listing.
Tool class: device cloud. Who usually runs it: QA engineer.
Recommended and optional tests
exploratory testingrecommended
Becomes mandatory when scam reimbursement claims rise after a payments flow change.
unit testsrecommended
Becomes mandatory when interest or fee calculation moves from the core platform into the bank's own code.
contract testsrecommended
Becomes mandatory when the bank plans a core platform migration or supplier change.
performance and load testingrecommended
Becomes mandatory when salary-day or month-end traffic has slowed logins or the bank sets an impact tolerance for app access.
offline and poor-network testingrecommended
Becomes mandatory when customers report duplicate or missing transfers after poor signal.
usability testingoptional
Optional: may cut support calls about card freeze and disputes.
Not needed and why
Not needed: the app serves customers of one bank in one language. Becomes recommended when a second language or market ships.
analytics and event tracking tests
Not needed: no attached risk depends on in-app analytics events. Becomes recommended when fraud or complaint reporting relies on app event data.
Order of work
First release
- release smoke tests: Install the store build fresh, log in as a test customer, confirm only that customer's accounts appear and move money between two of them.
- integration tests: Run a test debit card authorisation and its later settlement from the card processor and confirm one ledger entry and no overdraft fee when the balance covered the amount.
- end-to-end functional tests: Add a payee, read the name check result, send a first transfer and confirm the receiving test account shows the exact amount once.
- penetration testing: Have an external tester log in as one test customer and try to open another customer's transactions, statements and payees by changing account identifiers in app requests.
- data integrity and migration testing: After the overnight core banking batch, compare balances, interest and statement lines for the seeded test accounts with the hand-worked reconciliation sheet.
- compliance checks: Send a transfer to a new payee and check the scam warning, the customer's confirmation in the audit log and the reimbursement claim link on the transaction screen.
- resilience and failure testing: Switch off the core banking test service, submit a transfer during the outage and confirm the service message and a single posting after recovery.
- accessibility testing: Log in with a screen reader, hear the balance of each account and complete a transfer to a saved payee without sighted help.
- regression suite: Replay the account switch, transaction list and statement download cases and confirm no screen shows another test customer's transactions.
- security scanning: Scan the release build for session tokens stored on the device, missing certificate checks and account numbers written to logs.
- device and browser compatibility: Install the release build on the oldest iOS and Android versions named on the store listing, log in and open the account list.
Ongoing cadence
- release smoke tests: On every store build before submission.
- regression suite: On every app update that touches the transaction list or account caching.
- data integrity and migration testing: After each change to the overnight core banking batch or to interest rules.
- compliance checks: After each change to the new-payee or Faster Payments flow.
- security scanning: On every release build.
- resilience and failure testing: Before each core ledger or card platform change at the third party.
- contract tests: When the bank plans a core platform migration or supplier change.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of mobile banking app (ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JUnitTest framework for the JVM. apiandroidopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- XCTestApple's framework for unit and UI tests. iosopen-source
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
regression suite
security scanning
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
unit tests
offline and poor-network testing
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- Network Link ConditionerApple tool for simulating poor network conditions. iosopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for mobile banking app has the same 11 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the mobile banking app is accepted when a fresh store install shows a test customer only their own accounts and moves money between two of them. A transfer to a new payee shows the scam warning, records the customer's confirmation in the audit log and opens the reimbursement claim from the transaction screen. After the overnight batch, balances, interest and statement lines for the seeded test accounts match the reconciliation sheet.
Brief
# Test brief: mobile banking app Product type: mobile banking app. A bank's own app for accounts, transfers and cards. Risk map and evidence: https://howtotestaproduct.com/how-to-test/mobile-banking-app/ Printable checklist: https://howtotestaproduct.com/checklists/mobile-banking-app/ Run these 11 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: store-rejection, data-breach). Tool class: mobile automation. Usually run by: QA engineer. Done when: On every store build, a tester installs the app fresh, logs in to a test customer, sees only that customer's accounts and moves money between two of them. 2. integration tests (risks: money-loss, dependency-failure). Tool class: API client. Usually run by: developer. Done when: A test debit card authorisation and its later settlement create one ledger entry, and no overdraft fee appears when the balance covered the amount at authorisation. 3. end-to-end functional tests (risks: fraud-abuse, money-loss). Tool class: mobile automation. Usually run by: QA engineer. Done when: A tester adds a payee, sees the name check result, sends a first transfer, and the receiving test account shows the exact amount once. 4. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: security specialist. Done when: An external tester logged in as customer A cannot open customer B's transactions, statements or payees by changing account identifiers in app requests. 5. data integrity and migration testing (risks: data-corruption, money-loss). Tool class: data validation. Usually run by: QA engineer. Done when: After the overnight batch, balances, interest and statement lines for a seeded set of test accounts match the values worked out by hand in the reconciliation sheet. 6. compliance checks (risks: fraud-abuse). Tool class: test management. Usually run by: product manager. Done when: A transfer to a new payee shows the scam warning, the customer's confirmation appears in the audit log, and the reimbursement claim opens from the transaction screen. 7. resilience and failure testing (risks: dependency-failure, regulatory-penalty). Tool class: chaos tool. Usually run by: developer. Done when: With the core banking test service switched off, the app shows a service message, and a transfer submitted during the outage posts once after recovery. 8. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user logs in, hears the balance of each account and completes a transfer to a saved payee without sighted help. 9. regression suite (risks: data-breach, data-corruption). Tool class: mobile automation. Usually run by: QA engineer. Done when: Every app update replays the account switch, transaction list and statement download cases, and no screen shows a transaction belonging to another test customer. 10. security scanning (risks: data-breach). Tool class: SAST scanner. Usually run by: security specialist. Done when: Each release build is scanned and no open high finding remains on session storage, certificate checks or logged account numbers. 11. device and browser compatibility (risks: store-rejection). Tool class: device cloud. Usually run by: QA engineer. Done when: The release build installs, logs in and shows the account list on the oldest iOS and Android versions named on the store listing. Acceptance criteria wording: A release of the mobile banking app is accepted when a fresh store install shows a test customer only their own accounts and moves money between two of them. A transfer to a new payee shows the scam warning, records the customer's confirmation in the audit log and opens the reimbursement claim from the transaction screen. After the overnight batch, balances, interest and statement lines for the seeded test accounts match the reconciliation sheet. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a mobile banking app
What testing does a mobile banking app need?
11 tests are mandatory, from the store build smoke test and integration tests on card settlement to compatibility on the oldest OS versions named on the store listing. Each is tied to one of the 8 risks in the map, such as an overdraft fee charged on a card purchase the balance covered. Exploratory, unit, contract, performance and offline tests are recommended, each with the event that makes it mandatory.
What gets a mobile banking app rejected by an app store?
The map marks store rejection as a by design analysis risk: the update is held at review when the financial services declaration or the bank's licensing details do not match the listing. The release smoke test on every store build and the compatibility run on the oldest iOS and Android versions named on the listing are tied to it.
Which tests in a vendor test plan for a mobile banking app are not needed?
Localization is not needed while the app serves one bank's customers in one language. Analytics event tests are not needed until fraud or complaint reporting relies on app event data.
What testing is required for a mobile banking app as a financial product?
Compliance checks on the scam warning and reimbursement claim, resilience tests with the core banking service switched off and accessibility tests with a screen reader are mandatory. The map cites conduct and prudential regulator fines for releases and migrations that took current account access offline, and the European Accessibility Act for banking services.
When is test automation worth it for a mobile banking app?
The regression suite is mandatory while updates change the transaction list or account caching, because the map records a personal data glitch at a UK banking group. It replays the account switch, transaction list and statement download cases on every app update. Unit tests become mandatory when interest or fee calculation moves from the core platform into the bank's own code.
Evidence
ev-0116regulatorprimary
PS23/4 APP scams reimbursement policy statement, Payment Systems Regulator
The PSR sets a reimbursement requirement within Faster Payments for victims of authorised push payment scams, applying to in-scope payment service providers from 7 October 2024. Supports fraud-abuse for UK banking and payment apps that send Faster Payments, because scam payments made through the app become the provider's cost.
published 2023-12-19 · verified 2026-10-07
ev-0026regulatorprimary
Electronic Fund Transfers (Regulation E), Consumer Financial Protection Bureau
Regulation E sets error resolution and liability rules for consumer electronic fund transfers, so wrong or unauthorised transfers must be investigated and corrected.
published undated · verified 2026-10-07
ev-0115court-or-fineprimary
Wells Fargo Bank, N.A. (CFPB enforcement action, 2022), Consumer Financial Protection Bureau
CFPB order finding the bank charged overdraft fees when the account had enough funds at authorisation and froze accounts on suspected fraud when lesser restraints were available. Supports money-loss for a bank account app where available balance, holds and fees are shown and charged.
published 2022-12-20 · verified 2026-10-07
ev-0019regulatorprimary
European Accessibility Act, European Commission
The European Accessibility Act sets accessibility requirements for products and services such as e-commerce, banking services, e-books and transport ticketing sold in the EU.
published undated · verified 2026-10-07
ev-0112court-or-fineprimary
TSB fined [amount] for operational resilience failings, Bank of England (Prudential Regulation Authority)
This resulted in significant disruption to the continuity of TSB's banking services, including branch, telephone, online and mobile banking.
Joint PRA and FCA penalty after a platform migration left customers unable to use mobile and online banking and the bank failed to manage risk from its critical third-party IT supplier. Supports dependency-failure and regulatory-penalty for a bank's mobile app; transfers to neobanks that run on an outsourced core banking platform.
published 2022-12-20 · verified 2026-10-07
ev-0113court-or-fineprimary
FCA fines RBS, NatWest and Ulster Bank Ltd [amount] for IT failures, Financial Conduct Authority
When it noticed problems with the upgrade it decided to uninstall it without first testing the consequences of that action.
FCA penalty after a batch software upgrade and untested rollback left customers unable to use online banking or see accurate balances, with incorrect interest applied and inaccurate statements. Supports data-corruption and regulatory-penalty for banking apps that display balances and interest from the core ledger.
published 2014-11-20 · verified 2026-10-07
ev-0013standardprimary
OWASP Mobile Application Security Verification Standard (MASVS), OWASP Foundation
MASVS defines security requirements for mobile apps, including secure storage, network communication and authentication.
published undated · verified 2026-10-07
ev-0114regulatorsecondary
Nearly half a million Lloyds Banking Group customers affected by personal data glitch, UK Parliament, House of Commons Treasury Committee
Supports data-breach for mobile banking apps.
published undated · verified 2026-10-07
ev-0027regulatorprimary
PS21/3: Building operational resilience, Financial Conduct Authority
The FCA requires UK firms to identify important business services, set impact tolerances and test that they can stay within them during severe but plausible disruption.
published undated · verified 2026-10-07
ev-0001store-guidelineprimary
App Review Guidelines, Apple
Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).
published undated · verified 2026-10-07
ev-0004store-guidelineprimary
Financial Services policy, Google Play
Google Play requires declarations and licensing information from apps offering loans, trading, crypto and other financial services.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.