Progressive KYC: How to Ask for Sensitive Data Without Scaring People Off
The problem was never that you ask for a Social Security number. It's that you ask for it on the doorstep, before you've said hello.
Strahil Hadzhiev
AUTHOR
Stop asking for everything at the front door
Picture meeting someone for the first time, and before they've told you their name, they demand your passport, your home address, your date of birth, and your national ID number. You'd back away. Not because those things are unreasonable to share eventually — but because it's wildly too much, too soon, from someone who hasn't earned it yet.
That's exactly what most fintech onboarding does. It piles every sensitive requirement onto the very first interaction — full identity, government ID, Social Security number, proof of address — before the user has any reason to trust you and before they've gotten a single thing in return. Then teams act surprised when people bail at verification, and they blame the regulation. But the user didn't flee the requirement. They fled the ambush.
Progressive KYC is the fix, and the core idea is almost embarrassingly simple: stop treating identity verification as one big wall at the entrance, and start treating it as a series of smaller, well-timed asks distributed across the user's early journey. Collect the bare minimum to get someone started — often just a name, an email, maybe a phone number. Then ask for each sensitive piece only at the moment it actually becomes relevant, with the context that makes it make sense.
The unlock behind this is a distinction most teams never draw: what's required to create an account is not the same as what's required to transact. Those are two different thresholds, and cramming them into one moment is the original sin of fintech onboarding. Let someone in the door with almost nothing. Save the heavy identity verification for the moment they're about to do something that genuinely needs it — send money, withdraw funds, activate a card. Because here's the thing the compliance team can't tell you and the designer has to: the order in which you collect information is not a legal requirement. It's a design decision. Regulation says you must verify identity before certain actions. It says nothing about doing it all on screen one. That sequence is yours to design — and it's where the abandonment lives.
Earn the right to ask before you ask
Once you've decided when to ask, there's the harder craft: how. Because even a perfectly timed request for sensitive data can still scare someone off if it lands wrong. Over the years I've come to think every sensitive ask needs three things present, or it fails.
A reason. Never ask for something invasive without telling the person, right there, why you need it and what you'll do with it. "We need your Social Security number" is a threat. "Your SSN lets us verify your identity — it's encrypted immediately and never shared" is a reason. Same data, opposite feeling. The reason isn't legal boilerplate buried in a disclosure; it's a plain human sentence sitting right next to the field, doing the work of turning an interrogation into a purpose.
A moment. Ask at the point where the request feels like the natural next step toward something the user already wants. Nobody wants to hand over their ID to a product they're still evaluating. But the same person, at the moment they're about to make their first transfer, will happily verify their identity — because now the ask is standing between them and something they want, not blocking the door to something they haven't decided on yet. "To send your first payment, let's quickly verify it's really you" is a completely different experience from the same request thrown up cold at signup. The data is identical. The motivation is night and day.
A return. By the time you ask for the scary stuff, you should have already given the person something — shown them the product works, let them see their dashboard, proven you're clear and trustworthy in the small things. Think of it as a trust account: every honest, transparent, valuable moment earlier in the flow is a deposit, and the sensitive-data request is a withdrawal. Ask for the big withdrawal before you've made any deposits, and the account's overdrawn — they leave. Make your deposits first, and the withdrawal feels fair.
Underneath all three is one principle: progressive disclosure. One thing at a time, each with context, each earning the next. You're not hiding the requirements — you're revealing them at the pace a human can absorb them, in an order that builds confidence instead of triggering alarm. The goal isn't to ask for less. It's to ask for each thing at the exact moment the person is most ready to say yes.
Design the sequence so nobody ever feels ambushed
Zoom out, and progressive KYC is really an exercise in choreographing the whole early relationship — matching the rising sensitivity of what you ask for to the rising trust and value the user has experienced.
The shape looks like this. Give people meaningful access almost immediately, with the lightest possible ask. Let them explore, see the value, feel that the product is real and safe. Then, as they move toward actions that genuinely require more, unlock those capabilities in exchange for the next piece of information — always with context, always tied to what they're trying to do. Verification stops being a gate they hit before they've experienced anything, and becomes a series of small, sensible steps they take because they've decided they want in. And because these flows take time and life interrupts, you build in save-state at every stage, so a person who gets pulled away mid-verification returns to "welcome back, just one more step" instead of a blank form and a wasted effort.
Two honesty checks keep this from going wrong. First, progressive KYC does not skip requirements — it re-sequences them. Everything the regulator demands still gets collected; the user just reaches each requirement at the moment they're ready and motivated rather than all at once while they're still cold. Don't confuse "progressive" with "optional." Second, don't be sneaky about the staging. The dark-pattern version of this quietly hides that more will be asked later, luring people in and then springing requirements once they're invested. That's a betrayal, and users feel it. The honest version is upfront that verification happens in steps and signals what's coming. Progressive KYC done with integrity respects the user's time and their right to know what they're getting into. Done manipulatively, it's just a nicer-looking trap, and it poisons the trust you were trying to build.
This is why I keep coming back to the same truth across everything I design in finance: the technology and the specific requirements will keep shifting, but the psychology of handing over sensitive information does not. People give their most private data freely when two things are true — they trust the asker, and the ask makes sense in the moment. They slam shut when either is missing. Front-load everything on a stranger and you violate both. Stage the asks along a path of rising trust and clear purpose, and the exact same person hands over the exact same data without a second thought.
You can't change what compliance requires. You can absolutely change whether being asked for it feels like a handshake or a shakedown. That's the whole of progressive KYC — and it's entirely in the design.
Strahil Hadzhiev
AUTHOR
