The KYC Funnel: How to Increase Verification Completion and the Approval Rate Without Slowing Down the Decision

How to Measure the KYC Funnel

Before optimizing the KYC funnel, you need to make sure that all three of its key metrics are measured correctly and consistently. It is precisely the discrepancies in how the entry point, the exit point, and the calculation method are defined that most often distort the picture: teams compare incomparable numbers and make decisions based on incorrect data.

What Counts as the Entry and Exit of the KYC Funnel

The funnel entry is the moment when the user takes their first deliberate action within the KYC scenario: opens the verification screen, clicks the «Start verification» button, or moves to the first data-collection step. It is this event that is recorded as the starting point — not the moment of registration or sign-in within the product. The distinction is fundamental: if you include all registered users in the funnel, including those who never opened KYC, the metrics will be artificially deflated and will cease to reflect the real effectiveness of the verification process.

The funnel exit is the moment when a final decision has been made on the application: «approved», «rejected», or «sent to manual review». Manual review is counted as a separate status rather than a final decision — it becomes final only after the operator finishes reviewing the case. If you conflate «sent to operator» with «approved», the approval rate will be overstated and the real time to decision underestimated.

Separately, you need to fix the unit of analysis: session or user. A single user may start KYC several times — for example, after a failed attempt. Unique users show the real user experience; sessions show system problems: overload of individual steps, technical failures, device dependence. Both views are needed, but they cannot be mixed in a single report.

How to Measure Verification Completion, the Approval Rate, and Time to Decision

Completion rate (verification completion) is the share of users who reached the final step and submitted all the required data, out of those who started verification:

CR = (Number of completed applications / Number of started ones) × 100%

The metric measures the drop-off within the process itself — before the system began checking. The normal range varies substantially depending on the complexity of the scenario and the audience, but as a reference point: processes with a single document type and no additional steps reach a CR of 85–95%; multi-step scenarios with biometrics, several documents, and additional checks — 60–80%. If the CR is consistently below the expected range, the cause usually lies in the UX, technical failures, or an overly complex scenario — not in the quality of the verification algorithms.

Approval rate is calculated from the number of completed applications, not from all started ones:

AR = (Number of approved / Number of completed applications) × 100%

This is fundamental: if you include incomplete attempts in the denominator, the metric will mix two different problems — drop-off at the data-collection steps and the quality of the check itself. By separating them, the team understands exactly what to work on: the UX and instructions (if the CR is low) or the thresholds and algorithms (if the AR is low while the CR is high).

Time to decision is the median and the 95th percentile of the time from the moment the user submits the final data package to the moment they receive a decision. The median shows the typical experience, and p95 shows the «tail», which is most often formed by manual-review queues or timeouts of external checks.

All three metrics need to be tracked across breakdowns: channel (web / mobile app), document type, document country, and risk segment. An aggregate figure hides local failures: an overall CR of 78% may mean 92% for Russian passports and 40% for foreign ones — and these are fundamentally different optimization tasks.

Where the KYC Funnel Loses Users and Approvals

Funnel losses are not concentrated at a single point: they are distributed across three fundamentally different stages, each of which requires separate diagnosis — before the user began submitting data, at the moment of automatic verification of documents and biometrics, and at the stage of risk assessment and manual review.

Losses Before Documents and the Selfie Are Submitted

Some users leave the funnel before the system has received even a single file. These are losses unrelated to the quality of verification — they are purely behavioral.

The main reason for early abandonment is a lack of readiness for the process. According to a Signicat study covering more than 7,600 consumers in 14 European countries, 38% of users abandoned onboarding simply because they did not have the required documents on hand at the moment they went through it. Another 21% indicated that the process took too long, and the same share said that the volume of personal data requested seemed excessive to them.

Meanwhile, users’ tolerance for delays is declining: whereas in 2020 the average user was willing to wait about 26 minutes before abandoning an application, by 2024 this threshold had dropped to 18 minutes 53 seconds. Expectations are shaped by the entire digital experience, not just KYC: the faster other services work, the less tolerant the user is of slow onboarding.

The second reason for early abandonment is a lack of transparency at the start. If the user cannot see in advance what exactly will be required — which document type, whether a selfie is needed, how many steps lie ahead — they perceive the unknown as a heavy burden and prefer to leave. These losses occur before the verification point and are not recorded as technical failures — the users simply vanish from the funnel without a trace.

Losses at the Document and Biometrics Verification Stage

The second and technically most studied point of loss is the stage of automatic processing of the uploaded data. Here the funnel loses both users (drop-off) and approvals (false rejections that are the fault of the system, not the user).

The most vulnerable point at this stage turns out to be the transition from document upload to the biometric check. An analysis of behavioral analytics at one European digital bank revealed a 45-percent drop-off at precisely this transition: users were not abandoning the account opening — they were failing to complete a specific technical step and did not understand what they were doing wrong.

The root of the problem is delayed feedback. If the system needs several seconds or minutes to process, and the response arrives as a generic error («document not recognized»), the user receives no instructions for fixing it. They make another attempt at random, get the same result, and leave. The quality of the interface at the moment of capture — angle, lighting, positioning in the frame — directly affects whether the image falls within the acceptable range for the algorithm.

Losses at Risk Checks and Manual Review

The third point of loss is less obvious but systemically significant — and it lowers both the completion rate and the approval rate at the same time.

The first source of loss here is excessive false positives from automatic risk filters. Studies and industry reviews, including those citing Gartner analytics, record that in legacy transaction-monitoring systems the share of false positives can reach 90–95%. In the KYC context this means: a significant share of legitimate users get flagged because of overly strict or improperly calibrated rules — a name matching a sanctions list, an atypical registration geography, a rare document type. Systems without risk segmentation apply the same thresholds to everyone: to a client from a low-risk jurisdiction and to a potentially high-risk profile alike, creating unnecessary friction where it is not needed.

The second source of loss is the manual-review queue. Cases that did not pass an automatic decision are routed to operators. If the share of such cases is high and the team is limited in resources, the waiting time for a decision grows from hours to days. According to a Fenergo study of more than 450 C-level bank executives, 77% name processing delays as one of the key factors leading to the loss of customers at the onboarding stage. A user who has completed all the verification steps but has not received a decision within a reasonable time is highly likely to leave — especially if a competing service is ready to accept them faster.

How to Increase Verification Completion

Completion rate is the share of users who reached the final step and submitted the full data package, out of all who started verification. This metric depends not only on the user’s motivation but also on how constructively the verification scenario is designed for completion.

Trim the Scenario to the Minimum Sufficient

Every additional step in the KYC scenario is a point at which some users leave. This is not a hypothesis but a direct consequence of how any multi-step user journey works: each screen lowers the probability that the next one will be opened.

A practical approach is progressive KYC: at the first level, only what is necessary for a decision on basic access is requested, and only when a risk threshold is exceeded does the user go through extended verification. This model is directly enshrined in the FATF guidance as permissible under a risk-based approach — a simplified procedure is sufficient for clients with a low risk profile.

Concretely, this means removing from the critical path everything that does not affect the decision for a specific user segment. If a second document is not required to assess risk — do not request it at registration. If manual data entry duplicates what AI-OCR extracts from the document — remove the manual entry. If the email confirmation step affects neither identification nor compliance — move it outside the KYC funnel.

Check the Quality of Documents and Selfies at the Moment of Capture

One of the most common causes of non-completion is not the user’s unwillingness to pass verification, but repeated attempts due to poor-quality images. The user submits a photo of the document, waits for processing, receives an error, and either makes a new attempt or abandons the session. With each such iteration, the share of those who give up on continuing grows.

The solution is to move quality control to the client side and perform it before submission rather than after. At the moment of capture, the SDK or a webcam widget analyzes in real time:

• blur and sharpness of the frame;
• sufficiency of lighting and the absence of overexposure/shadows;
• completeness of the document capture (all four corners in the frame);
• the absence of glare on the laminate or a glossy surface;
• the correspondence of the proportions and outlines to the expected document type.

The same logic applies to the selfie: the openness of the face, the sufficiency of lighting, the absence of tinted glasses, and the head-turn angle are all checked.

The user receives an instant prompt — «turn the document», «remove the glare», «move closer» — and takes another shot before submitting. This eliminates the «submit → wait → receive an error» loop and directly increases the share of applications that pass verification on the first attempt. Client-side validation does not replace server-side validation, but it filters out obvious defects before they even enter the processing queue.

Return the User to an Unfinished Verification Without Re-Entering Data

Some users interrupt KYC not because they do not want to finish it — they were distracted, lost connection, or their device ran out of battery. If, upon returning, the system greets them with an empty form from scratch, a significant share of such users will not redo the steps they have already completed.

A session-recovery mechanism solves this problem. The principle: each completed step is saved on the server immediately, rather than upon the final submission. Upon returning, the user sees the funnel in exactly the state where they left off: the data they have already entered is prefilled; the documents they have already uploaded do not need to be uploaded again; the steps they have already completed are marked as finished.

Trigger-based reactivation also works: a push notification, SMS, or email is sent within a few hours of the interruption with a direct link that returns the user precisely to the unfinished step rather than to the home page. The time window is most effective in the first 24 hours — the longer the pause, the lower the probability of return.

For this, the session identifier must be persistent — not tied to a specific device or browser: a user who started verification on their phone and returned on a desktop should land at the same point.

How to Increase the Approval Rate

Verification completion and its positive outcome are different metrics with different points of loss. A user may go through all the steps, provide all the data, and still receive a rejection — not because they are a fraudster, but because the system is configured too strictly, does not support their document, or does not see enough data for a positive decision. It is precisely here that a significant part of the approval rate is lost.

Eliminate False Rejections in Automatic Verification

A false positive is a situation where the automatic system rejects a legitimate user, mistakenly classifying their application as suspicious. The direct losses are obvious: the rejection of a real customer. Less obvious are the indirect ones — reputational costs and an increased load on operators, who are forced to review cases that did not originally require manual review.

The mechanics of a false positive are not uniform, and each source has its own point of intervention.

Overly broad matching rules. Models that make a decision based on a single signal — for example, a name matching a sanctions list without taking into account the date of birth, nationality, or additional context — inevitably generate excessive alerts. The solution: move from «OR» rules to «AND» rules with additional distinguishing attributes that lower the probability of matching namesakes or technical artifacts.

Fixed thresholds without adaptation to context. A single similarity-score threshold for comparing a face with the photo in a document cannot work equally well for a low-quality front camera and a professional scanner. If the threshold is set for the best case — high clarity and perfect lighting — the system will reject correct attempts made with budget devices or under suboptimal conditions. Thresholds must take into account image quality, device type, and attempt history.

The absence of aggregated scoring. If each check — document, liveness, face matching, AML — makes a decision autonomously, without aggregating context, the final decision is composed of a logical AND of several rigid thresholds. Any one of them can block a legitimate user. Aggregated scoring with weighting coefficients for each signal works more accurately than a sequential set of binary filters.

The first step toward reducing false positives is quantifying them: breaking down rejections by reason and analyzing the share of those that are not confirmed by any additional fraud signal. It is precisely this share that constitutes the reserve for growing the approval rate without compromising compliance.

Revise Thresholds and Routing by Risk Segment

A single set of rules for all users is a compromise that simultaneously lets through part of the real fraud and blocks part of the legitimate applications. A more precise model involves risk segmentation and differentiated routing.

According to McKinsey, high-risk clients typically make up less than 5% of the incoming flow. This means that a standard verification flow configured to counter high risk overloads more than 95% of users with checks. At the same time, according to 2024 data, only about 29% of financial organizations use a tiered methodology — an approach in which the depth of verification is determined by the risk profile of the specific applicant, rather than applied uniformly to everyone.

At the funnel entry, each applicant receives a preliminary score based on available signals: geo-attributes, device type, IP, phone number, behavioral session patterns. It does not replace the KYC check, but it divides the flow into segments:

• Low risk — a reduced set of checks, automatic approval upon passing the basic threshold, without a manual route.
• Medium risk — the standard scenario: document + liveness + face matching + automatic AML screening.
• High risk — an extended set: additional data sources, enhanced document verification, a route to manual verification.

The key effect of this approach is that approval thresholds are configured separately for each segment. For the low-risk flow, borderline score values can be interpreted more leniently; for the high-risk one, more strictly. This yields a rise in the approval rate without lowering compliance quality, because strictness is applied where it is needed, rather than everywhere at once.

A separate point is the regular revision of thresholds. The distribution of risks in the flow changes: new fraud schemes appear, the geography shifts, sanctions lists are updated. Thresholds that were optimal six months ago may today either let through too much or block too much. Scheduled calibration — once a quarter or when there is a significant change in the incoming traffic profile — is a mandatory part of funnel management.

Expand Document and Data-Source Coverage

Some rejections are not related to the quality of the check — they are caused by the fact that the system simply cannot work with the document the user provided, or cannot make a positive decision due to a lack of data.

The document coverage problem. If the platform supports only passports and driver’s licenses of standard jurisdictions, a user with a regional national ID, a document of a non-standard format, or a document issued in a country with an unestablished template base will receive a technical rejection — not because they are unreliable, but because their document is unknown to the system. For platforms with an international or multi-regional audience, coverage by document type is directly a matter of conversion: every unsupported format means a guaranteed rejection for an entire segment of users.

The problem of data sufficiency for a decision. An automatic system may correctly recognize the document and biometrics but have no grounds for approval if there is not enough additional data to confirm the profile. Here, enrichment with data from external sources comes into play: verification of the phone number and its usage history, confirmation of the full-name–contact-data link, checks against government registries (tax status, existence of debts, court cases) and compliance databases (sanctions, PEP, adverse media). Each additional source confirming the applicant’s legitimacy reduces uncertainty and makes it possible to reach a positive decision where previously the application would have had to be sent to manual review or rejected.

How Not to Slow Down Time to Decision

Time to decision — the time from the moment the user submits their data to the moment they receive a response about the status of the check — directly affects conversion and the user experience. A delay of more than 30 seconds in an automatic check noticeably increases abandonment due to waiting; a multi-hour wait in manual review leads to a significant share of users not returning for the result. Acceleration here is built on architectural and organizational solutions, not on simplifying the verification requirements.

Before the Decision, Run Only Blocking Checks

A blocking check is one without whose result a decision on the application is fundamentally impossible: as a rule, this is extraction of data from the document, face verification and liveness, and a basic anti-fraud rule. Everything else — extended AML, device scoring, profile enrichment with data from external registries — is not blocking by default.

The risk-based approach, enshrined in the FATF Recommendations and the EU AML directives, directly permits making a preliminary decision with subsequent additional control for clients with a low and medium risk level. In practice this means: the user gains access to basic functions immediately after passing the key steps, while the extended checks are completed in the background. If the background control reveals a discrepancy, access is restricted and the decision is revisited.

Run Independent Checks in Parallel

In a sequential KYC pipeline, each step starts only after the previous one has finished. If each of the five checks takes an average of 1–2 seconds, the total time easily exceeds 8–10 seconds — and that is without accounting for network delays and queues. With parallel execution of independent steps, the total time is determined by the longest check rather than by their sum.

The following operations are data-independent and can be launched simultaneously:

• screening against sanctions lists and PEP — the name and date of birth extracted by OCR are enough, there is no need to wait for the liveness result;
• phone and email verification — launched immediately after collecting the contacts, in parallel with document processing;
• device and behavioral anti-fraud signals — collected in real time, independent of the progress of the document check;
• the database of previously rejected applications — can be checked by the document hash immediately after upload.

To implement parallel routing, it is enough to move the pipeline architecture to an event-driven model: each module subscribes to events signaling the readiness of the data it needs, rather than waiting for the entire previous step to finish. In SaaS solutions, this pattern is implemented at the orchestrator level; in on-premises configurations, through a message broker with an explicit dependency graph between steps.

Limit the Share of Manual Review and the Waiting Time

Manual review remains the most unpredictable and scale-dependent link in the funnel. As volumes grow, the queue is the first to become overloaded: operators work at a fixed throughput, whereas the flow of applications can increase several times over. A controlled time to decision is possible only when the share of manual review is kept within predefined limits.

The target benchmarks vary depending on the industry and regulatory requirements, but for mature automated KYC systems the typical range is 3–10% of the total number of applications. If the figure is higher, the cause is usually inflated confidence thresholds, insufficient document-type coverage, or overly broad escalation rules.

Several approaches are used to keep the share of manual review within norm. The first is graduated confidence thresholds: applications with a high score pass automatically, those with a low score go to review, and the intermediate range is routed into a separate segment with a simplified review interface (the operator sees only the reason for doubt, rather than the whole case from scratch). The second is limiting the queue by SLA: if an application waits for manual review longer than the set time (for example, 4 or 8 hours), an automatic action is triggered — notifying the user with an explanation of the status, escalation within the team, or, for segments with acceptable risk, temporary partial approval with subsequent further investigation. The third is a regular audit of escalation reasons: if a significant share of «manual» applications ends in approval without substantial changes, the corresponding routing rule should be revised.

Reducing the share of manual review is not equivalent to lowering compliance control. It makes sense to focus the operator resource on genuinely disputed cases and high-risk segments — it is precisely there that manual review adds value that automation does not provide.