What this means for your test
A banking app pentest needs to follow the customer journey across the device, identity service and backend API. Include recovery, device enrolment, beneficiary changes and payment approval. Prepare customer and staff role pairs so the assessment can distinguish a permitted action from an ownership or approval failure.
One banking journey. Several security boundaries.
A banking app pentest is an authorised security assessment of a bank’s mobile or web application and the backend services that support it. It examines whether someone can access another customer’s information, misuse a session or perform an operation beyond their authority. The agreed scope can cover retail banking, business banking or a specific product release.
Atlant Security connects mobile application testing with the customer, staff and service permissions behind each journey. The question is practical: can the server still enforce the bank’s rules when the client, device or session can no longer be trusted?
Start with your platforms, customer roles and critical workflows. We turn those inputs into a proposed scope, operating conditions and deliverables.
Build your banking app RFPWhat a banking app pentest can cover
Select the channels and workflows you need assessed. An iOS build, an Android build and a shared API are distinct test surfaces; including one does not silently include the others.
| Assessment area | Questions to resolve |
|---|---|
| iOS and Android apps | How are tokens and sensitive records stored? Can logs, notifications, backups or app links expose data? Are platform interactions and network trust controls appropriate for the agreed device threat model? |
| Web banking | Do browser sessions, application inputs and sensitive actions preserve customer and role boundaries? Are protections consistent between browser and mobile journeys? |
| Backend APIs | Can a customer read or change another customer’s account, statement or beneficiary? Are object, property and function permissions checked on the server? |
| Login, recovery and device enrolment | What happens after a password reset, lost device, new device registration or session revocation? Does a sensitive operation require the intended additional verification? |
| Payments and account changes | Are beneficiary, amount, currency and approval state bound to the authorised instruction? Can an operation be repeated, reordered or changed after approval? |
| Connected services | Which identity, payment, notification and support integrations are in scope? What authority does each service identity hold, and which provider systems require separate permission? |
For an API-only engagement, see digital banking and API penetration testing. For deeper maker–checker, payment-release and reconciliation scenarios, see payment workflow testing.
How we test mobile and online banking
01 / Agree the release and test conditions
Record app identifiers, build numbers, supported operating systems, API versions and environment differences. Define the customer roles, sensitive journeys, allowed techniques, rate limits and stop contacts. Agree whether source code, a test build or supplied credentials will be available, and how that assistance will be reported.
02 / Examine the client and its communication
Review the supplied app package and observe behaviour on agreed devices. Examine local data handling, platform features and traffic to authorised services. Where application hardening restricts observation, agree the assessment approach first. A bypass in a modified test build is not presented as a demonstrated bypass of the production build.
03 / Validate the bank’s rules at the server
Exercise representative journeys with separated test identities. Compare permitted and denied operations across accounts, roles and transaction states. Validate relevant weaknesses manually and confirm state changes through independent read-back or an agreed audit record. Tool output alone does not establish business impact.
04 / Report, remediate and retest
Explain the access demonstrated, effective controls and untested areas. Review findings with the responsible teams, then retest agreed fixes against the changed build and backend version. Release deadlines, retest windows and dependencies are part of the proposal.
Example: a beneficiary change after approval
Illustrative test design, not a client result. A business banking customer creates a synthetic payment to an approved test beneficiary. A second authorised user approves it. The assessment checks whether later changes to the beneficiary or amount invalidate that approval and require the intended authorisation again.
- Starting point: dedicated maker and checker identities, a seeded payment and a non-settling test environment.
- Expected result: the server rejects an unauthorised change or returns the instruction to the appropriate approval state.
- Evidence: app and API versions, identity and role, timestamps, redacted requests and responses, resulting transaction state and relevant audit events.
- Limit: changing a draft does not prove that funds can be released. Settlement remains disabled, and any downstream signing boundary is assessed only if authorised.
This approach gives engineering and risk teams a finding they can validate without confusing an accessible screen, a successful response and a completed payment.
What your team receives
- Executive assessment: the tested banking journeys, business consequences, controls that held and priority decisions.
- Coverage record: applications, builds, roles, APIs, environments, assumptions, exclusions and any blocked or incomplete work.
- Technical findings: affected assets, preconditions, reproducible observations, redacted evidence, severity rationale and the limits of the result.
- Remediation guidance: immediate safeguards, durable corrections and acceptance criteria for the responsible development or platform team.
- Agreed retest results: changed versions, cases repeated and findings confirmed fixed, partly fixed, still open or not retested.
Review the reporting deliverables or preview the fictional Megabank AG report. The sample demonstrates the broader bank reporting format; it is not evidence of a real mobile banking assessment.
Prepare an app testing scope
Your initial enquiry only needs a high-level description. Use the RFP builder to outline systems, objectives and timing, or send an existing brief with an NDA for review through the contact form. Agree a secure transfer channel before sharing builds, credentials or sensitive architecture.
- Platforms and release: iOS, Android, web banking, build versions and the planned release or assurance deadline.
- Journeys: onboarding, login, recovery, account access, beneficiary management, transfers, approvals and other critical functions.
- Roles: retail customers, business users, delegated users, approvers, support roles and representative test relationships.
- Dependencies: API documentation, identity providers, payment sandboxes, third-party ownership and permission requirements.
- Operating conditions: environment, synthetic data, permitted methods, stop authority, monitoring contacts and cleanup.
- Outputs: report audience, remediation discussion, retest needs and any procurement or assurance mapping required.
Duration and fees depend on the number of builds and roles, workflow complexity, API coverage, access arrangements and reporting requirements. A narrow release assessment and a complete mobile-plus-web scope require different effort. We agree those assumptions before quoting.
Prepare a detailed scoping brief or send your RFP and attach an NDA.
Banking app pentest questions
Does mobile banking testing include backend APIs?
It should include the API operations needed to assess the agreed mobile journeys, with the exact services and endpoints recorded in scope. Broader API estates, internal staff systems and other channels are separate scope decisions. Testing only the app binary cannot establish how the server enforces every permission.
Can you assess both iOS and Android?
Yes. Identify both platforms when requesting the scope. Shared product features do not make platform-specific storage, permissions, app links and hardening identical. The proposal records the builds and device or operating-system coverage.
Can testing run against production?
Only under explicitly agreed conditions. A representative non-settling environment is useful for state-changing payment scenarios. Any production work needs written permission, controlled identities and data, operational limits and stop authority. The report records differences that prevent a staging result from being assumed true in production.
Do you need source code or test accounts?
Representative accounts usually make role and customer-boundary testing more useful. Source code and an instrumentable build may help answer particular questions, but are scope options. The proposal distinguishes unauthenticated, authenticated and assisted work and records what cannot be tested without the requested access.
Is this the same as a bank network pentest?
No. This service follows customer-facing application journeys from the device or browser into supporting APIs. A bank network and identity assessment examines infrastructure and internal trust paths. They can be combined where the objective requires both.
When should we request a banking app pentest?
Plan early enough to remediate and retest before a significant release. New authentication, recovery, payment or API functionality can materially change the required scope. Agree recurring coverage around your release cycle and risk programme, rather than assuming one assessment covers every later version.
Testing references and coverage
We use relevant OWASP MASVS control areas and MASTG testing guidance to structure mobile coverage. The statement of work identifies the applicable controls and test cases; mentioning these references is not a claim of OWASP certification or full coverage of every control.
API scenario selection includes object-level authorisation and sensitive business flows from the OWASP API Security Top 10. These references help organise the assessment; the bank’s own account, role and payment rules determine the expected decisions.
If the engagement has a regulatory objective, identify it during scoping and review our bank testing and regulatory guidance alongside the responsible programme owner.
