Onboarding is the most consequential screen sequence a financial product has. It is where a stranger decides whether to trust you with identity documents and money, and it is where verification requirements collide with a person’s patience.
It is also where two teams with different incentives meet. Risk and compliance need evidence. Product needs completion. Treating that as a fixed trade-off produces flows that are both intrusive and leaky. Treating it as a design problem usually produces better outcomes on both counts.
Sequence for commitment, not for the database
Many onboarding flows are ordered to suit the backend: collect everything, then verify, then activate. People do not experience it that way. They abandon when the cost of the next step exceeds their current confidence that this will work.
A better ordering builds confidence before it asks for commitment — establish what the product will do for them, ask for low-friction information first, and request documents once someone has reason to believe the effort is worthwhile. Where regulation constrains sequence, the constraint is on what must be verified before activation, not usually on the order of collection.
Explain why you are asking
A one-line reason next to an intrusive request measurably changes how it feels. "We need this to verify your identity, which is required before we can hold funds for you" is not legal boilerplate — it is the difference between a reasonable request and an alarming one.
Design the waiting state honestly
Verification is often asynchronous, and "we are reviewing your application" with no timeframe is where confidence decays. Give a realistic range, say what happens next, and tell people whether they need to stay on the page. If manual review may be required, say so before it happens rather than after.
Make failure recoverable and specific
Verification fails for mundane reasons far more often than fraudulent ones: glare on a document, a name that does not match a marriage certificate, an address updated last month. A generic rejection converts an ordinary problem into a lost customer.
- Say what specifically could not be confirmed, within the limits risk policy allows
- Offer a concrete next action — retake, use an alternative document, or reach a person
- Preserve everything already entered; never make someone restart
- Provide a human route for the cases automation cannot resolve
Financial language is a risk control
Ambiguity about money produces support calls and complaints. Distinguish clearly between authorised and settled, available and pending, submitted and completed. Show currency explicitly. Show fees before confirmation, not after. If a transfer will take two working days, say so at the point of decision rather than on a confirmation screen.
Accessibility is not optional here
Financial services are used by everyone, including people with low vision, motor impairments, cognitive load, older devices and poor connectivity. Document capture in particular tends to assume a steady hand, a good camera and bright light. An alternative path — upload from files, submit by post, or complete with an agent — is both an accessibility requirement and a completion strategy.
Measure the drop-off, then look at it
Instrument each step and each failure reason, then watch real sessions. Aggregate funnels tell you where people leave; observation tells you why. In verification flows the reason is frequently something no analytics event was ever going to capture.