Playbook, fintech app
Onboarding here is a check somebody else runs, not a configuration
Signing up is the quick part, and then nothing works. An identity check has to complete before an account can hold or move anything, the check runs against rules the firm did not write, and the customer is left photographing a document again and again with no idea what is wrong with it. The publishable half of this is large and precise: which documents are accepted, what a proof of address has to show, how recent it must be, and what to do next.
Why this is not the general answer
The handling pattern for setup and onboarding holds across every trade. What follows is the part that does not.
- The blocking step belongs to a required check rather than to a setup screen, so the useful material is a document specification and not a walkthrough of the app.
- Acceptable documents differ by country and sometimes by document type within a country, which means a general list is wrong for somebody and the material has to be organised by where the customer is.
- The reason a specific check did not pass is deliberately not explained by regulated firms, so the assistant can be maximally precise about requirements and must be silent about outcomes.
- Until the check completes the account cannot do the thing it was opened for, so somebody sitting in this state is losing time on something that mattered, and a vague answer costs more than no answer would.
How it arrives
- what documents do you accept to open an account
- my proof of address keeps getting rejected
- how recent does a utility bill have to be
- can i open an account if i am not a resident here
- how long does verification normally take
- i uploaded my passport days ago and nothing has happened
What has to be indexed for this to work
| The accepted document list, organised by country | Which identity documents and which address documents are accepted where, including the ones that are not. A single global list produces confident wrong answers for every market you did not have in mind when writing it. |
|---|---|
| What a proof of address has to show, item by item | The name as it appears on the account, the full address, the issue date and the maximum age, plus whether a screenshot or a downloaded document is acceptable. Most rejections are one of those five things, and all five are publishable. |
| The published timescale, and what happens when a check does not pass | How long a check normally takes, what the customer will see, and the route for submitting something again. Not the reasons a check fails, which is a different document and not a public one. |
| Eligibility conditions stated before anybody applies | Age, residency, which countries are supported and which account types are open to whom. Putting this in front of the signup saves somebody a rejection they could have predicted, which is the least pleasant way to meet a new product. |
The reply
For a proof of address the document has to show your name exactly as it appears on the account, the full address, and a date inside the accepted window, and the accepted document types differ by country so the list for yours is the one to work from [1]. Screenshots are treated differently from downloaded documents, which catches a lot of people [2]. I cannot see your account or tell you why a particular upload was not accepted, and I would not want to guess at it. If you have submitted something and heard nothing, leave your name and the email you signed up with and the team will check where it is.
It answers with the five things a document has to show rather than with encouragement, because somebody on their fourth attempt needs a specification. It flags the screenshot distinction unprompted since that rejection cause is invisible to the customer. It refuses to speculate about the specific rejection even though the person is almost certainly just confused, because from here there is no way to tell.
Where it stops
The trigger. The visitor asks why their own document was rejected, how long their own check will take, or says they have submitted something and heard nothing.
I have no view of your application or any document you have sent, so I cannot say what happened to it. Leave your name and the email you signed up with, and the team who can actually see it will pick it up.
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
- Never say why a particular document was rejected, or what to change so that the next attempt passes.
- Never say a document type is acceptable in a country your published list does not cover.
- Never confirm that an application exists, or that a document has been received.
- Never predict whether somebody will be approved, or say that approval is likely.
Questions
- Can it tell somebody how far through verification they are?
- No. It cannot see an application, a document or an account, and verification status belongs behind authentication rather than behind a chat box on a public page. It can give the published timescale, which answers the question underneath most of these.
- Is it not obstructive to refuse to explain a rejection?
- It would be if the alternative existed. Firms are unspecific about failed checks for reasons that are not customer service laziness, and an assistant improvising a cause is worse than one that hands over. The compensation is being unusually precise about the requirements themselves.
- What is the highest value document to write first?
- The address document specification: the five things it must show, and the maximum age. It is short, it is the same for everybody in a given market, and it sits behind a large share of repeat uploads and the messages that follow them.
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 setup and onboarding in generalMost product material is written for somebody who already understands it. A first run guide has to be ordered, not merely complete.
- A frozen screen is support, a frozen payment is something else entirelyCrashes, camera steps and reinstalls are answerable. The moment a payment is involved it stops being a troubleshooting question.
- At two in the morning the only useful answer is a telephone numberWhich routes run around the clock and which do not, and why a quiet weekend is settlement rather than an unanswered message.
- The one answer that has to be a quotation rather than a sentenceSafeguarding and deposit protection are drafted statements, not a topic. Quote the paragraph, never summarise it, never reassure.
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.