How to test a banking password reset workflow

Banking password reset workflow testing checks that a customer can regain access through approved identity verification while the bank protects credentials, account data and active sessions from unauthorised changes. It validates the journey from reset request to successful sign-in, including message delivery, reset token or code handling, password rules, failure responses and related audit or notification behaviour.

How to test a banking password reset workflow

Start by mapping the expected states and transitions from the product requirements. A typical flow moves from a reset request to identity verification, credential replacement and sign-in. Record which channels and checks apply, such as email, SMS, a one-time code or additional verification. These controls vary by bank and risk policy, so test against the approved design rather than assuming a particular method.

Prepare synthetic customer accounts with known states: active, locked, dormant or otherwise ineligible where relevant. Use test mailboxes, SMS sinks or provider stubs in a controlled environment. Keep test credentials and reset tokens out of shared logs, screenshots and CI output. Verify that test data cannot reach real customers.

Build coverage for the following behaviours:

• A valid request completes the required verification and allows the customer to set an acceptable password.
• An invalid, expired, already-used or altered token or code cannot change credentials.
• A token issued for one customer or purpose cannot reset another customer's password.
• Password policy boundaries are enforced, including any required length, character or reuse rules.
• Repeated requests and verification attempts follow the specified throttling and abuse controls.
• Responses to registered and unregistered identifiers do not reveal account membership through messages, status codes or other observable differences required to remain private.
• Delivery failures, delayed messages, duplicate submissions and interrupted sessions leave the account in a safe, defined state.

Check both the interface and relevant service boundaries. UI tests can confirm that the customer sees clear instructions, validation errors and completion status. API or integration tests can assert that the credential changes only after valid verification, that the reset token is consumed according to policy, and that failed requests make no unintended changes. Avoid relying on a single UI assertion to prove that the account state changed correctly.

After a successful reset, confirm that the new password works and the previous password fails. Check the bank's specified session policy, including how existing sessions and remembered devices are treated. Verify that the reset event is recorded for audit and that any confirmation message is sent to the intended channel. Audit records should identify the event without exposing the password, full token or other secrets.

Failure modes and dependencies to include

Password reset journeys often depend on identity services, notification providers, customer records and authentication services. Simulate timeouts, rejected delivery, delayed callbacks and partial outages at these boundaries. Confirm that retries do not create conflicting tokens or accidentally complete a reset twice. Where a provider is stubbed, retain at least one controlled integration check against the configured test service so that interface or message-format changes are detected.

Common defects include accepting a token after it has been used, applying a reset to the wrong customer, allowing a password change before verification, and leaving the old credential active. Enumeration leaks, excessive verification attempts, secrets in logs and inconsistent results between web and mobile channels also need attention. Treat rate limits and expiry as configuration-dependent rules, then test the configured boundary values and behaviour around them.

Practical example

For an account with a registered test email address, submit a reset request and capture the message in the test mailbox. Use its link once, set a password that meets the policy, then assert that sign-in succeeds with the new password and fails with the old one. Re-submit the same link and assert that no credential change occurs. Repeat with an expired link and a link issued to a different test account. Check the relevant audit event and confirm that no password or usable token appears in application logs.

Run this scenario in the relevant web and mobile journeys, and include it in regression testing when authentication, customer identity, notification or session-handling components change. Link scenarios to the requirements that define verification, privacy, password policy and session behaviour so failures can be assessed against the intended control.