Bank app recovery when the customer loses their phone
A customer loses their phone and cannot sign in. Map approved recovery routes, interruptions, waiting states, accessibility, and the handoff to bank support.
Fintech and banking
Published Updated 5 min read
The customer has a new phone. The bank asks them to approve the login on their old one. The old phone is gone.
They try the help button. It asks them to sign in.
This illustrative loop is a useful place to start a banking app redesign. The customer already has an account and a reason to use it. The product has given them instructions they cannot follow. A new home screen will not resolve that.
Account recovery UX connects the bank’s approved identity checks to a path the customer can understand and complete. The bank’s security and risk owners define acceptable recovery methods. The design team makes those methods usable, including when the usual device or contact channel is unavailable.
Which problem is the customer trying to solve?
“I can’t log in” hides several situations. Someone may have forgotten a password, changed a number, lost a device, or had an account restricted. Each situation can require a different approved path.
Start by separating the circumstances without making the customer diagnose a technical cause. “I no longer have this phone” is more useful than asking them to identify an authentication-factor failure. Keep routes understandable while allowing the bank to control which details it can disclose before verification.
Map the dependencies behind each path. If a route needs an existing device, a working number, or access to email, write that down. Check that an alternative does not quietly depend on the same missing thing.
A recovery map that ends with “Contact support” is incomplete. Specify how the customer reaches support while signed out and how the bank establishes identity through that channel. A designer should never invent a shortcut around those checks to make the prototype smoother.
What should customers know before they start?
Tell them what the chosen route needs before asking for it. If an approved process requires a document or a conversation with support, explain the preparation in the bank’s own terms. Avoid making a customer discover the requirement after several screens of work.
Distinguish the customer’s task from the bank’s decision. Submitting information may start a review; it does not necessarily restore access. Button labels and confirmation copy should reflect that difference.
Time estimates need operational evidence. If the team cannot support a completion promise, describe the next step and notification channel without inventing a countdown. Explain where the customer can check progress, including when their ordinary account remains unavailable.
The same care applies to duplicate attempts. When a request already exists, show an approved route to its status rather than encouraging another submission that support must reconcile later.
What does a complete recovery flow contain?
Use this worksheet with product, security, support, and engineering. The stages are a design exercise, not a prescribed authentication policy.
| Stage | Customer’s question | Evidence the design needs |
|---|---|---|
| Choose a route | Can I use this without my old phone? | Explicit dependencies and an approved alternative |
| Prepare | What do I need before starting? | Requirements explained before the relevant step |
| Submit | Did the bank receive my request? | A clear submission result or an accurate unresolved state |
| Wait | Do I need to do anything now? | Current status, next action, and a supported contact route |
| Resolve a problem | What can I correct? | An actionable explanation within the bank’s disclosure rules |
| Return to the app | Has access actually been restored? | Confirmation of the outcome and the next approved login step |
The table’s center is the waiting stage. Teams often prototype submission and success while leaving the period between them to a generic spinner. That is precisely when the customer may close the app, lose connectivity, or contact support.
Design the return journey. Which state appears when the customer comes back? Which details remain available safely? What can support see without asking the customer to repeat sensitive information in an unsuitable channel? Agree on retention and access with the responsible owners.
Can people complete every authentication step?
The W3C explanation of accessible authentication addresses barriers such as remembering passwords and transcribing codes. It describes mechanisms including password-manager support and copy and paste that can reduce the cognitive burden of authentication.
For the redesign, test those behaviors in the actual flow. A code field that looks accessible can still frustrate someone if pasting fails, focus jumps unexpectedly, or the next instruction is not announced. Check every step, including a provider-hosted screen that the bank did not build itself.
Bring participants with relevant access needs into testing. Allow them to use their usual assistive tools. Completing the happy path on a designer’s phone does not establish that a customer can recover access under different conditions.
What should a redesign partner demonstrate?
Give a shortlisted agency the lost-phone scenario and the bank’s approved recovery rules. Ask it to trace the path from the signed-out screen through an interruption and a support handoff. Use synthetic details rather than customer documents.
The review should reveal where the process needs a product decision, where it needs a service change, and where clearer interface copy is enough. If support cannot expose a safe status check, that is a dependency to resolve, not something to conceal behind a prototype.
Track the journey after release with appropriate privacy controls. Look at completion by recovery route, repeated attempts, abandonment at specific steps, and contacts from customers who cannot tell what happens next. Interpret these alongside security outcomes; a higher completion rate alone is not permission to weaken checks.
For a broader redesign, connect this work to the banking app UX audit. The finished recovery brief should name an approved route for each supported situation, account for interruptions, and give support a usable handoff. The customer with the missing phone should reach a real next step.
