Banking App Testing Checklist (Security-First, 2026)

Banking apps have the highest bug cost of any app category. A crash loses trust. A security bug loses the bank's license. Scripted automation covers the happy path but misses the creative attacks and

Banking apps have the highest bug cost of any app category. A crash loses trust. A security bug loses the bank's license. Scripted automation covers the happy path but misses the creative attacks and UX slips that actually hurt customers. This checklist is what a security-first QA team runs before every release.

Why banking apps are different

Three things make banking QA harder than other app categories:

1. Regulatory exposure — PCI-DSS, PSD2, RBI, SOX, GDPR all apply. A missed logging requirement or an unencrypted audit trail is a compliance finding, not just a bug.
2. Adversarial users exist. Other apps worry about frustrated users. Banking apps worry about motivated attackers.
3. Money is real and irreversible. A duplicate-submit bug on a food app costs one meal. On a banking app, it costs ten thousand dollars transferred twice.

Pre-release checklist

Authentication

1. Password login — strong password policy enforced client + server
2. Biometric login — fallback to password if biometric fails 3x
3. Biometric enrolment change detected — re-auth required with password
4. 2FA / OTP — code expires, cannot be replayed
5. Session timeout after 5 minutes idle — configurable, defaults sensible
6. Session invalidated on background for > 30 seconds
7. Device change detected — user notified via SMS + email
8. Root / jailbreak detection — app refuses to run on compromised device
9. Tapjacking protection — overlay detection blocks sensitive screens
10. Screenshot blocking on balance and statement screens

Balance and statements

1. Balance loads within 3 seconds on 4G
2. Balance matches core banking system exactly (no cached stale value)
3. Pending transactions clearly labeled separate from cleared
4. Statement pagination works past 100 transactions
5. Date range filter respects timezone
6. Export PDF / CSV — no PII in filename, file encrypted or warning shown

Transfers

1. Beneficiary add — OTP required, cooling period before first transaction
2. Beneficiary validation — IFSC / SWIFT / ABA / IBAN format strict
3. Transfer amount — min and max enforced client + server
4. Daily limit enforced and visible to user before attempt
5. Insufficient balance — clear error, no partial transfer
6. Network timeout mid-transfer — no duplicate submission on retry
7. Transfer confirmation screen — shows all details, user must confirm
8. Transaction ID visible and copyable post-transfer
9. Failure reason clear and actionable (not "error 403")

Bill pay / merchant payments

1. Biller list loads from server, not cached indefinitely
2. Autopay setup — cancellation path equally obvious
3. Recurring payment edit / pause / delete all work
4. Payment scheduled for future date — edit and cancel possible until T-1
5. Statement reconciliation — paid bills marked correctly

Cards

1. Card details load with proper masking (first 4, last 4)
2. CVV never shown in full, not even when revealed
3. Block / unblock card — immediate effect, confirmation via push
4. PIN change — OTP required, complexity enforced
5. International usage toggle — effect reflected in real time
6. Virtual card generation — unique CVV, expiry, short lifetime

Security-adjacent

1. No sensitive data in logcat / OS logs (grep for card numbers, CVVs, passwords)
2. No sensitive data in crash reports (verify with intentional crash)
3. App does not write PII to external storage
4. Clipboard is cleared after copying account numbers
5. Pull-to-refresh does not leak request body to URL
6. Deep links reject unauthenticated access to sensitive screens
7. In-app browser sandboxed — opens third-party URLs externally
8. WebView — JavaScript enabled only on trusted domains
9. Certificate pinning active — MITM attempts rejected

Push and SMS

1. Push notifications do not contain amounts or account numbers (or user opts in)
2. SMS OTP does not include recipient account details
3. Fraud alert push — actionable, link to block card
4. Rich notifications respect lock-screen privacy settings

Regulatory / compliance

1. Audit trail — every sensitive action logged with user, device, timestamp
2. Data retention — deleted accounts purged after regulated period
3. Right to export — user can download their data in machine-readable format
4. Consent flow — clear opt-in for optional data sharing
5. Accessibility — WCAG 2.1 AA minimum (legal requirement in many jurisdictions)

Accessibility

1. Screen reader reads amounts correctly ("one hundred and fifty dollars")
2. Touch targets at least 48dp, 64dp preferred for elderly users
3. High contrast mode — all text passes 4.5:1 ratio
4. Focus order predictable in long forms (transfer, add beneficiary)
5. Error announcements audible, not just visible

Edge cases

1. App backgrounded during OTP entry — session preserved 60 seconds
2. Rotation on payment screen — form state preserved
3. Locale change (English → Hindi mid-session) — app does not crash
4. Clock skew ±2 minutes — TOTP still works within window
5. Daylight saving transition — scheduled payments fire correctly
6. Account locked server-side while user in transfer flow — graceful error
7. Two sessions from two devices — last-write-wins or both allowed?
8. User changes device — old device session invalidated within 60 seconds

How SUSA helps

SUSA runs security checks automatically alongside UI exploration: OWASP Mobile Top 10, APK static analysis via Hammer integration, runtime API abuse simulation (IDOR attempts, auth bypass, tampered headers), header and CSP validation for web, sensitive-data-in-logs detection. The adversarial persona tries invalid inputs and rapid taps; the business_professional persona checks efficiency of common flows like transfer and statement download; the accessibility_user persona runs TalkBack and checks WCAG compliance on every screen.

susatest-agent test bank.apk --persona adversarial --steps 200 --security-depth full

For a banking app, I would run three SUSA passes per release: adversarial for security and stress, elderly for accessibility and UX clarity, business_professional for efficiency of the money-moving flows. Then Appium regression in CI on the generated scripts. Then a human pass for anything involving real card rails.