How to test a neobank
Direct answer
Shipped untested, a neobank opens accounts in the app for applicants with a landmark as home address, which can then move the proceeds of financial crime, and fails to send the remaining balance to the external bank when a customer closes the account. 10 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: the same self-service sign-up and closure flows carry both accounts opened on implausible details and the unpaid closing balance.
10 mandatory testsfirst: end-to-end functional tests
What counts as a neobank
A neobank here is a licensed or partner-bank-backed app on iOS, Android and web that is the customer's primary account, opened entirely through in-app sign-up with ID and selfie capture. It covers remote onboarding, sanctions screening, the app ledger of customer balances, card payments, transfers and account closure. A traditional bank's own app on its core ledger and a card or wallet that sits on top of another bank account are out of scope.
Adjacent product types not covered here
- mobile banking app: A mobile banking app serves existing customers of a bank with branches and its own core ledger, so overnight batch errors and payee scams lead instead of remote onboarding fraud.
- peer-to-peer payment app: A peer-to-peer payment app holds stored balances for sending money between people but is not the primary account, so social feed privacy and reversals after delivery replace sanctions screening at sign-up.
- crypto exchange: A crypto exchange holds customer assets in hot and custodial wallets rather than pooled partner bank accounts, so wallet signing and order book load replace partner bank reconciliation.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fraud or abuse by users fraud-abuse | money | practitioner single incident, no second source | The in-app sign-up accepts a landmark as a home address, and the account opens for someone who can use it to move the proceeds of financial crime. | |
| Money leaves or fails to arrive money-loss | money | primary | A customer closes the account in the app and the remaining balance is not sent to their external bank within the promised window. | |
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | The selfie and ID capture step in app-only onboarding cannot be completed with a screen reader, so a blind applicant has no branch alternative. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | Automated sanctions screening at app sign-up checks only part of the list, and accounts keep opening for high-risk applicants while a regulator restriction is in force. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | By design analysis: the app stores ID document photos, selfies and proof of address from remote onboarding, so a storage or API fault exposes identity kits. | |
| Records silently wrong data-corruption | data | practitioner single incident, no second source | The app's own ledger of customer balances drifts from the partner bank's pooled account records, and nobody can say whose money is where. | |
| Third-party dependency fails dependency-failure | outage | primary | The banking-as-a-service provider between the app and its partner banks fails, and app customers cannot withdraw balances the app still displays. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | By design analysis: the app is the only way to open the account, so a held release blocks sign-ups when partner bank or licence details on the listing are incomplete. |
Mandatory tests (10)
Step 1: release smoke tests
Why:store-rejection
Done when: On every store build, a tester signs up a new test applicant, passes the ID step, receives account details and makes a first card payment in the sandbox.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: end-to-end functional tests
Done when: An applicant with an implausible address or mismatched selfie is sent to manual review, and a closed test account's balance arrives at the external bank account.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 3: penetration testing
Done when: An external tester cannot download another applicant's ID photo or selfie, and cannot reuse a passed ID check to open a second account.
Tool class: proxy. Who usually runs it: security specialist.
Step 4: data integrity and migration testing
Done when: After each partner bank statement, the sum of customer balances in the app ledger equals the pooled account statement; a run that finds a difference lists it by customer.
Tool class: data validation. Who usually runs it: QA engineer.
Step 5: compliance checks
Why:regulatory-penaltyfraud-abuse
Done when: Test applicants whose names are on the current sanctions list are stopped at sign-up, and the screening log shows the list version used.
Tool class: test management. Who usually runs it: product manager.
Step 6: regression suite
Why:regulatory-penaltydata-corruption
Done when: Every release reruns the sign-up screening and ledger posting cases, and none changes outcome against the previous release.
Tool class: API client. Who usually runs it: QA engineer.
Step 7: accessibility testing
Done when: A screen reader user completes sign-up, including the ID and selfie step or its stated alternative, without sighted help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 8: integration tests
Why:dependency-failuredata-corruption
Done when: A card payment, a refund and an incoming transfer made in the sandbox each appear once in both the app ledger and the partner bank feed.
Tool class: API client. Who usually runs it: developer.
Step 9: security scanning
Why:data-breach
Done when: Each release build is scanned and no open high finding remains on stored ID images, tokens or card details on the device.
Tool class: SAST scanner. Who usually runs it: security specialist.
Step 10: resilience and failure testing
Done when: With the partner bank feed stopped, the app marks balances as delayed instead of showing stale figures as current, and blocks withdrawals it cannot confirm.
Tool class: chaos tool. Who usually runs it: developer.
Recommended and optional tests
exploratory testingrecommended
Becomes mandatory when customer growth outpaces the fraud team's review queue.
unit testsrecommended
Becomes mandatory when the neobank runs its own ledger instead of the partner bank's.
device and browser compatibilityrecommended
Becomes mandatory when sign-up drop-off differs by device model.
performance and load testingrecommended
Becomes mandatory when a launch or referral campaign has slowed sign-ups or card approvals.
usability testingoptional
Optional: may lift sign-up completion for an app-only account.
offline and poor-network testingoptional
Optional: may catch duplicate transfer submissions from poor mobile signal.
Not needed and why
Not needed: the app launches in one market and language. Becomes recommended when a second country licence or language ships.
payment and money-flow testing
Not needed: card and transfer flows run in the issuer processor sandbox under integration tests. Becomes recommended when the app accepts card top-ups from other banks.
analytics and event tracking tests
Not needed: no attached risk depends on product analytics events. Becomes recommended when fraud scoring uses in-app event data.
Order of work
First release
- release smoke tests: On the store build, sign up a new test applicant, pass the ID step, receive account details and make a first card payment in the sandbox.
- end-to-end functional tests: Submit a test applicant with an implausible address or mismatched selfie and confirm manual review, then close a funded test account and confirm its balance reaches the external bank account.
- penetration testing: Have an external tester try to download another applicant's ID photo or selfie and reuse a passed ID check to open a second account.
- data integrity and migration testing: Compare the sum of customer balances in the app ledger with the partner bank's pooled account statement and list any difference by customer.
- compliance checks: Run test applicants whose names are on the current sanctions list through sign-up and confirm they are stopped and the screening log shows the list version used.
- regression suite: Rerun the sign-up screening and ledger posting cases and confirm no outcome changes against the previous release.
- accessibility testing: Complete sign-up with a screen reader, including the ID and selfie step or its stated alternative, without sighted help.
- integration tests: Make a card payment, a refund and an incoming transfer in the sandbox and confirm each appears once in the app ledger and in the partner bank feed.
- security scanning: Scan the release build for stored ID images, tokens and card details on the device.
- resilience and failure testing: Stop the partner bank feed and confirm the app marks balances as delayed and blocks withdrawals it cannot confirm.
Ongoing cadence
- release smoke tests: On every store build before submission.
- regression suite: On every release that changes onboarding rules or ledger code.
- compliance checks: When the sanctions list is updated and after each change to screening rules.
- data integrity and migration testing: After each partner bank statement is received.
- integration tests: When the partner bank or banking-as-a-service provider changes its feed or API version.
- resilience and failure testing: Before each change of provider between the app and its partner banks.
- exploratory testing: When customer growth outpaces the fraud team's review queue.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of neobank (ios, android, web). 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
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
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- 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
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
unit tests
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
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
performance and load testing
- ArtilleryLoad testing with YAML scenarios. apiwebfreemium
- GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
- JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
- k6Load testing scripted in JavaScript. apiwebopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- LocustLoad testing scripted in Python. apiwebopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for neobank has the same 10 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the neobank app is accepted when a new test applicant can sign up, pass the ID step, receive account details and pay by card, while applicants on the current sanctions list are stopped with the list version logged. A closed test account's balance arrives at the external bank account. After each partner bank statement, the sum of customer balances in the app ledger equals the pooled account statement, and a run that finds a difference lists it by customer.
Brief
# Test brief: neobank Product type: neobank. A licensed or partner-bank-backed app that is the customer's primary account. Risk map and evidence: https://howtotestaproduct.com/how-to-test/neobank/ Printable checklist: https://howtotestaproduct.com/checklists/neobank/ Run these 10 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). Tool class: mobile automation. Usually run by: QA engineer. Done when: On every store build, a tester signs up a new test applicant, passes the ID step, receives account details and makes a first card payment in the sandbox. 2. end-to-end functional tests (risks: fraud-abuse, money-loss). Tool class: mobile automation. Usually run by: QA engineer. Done when: An applicant with an implausible address or mismatched selfie is sent to manual review, and a closed test account's balance arrives at the external bank account. 3. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: security specialist. Done when: An external tester cannot download another applicant's ID photo or selfie, and cannot reuse a passed ID check to open a second account. 4. data integrity and migration testing (risks: data-corruption, money-loss). Tool class: data validation. Usually run by: QA engineer. Done when: After each partner bank statement, the sum of customer balances in the app ledger equals the pooled account statement; a run that finds a difference lists it by customer. 5. compliance checks (risks: regulatory-penalty, fraud-abuse). Tool class: test management. Usually run by: product manager. Done when: Test applicants whose names are on the current sanctions list are stopped at sign-up, and the screening log shows the list version used. 6. regression suite (risks: regulatory-penalty, data-corruption). Tool class: API client. Usually run by: QA engineer. Done when: Every release reruns the sign-up screening and ledger posting cases, and none changes outcome against the previous release. 7. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user completes sign-up, including the ID and selfie step or its stated alternative, without sighted help. 8. integration tests (risks: dependency-failure, data-corruption). Tool class: API client. Usually run by: developer. Done when: A card payment, a refund and an incoming transfer made in the sandbox each appear once in both the app ledger and the partner bank feed. 9. 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 stored ID images, tokens or card details on the device. 10. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer. Done when: With the partner bank feed stopped, the app marks balances as delayed instead of showing stale figures as current, and blocks withdrawals it cannot confirm. Acceptance criteria wording: A release of the neobank app is accepted when a new test applicant can sign up, pass the ID step, receive account details and pay by card, while applicants on the current sanctions list are stopped with the list version logged. A closed test account's balance arrives at the external bank account. After each partner bank statement, the sum of customer balances in the app ledger equals the pooled account statement, and a run that finds a difference lists it by customer. 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 neobank
What testing does a neobank need?
10 tests are mandatory, starting with a sign-up smoke test on every store build and end-to-end tests of sign-up and account closure. Each is tied to one of the 8 risks in the map, such as accounts opened on implausible details through app-only onboarding or balances drifting from the partner bank's pooled account. Exploratory, unit, compatibility and performance tests are recommended, each with the event that makes it mandatory.
What is the minimum testing for a neobank at MVP stage?
The minimum is the 10 mandatory tests, because each condition already applies from the first release of an app-only account: self-service sign-up, identity documents stored from remote onboarding and customer funds pooled at partner banks. Usability and offline tests are optional, and localization, payment sandbox and analytics tests are not needed until the conditions on the page change.
What gets a neobank rejected by an app store?
The map marks store rejection as a by design analysis risk: a release is held when partner bank or licence details on the listing are incomplete, and because the app is the only way to open an account, a held release blocks sign-ups. The sign-up smoke test runs on every store build, and compatibility of the ID capture step becomes mandatory when sign-up drop-off differs by device model.
What does GDPR mean for testing a neobank?
The map cites the General Data Protection Regulation for the data breach risk, because the app stores ID document photos, selfies and proof of address from remote onboarding. Penetration testing checks that one applicant cannot download another's ID photo or selfie, and security scanning checks stored ID images and tokens on the device on every release build.
Which tests in a vendor test plan for a neobank are not needed?
Analytics event tests are not needed while no attached risk depends on product analytics events, until fraud scoring uses in-app event data. Localization is not needed while the app launches in one market and language. Payment and money-flow testing is not needed while card and transfer flows run in the issuer processor sandbox under integration tests.
Evidence
ev-0117court-or-fineprimary
FCA fines Monzo [amount] for failings in financial crime controls, Financial Conduct Authority
FCA penalty against an app-only bank whose financial crime controls did not keep pace with customer growth and which onboarded customers on obviously implausible details, such as London landmarks as an address. Supports fraud-abuse and regulatory-penalty for neobank in-app onboarding.
published 2025-07-08 · 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-0119court-or-fineprimary
Chime Financial, Inc. (CFPB enforcement action), Consumer Financial Protection Bureau
CFPB order against a fintech offering accounts through partner banks for failing to refund remaining balances to customers who closed their accounts within the promised window. Supports money-loss for the neobank account closure flow.
published 2024-05-07 · 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-0118court-or-fineprimary
FCA fines Starling Bank [amount] for failings in their financial crime systems and controls, Financial Conduct Authority
FCA penalty against an app-only bank whose automated sanctions screening system had been checking customers against only part of the sanctions list, and which opened accounts for high-risk customers despite a restriction. Supports regulatory-penalty for neobank automated onboarding and screening.
published 2024-10-02 · 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-0025regulatorprimary
Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union
The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.
published undated · verified 2026-10-07
ev-0120court-or-fineprimary
Synapse Financial Technologies, Inc. (CFPB enforcement action), Consumer Financial Protection Bureau
CFPB complaint that a banking-as-a-service middleware provider did not keep records of where consumer funds sat or keep them matched with partner bank records, so consumers of fintech apps lost access to funds. Supports data-corruption and dependency-failure for neobanks that hold balances through partner banks.
published undated · verified 2026-10-07
ev-0028regulatorprimary
Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex, European Union
DORA requires EU financial entities to test digital operational resilience, manage ICT third-party risk and report major ICT incidents.
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.