A friend covered my share of dinner. I told him I would send it back that night. So I downloaded the PayPal app, signed up, entered my details, set a password. Two minutes in, I had an account. I opened it, tapped to send money — and could not.
I needed to verify my identity. I needed to link a bank account, which meant waiting on small test deposits that would land in a day or two. The amount I wanted to send sat behind a wall I had not known was there. My friend was awake. The money was in my checking account. I had a working app on my phone. And I still could not do the one thing I had downloaded it to do.
That is the problem worth thinking about. Not "signup was long." Signup was fine. The problem is that finishing signup did not make me able to transact. I had joined. I had not activated. Those are different things, and the gap between them is where a lot of new users quietly give up.
What the user actually joined for
No one downloads a payments app to have an account. They download it to move money — to pay a friend back, to split a bill, to collect something they are owed. The account is not the goal. It is the thing standing between the user and the goal.
So the real flow is not "download, sign up, done." It is "download, sign up, reach the first transaction." Signup is the middle of the path, not the end of it. A product that treats a completed signup as success is measuring the wrong finish line.
And the new user is not the only one with a stake in where that line sits.
The growth team wants users to activate — a signup that never transacts is acquisition spend with nothing to show for it. The risk and compliance team owns the other side: every shortcut on identity and funding is a possible fraud loss, and a regulator does not accept "we wanted faster onboarding" as a defense. The person on the other end — the friend waiting to be paid — wants the money, and their view of the platform is being shaped by a delay they cannot see the reason for. And the new user just wants to do the thing.
Four parties. The growth team and the new user pull toward speed. The compliance team pulls toward verification. A flow that picks one side and ignores the other either bleeds fraud or bleeds users. The real product work is serving all of them at once — and that turns out to be possible, because the conflict is smaller than it looks.
What good looks like
If this is working, a new user reaches their first real transaction in the same session they signed up. Not the next day. Not after a verification email and a test-deposit wait. That session.
The platform asks for exactly as much as the law and the risk of the action in front of the user actually require — and no more. It asks at the moment the information is needed, not all of it at the door. A user sending a small amount to a friend should not clear the same checks as a user wiring a large sum to a brand-new account. The friction should match the risk of what the user is doing, not the fact that the user is new.
And the user should never be left holding an account they cannot use. If something genuinely must be verified before an action, the product says so plainly, at the moment the user tries it — not as a wall discovered after the celebration screen.
Joining is not the goal
It is tempting to measure onboarding by signup completion. It is the easy number, and it climbs whenever you remove a field. It is also the wrong number.
A completed signup that never transacts is not a win. It is a cost — acquisition paid for, an account created, a user who decided the app was not worth the wait. Counting it as success means the dashboard looks healthy while the business is not.
The goal is the first transaction. The user actually sent the money, received the money, did the thing. Everything before that is setup. If signups rise and first transactions do not, onboarding got better at the wrong job.
Why people join and then stall
Three things tend to be wrong when users sign up and never transact.
The first is that the platform demands everything at the door. Full identity verification, a linked and confirmed bank account, every compliance check — all of it before the user has done anything or seen any value. The user is asked for the largest commitment at the moment they trust the product least.
The second is that verification has a wait built into it. Bank linking through test deposits takes a day or two. A review queue takes hours. Whatever momentum the user had — the friend awake, the bill due — is gone by the time the platform is ready. The user comes back to a task, not a moment.
The third is that even when signup completes, nothing carries the user to the first transaction. The flow ends, the user lands on an empty home screen, and the product assumes its job is done. It is not. The user has an account and no path.
Underneath all three is one mistake. The platform took the friction that exists to protect the riskiest action — a large, hard-to-reverse movement of money out of the system — and applied it to the very first action, which is usually the lowest-risk thing the user will ever do. It protected the withdrawal by blocking the introduction.
What to build instead
The move is progressive onboarding. Let the user reach the smallest valuable, low-risk action with the least information possible, and defer the heavy verification to the moment the risk actually appears.
Concretely: a user should be able to start with little more than an email and a phone number, and do something real — be ready to send a small amount, or claim money someone has already sent them. The full identity check and the bank link move to the point where they genuinely matter: when money moves out of the system, or when an amount crosses a threshold where the risk is real. Verification is not removed. It is placed where the risk is.
This is also where a risk model earns its place. Instead of treating every new user as equally risky and making all of them clear the same checks, the platform can score the signup — the device, the behavior, the size and shape of the first action — and decide how much friction this particular user needs. Most new users are exactly who they say they are, doing something small. They can move through quickly. The few signups that look risky get more verification, earlier.
The line matters here. The risk model decides how much friction a user sees. It does not decide what the law requires — compliance rules own that, and they do not bend. The model's job is to route each user to the lightest path the rules allow, and to flag the ones who should not get the light path at all. It reduces friction around the rules. It does not become the rules.
Where it gets hard
The hard part is not the signup screens. It is holding the tension between activation and fraud honestly.
Every check you defer is a check that was not done before money moved. Defer too much, and the fast path becomes the fraud path. Defer too little, and you are back to the wall. The work is deciding — per action, per risk tier — what must be verified before this specific thing can happen, and what can wait. That is a real decision with a real cost on both sides, and it cannot be hand-waved by saying onboarding should be frictionless.
How you know it is working
The north star is first transaction within twenty-four hours of signup. Not signups. Not completed profiles. The share of new users who actually transact, fast.
The leading indicators move first. Step completion rate through onboarding. Time to first value — how long from download to the first thing that felt useful. The share of users who reach a state where they can transact within the first session. These tell you the path is clearing before the north star confirms it.
The lagging indicators confirm it held. The share of new accounts that ever transact at all. Seven-day and thirty-day transaction rates. Whether the users who activated fast kept going, or just spiked once and went quiet.
The countermetric is the one that keeps this honest: fraud rate among new users in their first thirty days. Progressive onboarding moves verification later, and later verification is, by definition, a window. If that window is being exploited, new-user fraud climbs, and chargebacks and disputes climb with it. A faster activation number sitting on top of a rising new-user fraud number is not a win. It is a loss the dashboard has not surfaced yet.
So that fraud rate is the kill switch. If new-user fraud crosses a set threshold over baseline — twenty percent is a reasonable line — the fast path tightens automatically: more verification, earlier, until the number comes back down. Activation that costs more in fraud than it earns in growth is not activation. It is leakage.
How to ship it without opening a hole
Start at the safest entry point. The lowest-risk new user is one signing up to claim money someone has already sent them — high intent, and the money is coming in, not going out. Let that user in with an email and a phone number, let them claim, and defer the identity and bank checks to the moment they try to move that money out. Learn there, where the risk floor is lowest.
Then widen by risk tier, not all at once. Each step earns the next by proving the fraud number held. The first version should feel like the platform trusts the user with the small, safe thing immediately, and asks for more only when more is genuinely at stake.
The tradeoff underneath all of it is activation against fraud and compliance. You cannot make it disappear. You can only decide where the verification sits. Most onboarding puts it all at the front, where it does the least good and the most damage. The better design puts it where the money actually moves.
Back to the friend waiting to be paid
Picture that Sunday night again. I download the app, sign up with an email and a phone number, and I am in — not with a full account, but with enough of one to do the small, safe thing I came for. I send my friend his share. He has it before he goes to sleep.
The identity check and the bank link still happen. They happen later — the first time I move a larger amount, or pull money out — the moment the platform actually has something to protect. By then it does not feel like a wall. It feels like the platform asking a fair question at the point the question makes sense.
That is the whole idea. Onboarding is not the part where you collect everything you might ever need. It is the part where you get the user to the first thing they came to do, and earn the right to ask for the rest by the time it matters. An account the user cannot transact with is not an account. It is a waiting room.