A new customer downloads your app, creates an account, and is then asked for an identity document, a selfie, their address, their employment status, the source of their funds and three tick boxes. Some of those steps are required by law. Others were added along the way, out of caution or habit, and nobody quite remembers which. That is often where fintech onboarding loses its sign-ups: in the blur between compliance and design.
I designed Moonworkers, my payroll API for small UK businesses, starting from its users: personas, wireframes, then a Figma design system. I also build content machines where nothing goes through without a written reason. Both taught me the same thing: you only simplify a sign-up flow once you have sorted what is mandatory from what is not. Here is how I do that sorting, then how I design and test the flow.
01Two kinds of onboarding that often get mixed up
The word covers two things. There is product onboarding: the screens that explain the app, guided tours, help bubbles. And there is customer onboarding in the regulatory sense: collecting information and verifying an identity, because a financial institution is not allowed to open an account without doing so.
On the first kind, Nielsen Norman Group is blunt. In the video Onboarding: Skip it When Possible, Alita Kendrick explains that these screens raise the interaction cost, even when users skip them, since they still have to dismiss them. They tax memory and pull people away from what they came to do. Her advice: test the first use, and improve the design rather than bolting an instruction manual onto it.
The same video names one case where welcome screens make sense: when the app needs information from the user to get started. That is exactly a fintech's situation. You cannot remove identity verification. You can remove the tutorial in front of it, and make the verification itself clearer.
02What regulation asks for, and what it leaves open
In Europe, the European Banking Authority has published guidelines on remote customer onboarding solutions. They set out the steps an institution should follow to choose a verification tool and assess whether it is reliable. They also state that they are technologically neutral and do not favour any one tool. According to the EBA, the Anti-Money Laundering Directive did not spell out what was and was not allowed remotely, and the guidelines were meant to clear up that uncertainty.
In France, the AMF says these guidelines have applied since 2 October 2023 to credit and financial institutions, and that it extends them to other firms it supervises. They also cover the case where an institution hands verification to a third party.
What I take from this for design: the rules fix what has to be known and checked, and leave the means to the institution, under its own responsibility. The order of the screens, how a question is worded, when a document is requested, the waiting message: all of that is still to be designed. I am not a lawyer, and I am not the one who decides what is mandatory. But I can insist that the decision is written down, and that is where everything starts.
03Justify every question before drawing a screen
The GOV.UK Service Manual offers a simple tool, the question protocol. Before designing a form, you list every piece of information you ask for and, for each one, answer a few questions in writing. Do you need it to deliver the service? Why? What will you do with it? Who has to provide it? How will you check it and keep it up to date? The manual adds that this document gives you a way to push back on unnecessary questions.
It is the same logic as my content machine. An article brief is refused while a field is missing or has no reason to be there, and the tool separates what can be checked from what has to be judged. For a sign-up flow, I build a four-column table.
- The question, as the user will read it.
- Where it comes from: a regulatory obligation (with the reference given by compliance), a product need, or "we have always asked for it".
- When it is truly needed: before the first transaction, later, or only for some customers.
- What happens if you remove it.
The third column is the one that saves the most. Nielsen Norman Group recommends, in its web form usability guidelines, removing fields that can be derived another way, collected later, or simply left out. A question compliance considers necessary is not necessarily needed on the first screen.
04Building the sign-up flow, screen by screen
Once the table is approved, I start drawing. The same principles come back every time.
Start with eligibility
The GOV.UK Service Manual advises asking first the questions that tell users whether they can use the service, so you do not waste their time. Country of residence, type of customer, minimum age: if the answer rules them out, they may as well know before photographing their passport.
One thing per page
The same manual recommends starting with a single question or decision per screen. It lists several benefits for users: understanding what is being asked, getting through on a mobile, recovering more easily from an error. And for the team: saving answers as people go, and measuring each question separately. That last point is valuable. You will finally know which screen people abandon.
State formats before the error
An identity document rejected because the photo is blurred, a proof of address that is too old, a name typed without the accents on the document: these rejections can be prevented. Nielsen Norman Group asks for formatting requirements to be explained before input, and for error messages that are visible, specific, and keep what the user has already typed. The stakes are measurable: according to the study by Seckler and colleagues cited in the same article, 78% of forms that followed usability guidelines were submitted without errors at the first attempt, against 42% of forms that did not.
Plan for the wait and the rejection
Identity verification does not always answer straight away. So I design three screens that are often forgotten: one that says what is happening during verification and how long it may take, one that explains a rejection and how to fix it, and one that lets people pick up later without typing everything again. These are the screens customers see when they are most anxious.
05Compare several flows before building
On one project, I watched a discussion go round in circles for weeks, until the day we showed several mock-up directions at the same level of finish. The decision came quickly. As long as one option is polished and the others stay as sketches, you are not comparing flows, you are comparing presentation effort.
For onboarding, I therefore prepare two or three different sequences. For example, verify everything first and then open the account. Or open limited access straight away and ask for the rest before the first transaction, if compliance agrees. I turn them into clickable prototypes and have them tested by people who match the product's personas.
One last habit, learnt on client work: a site can look fine to the logged-in team and be broken for visitors. So I test the flow as a new customer, on an average phone, with a test identity document, and never only from an admin account. It is the same discipline as acceptance testing before go-live.
06What this method does not solve
The question table is only worth something if compliance plays along. If nobody can say why a piece of information is requested, the question stays, out of caution, and that is fair: the institution carries the risk, not the designer. My job stops at making that decision visible and proposing flows, much as when I translate business needs into technical requirements.
Nor does it choose your verification tool. The EBA guidelines ask the institution to assess the tool it adopts, and that work belongs to compliance and engineering. Finally, a shorter flow guarantees nothing about fraud or sign-ups. It removes needless obstacles. If nobody wants the offer, a smoother flow will not change that.
07Where to start on Monday
Take your current flow and capture every screen. List all the questions in the four-column table, then spend an hour with whoever is in charge of compliance to fill in the "where it comes from" column. You will almost always find two or three questions that nobody can justify, and as many again that can wait.
Only then redesign: eligibility first, one question per screen, formats stated, the wait and the rejection planned for. If you would like an outside view on that sorting or on the mock-ups, it is the kind of short engagement I describe in my services, and the portfolio shows what I built for Moonworkers. Happy to talk it through.