Playbook, fintech app
Explaining the recovery route without becoming any part of it
A reset question looks like the most harmless thing in the queue right up to the point you remember that the person typing is, by definition, unable to prove who they are. Account recovery is the flow attackers probe, and a chat widget sitting next to it is a surface worth thinking about carefully. The good news is that the correct behaviour here is also the simplest one: describe the published route, and perform none of it.
Why this is not the general answer
The handling pattern for password resets holds across every trade. What follows is the part that does not.
- The asker is unverified by construction, which is not true of any other cell in this family, and the assistant has no way to change that.
- Recovery is the flow that gets probed, so a widget that appears willing to assist with any step of it is a liability rather than a convenience.
- The real questions are rarely the password itself, they are a lost device, a changed number and a second factor nobody can reach.
- That the assistant performs no part of the flow is a security property worth stating out loud, since it also tells a customer what your staff will never ask for.
How it arrives
- i cannot log in, how do i reset my password
- i have lost the phone with the authenticator on it
- i changed my number and cannot receive the code
- how do i reset my passcode in the app
- the reset email has not arrived
- can you send me a one time code
What has to be indexed for this to work
| The published reset route, step by step | Where the reset starts, what arrives, how long the link or code is valid, and what to do when nothing turns up. Written as steps rather than as prose, because somebody locked out is not reading paragraphs. |
|---|---|
| Device change and second factor recovery | What happens when the authenticator is on a phone that is gone, whether recovery codes were issued, and what re-verification is required. This is the actual question behind most of these messages and it is the least documented part of the flow. |
| Re-verification requirements for account recovery | What a customer will be asked for when the standard route is unavailable, so the answer is a preparation instruction rather than a surprise. Publishable, and it shortens the recovery considerably. |
| Your security page on what staff will never ask for | Passwords, full card numbers, one time codes. Worth indexing precisely so the assistant can repeat it in exactly the conversation where somebody is most likely to be talked into handing one over. |
The reply
The reset starts from Forgot passcode on the sign in screen, which sends a link to the registered email that stays valid for thirty minutes, and if nothing arrives it is worth checking the spam folder before requesting a second one. If the authenticator was on a phone you no longer have, that is the device change route rather than the reset route, and it needs re-verification with an identity document. I cannot reset anything, look up an account, or send or read a code, and neither will anybody from the team ask you for one.
It separates the two flows the customer has merged, because sending somebody round the reset loop when their problem is a lost device wastes the twenty minutes they do not have. It states the non capability as a security fact rather than as an apology, which is the framing that helps a customer spot a scam later. It performs nothing and asks for nothing, which is exactly what a widget next to a recovery flow should do.
Where it stops
The trigger. Recovery requires identity re-verification, or the customer has lost access to both the registered email and the second factor.
Recovering an account when the registered email or the second factor is gone needs identity checks that cannot happen in a chat box. Leave your name and a contact email, and somebody from the team will get in touch through the proper channel. Please do not put any codes, card numbers or passwords in this box.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Anything that asks for a password, passcode, card number, or a one time code.
- Any confirmation, reading or sending of a code, link or token.
- That an account does or does not exist for a given email or number.
- A shortcut, workaround or alternative to the published recovery route.
Questions
- Could somebody use the widget to social engineer their way in?
- It cannot look anything up or write anything, so there is no account state for it to disclose and no step for it to perform. The remaining risk is wording, which is why it should never confirm that an email is registered, and why the refusal is worth writing so that it declines as a category rather than as a search that came back empty.
- Should it help when the reset email does not arrive?
- Yes, to the extent the published route covers it: spam folder, validity window, requesting a second link. What it cannot do is say whether one was sent, because that requires seeing something it cannot see and confirms an account exists at the same time.
- Why index the page about what staff never ask for?
- Because this is the conversation where somebody is most vulnerable to being asked for a code by a person pretending to be you. Having the assistant state it unprompted, in the same reply as the recovery steps, costs nothing and lands at exactly the right moment.
Keep reading
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- Handling password resets in generalAn assistant cannot reset anything. It can walk somebody through your real flow and name the step that usually breaks.
- A complaint starts a clock, so it has to be recorded rather than absorbedA complaint to a regulated firm follows a defined procedure with deadlines. The assistant quotes it and makes sure the message is logged.
- The one handover in this set where a contact form is the wrong mechanismSomebody watching money leave an account cannot wait on an email reply. Putting the number in the refusal text rather than composing it.
- The file outlasts the account, and that is a duty rather than a choiceClosure does not end a retention duty. Why erasure here is partial by law rather than by preference, and why chat removes nothing.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.