KYC drop-off is often a funnel diagnosis problem. More signups will not fix a verification bottleneck. When users create an account but never complete identity verification, the useful question is not simply “How do we send another reminder?” It is “Which step did they reach, what stopped them there, and what evidence would change our diagnosis?”
In my growth work across Vietnam and the Philippines at ZoltMoney, I worked on the journey from registration to identity verification and first transfer. That experience shaped the diagnostic process below. It is a framework for consumer apps and fintech teams, not a claim about a specific company’s results.
1. Define the drop-off before trying to fix it
“Signed up but not KYC” can describe several different states. A user may never open verification, start but stop at a document screen, submit and wait for review, or receive a request to resubmit. These users need different product fixes and different messages.
- Eligible cohort: people who registered during the same period and were actually offered verification.
- Entry: opened the verification flow.
- Progress: reached each meaningful step, such as personal details, document capture, and submission.
- Outcome: approved, pending, rejected, or asked to resubmit.
Pick one denominator for each conversion rate and keep it consistent by country, channel, device, and signup week. For example, “approved / registered” answers a different question from “approved / submitted.” Do not treat a pending review as user abandonment.
2. Check whether your events reflect reality
A neat-looking funnel can still be wrong. I have seen how a missing notification or an incomplete analytics event can make a team misread the journey. Compare event data with the operational source of truth for verification status. Exclude internal and test accounts, duplicate attempts, and users who were not eligible to begin the flow.
A minimum event map is signup completed → verification opened → step reached → submitted → final status. Record the timestamp, market, device, source, and a stable user identifier in a privacy-conscious way. Then audit a small sample of real records against the event trail before trusting the dashboard.
3. Diagnose the friction at the exact step
Look at the point where users pause, then pair the funnel with qualitative evidence. Possible causes include unclear instructions, document capture on a small screen, a failed upload, an interruption, uncertainty about why identity information is needed, or a status message that never arrives. These are hypotheses until you validate them.
Three useful questions for a short support conversation are: “Where did you pause?”, “What felt unclear or inconvenient?”, and “What would help you continue?” Ask in plain language such as “identity verification” or “finishing your account setup.” Never request identity documents through an informal support channel.
4. Match the response to the cause
| Observed state | First response to test | Measure |
|---|---|---|
| Never started | Make the value and expected steps clear at the entry point. | Verification starts per eligible signup. |
| Stopped at a step | Clarify that step or repair its usability; link back to the correct screen. | Step-to-step completion. |
| Needs resubmission | Explain the allowed next action without exposing sensitive details in push copy. | Valid resubmissions and approvals. |
| Pending review | Set accurate status expectations and provide a support route. | Unnecessary repeat attempts and support contacts. |
Lifecycle messages can support a product fix, but should not hide a broken flow. A D0, D1, or D3 reminder should have an entry rule, an exit rule, a frequency limit, and a destination that matches the user’s actual state. Check consent and applicable communication rules before sending.
5. Measure completed verification, not just message clicks
Track eligible signups, verification starts, submissions, approvals, time to approval, and support reasons by cohort. For each intervention, compare the same outcome over a defined window and note any concurrent product or channel changes. An opened email or clicked push is diagnostic, not proof that the user completed verification.
A practical one-week audit: Day 1, reconcile status data; Day 2, map steps; Day 3, inspect mobile friction; Day 4, read support themes; Day 5, choose one product or message hypothesis; Day 6, run a small test; Day 7, review approved outcomes and what remains uncertain.
6. Segment the problem without losing the denominator
Overall conversion can improve while a valuable cohort gets worse. Read the same journey by acquisition source, signup week, country, operating system, app version, and new versus returning users. If one campaign brings in people who are still exploring, its registration-to-approval rate may look weaker even when the verification interface is working. Conversely, a high-intent campaign may disguise a serious document-capture issue. Separate mix effects from changes in the product experience before prioritizing a fix.
Keep segments large enough to interpret and use a consistent window, for example approvals within seven days of signup. A cohort with fewer than a handful of people can raise a useful question, but it is not a reliable basis for declaring a winner. For markets with different identification requirements, do not copy a step-level benchmark from one country to another. Compare each market with its own previous cohorts and approved policy.
“A reminder cannot repair a step that people cannot complete.”
7. Turn the diagnosis into a decision tree
Imagine 100 eligible new users register. Some never open identity verification. Others open it but do not submit. Another group submits and is awaiting review. The aggregate label “incomplete KYC” hides three owners: acquisition and onboarding for the first group; product and operations for the second; and status communication or review operations for the third. That example is illustrative, not a ZoltMoney result.
For each branch, write down three things: what you observed, the most plausible explanation, and the evidence that would disprove it. If starts are low, review the screen that explains the value and timing of verification. If starts are healthy but document submission falls, inspect recordings or usability sessions where permitted and review device-specific errors. If submitted users return repeatedly, compare the status shown in the app with the verified back-end status. This simple discipline prevents a team from treating every gap as a copywriting problem.
Do not infer a user’s motivation from a single event. A missing “submitted” event may mean abandonment, a broken event, a delayed sync, or a legitimate review state. Pair quantitative data with support tags, product error logs, and a small set of consented user conversations. Report uncertainty to stakeholders rather than smoothing it away.
8. Design lifecycle support around state and safety
Useful lifecycle communication starts with a precise trigger. A user who has never opened verification might receive a short explanation of why the step matters and what to prepare. A user who paused at document capture needs a deep link to resume, plus help with the specific allowed document types. A user awaiting review needs a truthful status update, not a generic “finish verification” prompt. A resubmission request should route them to the secure in-app process, with details exposed only after authentication.
Set an exit rule as carefully as the trigger: stop messages when verification is submitted, approved, or the user opts out. Suppress duplicate journeys across email, push, and in-app messages. Respect local consent rules and your compliance team’s approved wording. For a fintech product, do not imply approval is guaranteed or that completing a verification step creates a financial benefit by itself.
Example message for a user who started but did not submit: “You can return to your account setup where you left off. Open the app to review the next verification step. Need help? Use support in the app.” The exact copy and timing should be reviewed against the product’s current status logic and local requirements.
9. Test one causal hypothesis at a time
Before a change goes live, write a short test card: eligible population, current baseline, intervention, primary outcome, measurement window, and guardrails. For instance, if users repeatedly fail to capture a document image, the hypothesis may be that clearer camera guidance increases valid submissions. The primary measure is valid submissions or eventual approvals in that cohort; guardrails might include resubmission rate, support contacts, and review workload.
Where feasible, compare an exposed group with a randomized holdout. If the sample is too small, use a cautious before-and-after read with matched cohorts and disclose what else changed. Avoid celebrating a lift in verification starts if approvals fall or fraudulent attempts rise. Document the decision and what you will learn next, including cases where the evidence does not support the hypothesis.
Questions to bring to a growth review
- Which precise states are included in “incomplete KYC,” and who owns each one?
- Does our event trail agree with the verified operational status?
- Which step and segment account for the largest recoverable gap?
- What evidence from users supports the leading explanation?
- Will the proposed fix improve approved users without increasing risk or support burden?
If your team cannot answer these questions quickly, start with a focused funnel audit. My marketing audit and consulting services can help turn scattered events and CRM journeys into a prioritized experiment plan.
The takeaway
KYC drop-off is a set of distinct problems, not one audience segment. Diagnose the state, verify the data, listen to users, then test one change at a time while keeping verification requirements intact.
If you want an independent review of your signup-to-verification journey, see my growth and marketing audit services or email me the funnel stage you want to improve.