One convincing support request can hand over a customer’s account. Close the recovery gap.

“I lost my phone. I cannot access my email. Please change the number so I can get back in.”

A genuine customer can send that message. So can someone holding their leaked personal details. If your support process lets the caller replace the recovery channel and then receive the reset code, the attacker can complete every remaining step.

This is an illustrative scenario, not a reported Toden customer incident. It exposes a practical question: what evidence gives your team permission to hand control back?

Find the moment support can change ownership

List every action your staff can perform during recovery: remove a second factor, replace a phone number, change an email, enrol a device or approve a password reset.

For each action, record the evidence required, the staff role allowed to approve it and the system that enforces the decision. Include the emergency exception. Attackers do not have to use the path you documented if another screen lets an agent bypass it.

A customer's name, date of birth or recent transaction details can help find the record. Those facts alone should not authorise a sensitive reset. A convincing story is not stronger evidence because the caller sounds distressed.

Prove the link to the account you already know

A valid ID presented during recovery is not enough if it belongs to someone other than the established account holder. The recovery decision needs to connect the claimant with the existing record.

NIST's account recovery guidance (opens in a new tab) describes methods including recovery codes, recovery contacts and repeated identity proofing. For repeated proofing, it calls for consistency with the previously established account. It also requires recovery notifications within its scope. Those are useful design references, not a claim that every fintech follows the same mandatory recovery rules.

Where you use a live selfie and face comparison, select the trusted reference from the existing account on your server. Do not let the claimant upload both the new selfie and the supposed original reference. Use an alternative reviewed route where the reference is unsuitable or the customer cannot complete the biometric journey.

Bind the proof to one reset

Define exactly what the evidence authorises. A successful recovery check for one customer should not become reusable permission to reset a different account or change every security setting.

Your backend should verify the result, associate it with the intended account and request, enforce its permitted lifetime and reject reuse after the action completes. A client-side success screen or a screenshot sent to support is not the decision record.

Keep the new phone or email separate from the evidence used to approve it. Confirming that someone controls a newly supplied inbox tells you where they can receive messages. It does not establish that they own the account.

Give staff a safe exception route

Some genuine customers will fail an automated check. Provide a route that asks for appropriate additional evidence and assigns a clear reviewer.

An illustrative policy might allow an agent to start recovery while reserving high-risk exceptions for a second authorised reviewer. Record the reason, evidence and approver. Set restrictions according to the case rather than rewarding persistence with a bypass.

Train reviewers on the boundary they must preserve. “The customer is upset” explains urgency. It does not explain why the identity evidence is sufficient.

Review who can change the policy as well as who can approve a case. Otherwise a recovery permission can be bypassed by editing the rule.

Separate access from permission to move money

Successful recovery does not have to restore every sensitive action immediately. Your policy can apply additional conditions to new beneficiaries, contact changes or high-value withdrawals after a risky reset.

Notify the customer through established notification channels where available and appropriate. Provide a clear way to report an unauthorised change. If the only notification goes to the channel just replaced by the claimant, you have lost an independent opportunity to detect abuse.

Measure recovery completion, time to regain access, exceptions, repeated failures, complaints and confirmed takeovers. A process that blocks legitimate customers indefinitely also needs correction.

Where Toden fits

Toden's account recovery flow combines liveness, comparison with a verified photo and an account activity assessment. Your team can configure the workflow and use the result in its recovery decision.

Your application still controls the reset, staff permissions, notifications and withdrawal restrictions. A face check cannot repair an unrestricted override button.

Already using Toden? Review one real recovery journey with support and engineering. Considering it? Start in the sandbox (opens in a new tab) and test a genuine recovery, a mismatched person, an inconclusive result and an attempted reuse before production.