00 — OVERVIEW

My Role

Product Designer & Builder

Type

Product concept

Period

2026

The Stack

React · Custom CSS · AI-assisted build

New businesses have to prove they're legitimate before they can move money. I designed the full KYB onboarding flow for Sanad, a fictional business-banking product, and built it as a working React prototype. One rule shaped everything: you can't make the process easier by making it less rigorous.

Outcome

A working six-screen prototype, embedded in the case study. Every decision earns its place against a constraint that can't move: regulators decide the steps, design decides how they feel.

"The interesting part isn't the screens. It's the constraint: make a legally rigid process feel fast, clear, and trustworthy without weakening what it's required to do."

New businesses can't move money on a fintech product until they pass KYB (Know Your Business) verification. It's slow, document-heavy, and legally mandatory, so businesses start it, hit friction, and quit. The company loses a customer it already paid to acquire.

You can't fix this the usual way. Regulators require every step, so "remove friction" is off the table. The real problem is narrower:

How do you make a legally rigid, unavoidable process feel fast and trustworthy, without weakening what it's required to do?

I designed the full flow for a fictional business-banking product, Sanad, and built it as a working prototype. Then I audited my own build against best practice and published what it got wrong. Click through it below.

Live prototype · click through the real flow
sanad.app/verify
Business verification

Verify your business

Let’s get your business verified so you can start moving money.

Regulators require us to confirm a few things before you go live. Here’s the whole path up front — no surprises. Most businesses finish the form in about 10 minutes.

  1. 1Business detailsLegal name, registration, address.~3 min
  2. 2OwnersAnyone who owns or controls 25%+.~4 min
  3. 3DocumentsProof of the above. Miss one? Add it later.~3 min
  4. 4ReviewCheck it over and submit.~1 min
After you submit, verification takes 1–2 business days. You can leave and pick up exactly where you left off.
The actual working prototype, not a video. Reach the rejection path by simulating that outcome on the pending screen. This is the post-audit v2 build. Prefer to skim? The key screens are captured below.

The Short Version

Who it's for: a founder or ops lead, busy, not a compliance expert, often missing a document, and a little guarded about handing over sensitive data. Not someone who reads instructions.

Scope: the six-screen verification journey only. Not the banking product, back-office tools, or pricing. Depth on the journey, not breadth.

Research: I studied how Stripe, Mercury, and Airwallex handle onboarding. Three things stood out, and each became a design move:

  • Best pattern: Mercury asks for light info first, heavy KYB later. Commitment builds before documents do.
  • Worst pattern: the waiting screen after you submit. All three leave it thin. The moment that most needs reassurance gets the least design.
  • The gap nobody fills: the emotional design of rejection. Everyone tells you what to fix; nobody makes a rejected document feel non-accusatory.

Six Decisions

Each one is the same shape: the problem, what I chose, and the option I rejected. What you decide not to do says as much as what you ship.

1. Show the whole path up front

A busy, anxious user needs to know what they're in for before they commit. The process really is long, so I show the entire map (every step, with time estimates) instead of revealing it one screen at a time. Hidden scope doesn't reduce drop-off; it just delays it to the moment the user feels misled.

Decision 1 — the whole path, with per-step time estimates and the 1–2 day wait, set before the user starts.

2. Explain why at every sensitive request

Non-experts abandon when asked for something invasive with no reason. Some requests genuinely are invasive and can't be removed, so I put a one-line "why we ask" next to each sensitive field rather than a generic privacy blurb up top. Blanket reassurance is wallpaper; a specific reason lands where the anxiety actually is.

Decision 2 — the reason sits inline, next to the field that triggers the worry.

3. Build momentum before the heavy lifting

Early confidence carries people into the hard parts. I sequence easy-to-hard and pre-fill what's already known so the user just confirms it, instead of one long form up front. Front-loading effort before any sense of progress is the fastest way to lose someone at step one.

Decision 3 — the applicant is pre-added; the user confirms rather than starts from blank.

4. Never hard-block a willing user

The most common real-world drop-off is "I don't have that document right now." The document is still required, but I let the user mark it "add later," keep moving, and save automatically. A hard block turns a temporary problem into a permanent one. Required doesn't mean required this second.

Decision 4 — the escape hatch works on required documents too, which is the whole point.

5. Make the wait honest instead of empty

Review takes days on the backend, and a silent "pending" screen erodes the trust the flow just built. I can't make the review faster, so I made the wait honest: a real timeline, plain-language status, what to do meanwhile, and how they'll be told. A cheerful "almost done!" breaks trust the moment it turns out to be untrue.

Decision 5 — the research's worst pattern, turned into the screen that reassures.

6. Handle rejection with dignity

A document gets rejected. Told badly, the user feels accused and quits at the finish line. I name the exact item and reason, reassure that everything else is saved, and drop them straight to fixing that one thing. "Verification failed" reads as an accusation and a dead end. "Your proof of address is a little out of date, everything else is verified" is the same fact delivered as a small, fixable task.

Decision 6 — the screen I invested the most in: specific, blameless, one tap forward.

Auditing My Own Build

Because the prototype is real code, I could hold it to the same standard as the writing. After the first build, I audited it against best practice. It failed in four places, and the failures are worth showing.

  • The consent checkbox was a dark pattern. V1 shipped it pre-checked. Legal consent has to be an affirmative act, so now it starts empty and Submit stays disabled until it's ticked.
  • The build contradicted my own Decision 4. "Never hard-block" — yet "add later" only existed on the optional document, where it does nothing. I extended it to required documents.
  • "Saved automatically" was a lie. The label was there, but going back wiped uploads and owners. I moved state up so the promise the UI makes is one the prototype keeps.
  • A date that didn't add up. The rejected document was named as a June bill while the reason said January. A compliance reviewer would catch that in seconds; so should I. Fixed, along with accessibility gaps: unlinked labels, a keyboard-unreachable step rail, missing focus states.

None of these showed up in a screenshot. They only surfaced because the artifact runs, which is the argument for designing in code: it makes your claims testable, including against yourself.

Two Threads, and What's Next

Every screen comes back to two ideas: explain why at every sensitive moment, and never hard-block a willing user. Trust is built request by request, and momentum is the scarcest resource in onboarding.

Because this is a concept, I have design intent, not proof. Rather than invent a "40% lift," here's what I'd test: whether "add later" actually recovers droppers, whether the per-field reasons cut abandonment on the owners step, and whether the honest wait lowers support tickets during review.

Regulators decide what the steps are. Design decides how they feel. That gap is the whole job.

Return home
Back to Home
next story
Form: Privacy-First Health