KYC for business: how to build a process with high conversion and manageable risk

How to set the target balance between conversion and risk

Which check to apply to which customer? Excessive verification drives away bona fide users; insufficient verification opens access to fraudsters and violates regulatory requirements. The verification level should be determined by the risk profile of the specific customer rather than by a single standard for the entire application flow.

Where a basic scenario is enough and where enhanced verification is needed

The answer to this question determines the architecture of the entire KYC process. In international practice — enshrined in FATF Recommendation 1 and Recommendation 10 — it is customary to distinguish three verification levels depending on the customer’s risk profile.

Simplified Due Diligence (SDD) is applied when the customer’s risk is objectively low: publicly traded companies from jurisdictions with a strong AML regime, regulated financial institutions, government entities. For such customers, it is permissible to reduce the volume of documents collected and lower the intensity of monitoring. Importantly: SDD does not cancel sanctions checks — they are mandatory in any scenario.

Customer Due Diligence (CDD) is the basic level for most customers: individuals, small and medium-sized businesses, retail users without explicit risk factors. It includes document verification, biometric identification, checking against sanctions lists, and PEP status screening.

Enhanced Due Diligence (EDD) is mandatory when high-risk factors are present: the customer is a politically exposed person (PEP) or connected with one; the customer is registered or conducts activity in a jurisdiction from the FATF high-risk list (last updated in February 2026); the business belongs to sectors with an elevated exposure to laundering — cryptocurrency exchanges, casinos, trade in luxury goods or weapons. EDD implies a deeper verification of the source of funds, approval from senior management, and enhanced subsequent monitoring.

The criteria for distinguishing scenarios are fixed in the company’s risk management policy and must be documented: the regulator assesses not only the fact of the check but also the logic of assigning the risk level. Chaotic escalation or the systematic underestimation of the level — both variants create regulatory and reputational risks.

Which conversion, speed, and verification quality metrics to consider as targets

Without measurement there is no management. For the KYC process, it is critical to track several interconnected groups of indicators simultaneously — optimizing one at the expense of another gives a false sense of progress.

Conversion and churn. According to a global study by Fenergo (600 financial institutions, 2025), 70% of companies lost customers over the past year specifically due to inefficient onboarding — a growth compared with 67% in 2024 and 48% in 2023. In a broader sample of financial services, it is estimated that up to 63% of potential customers do not complete registration. For a specific product, the target benchmark for conversion is determined based on the industry benchmark, the complexity of the product, and the level of mandatory verification. The general principle: each additional step in the funnel reduces conversion — and each step must be justified.

Verification quality metrics. Two key indicators are FRR (False Rejection Rate, the share of erroneous rejections of bona fide customers) and FAR (False Acceptance Rate, the share of erroneously let-through fraudsters). They are inversely related: the more aggressive the threshold values, the lower the FAR but the higher the FRR — and the greater the churn. For most onboarding scenarios, the target FAR at the stage of biometric comparison of the document and the face must not exceed tenths of a percent; FRR is to be kept at the minimum possible level for a given FAR. The specific target values depend on the product’s risk profile and must be fixed before launch rather than selected after the fact.

Processing speed. An automated document check takes less than a second, a biometric comparison — less than 100 milliseconds when modern face verification algorithms are used. From the standpoint of the customer experience, the end-to-end indicator is critical: the time from the start of the session to receiving a decision. For a standard CDD scenario in a fully automated mode, the benchmark is 1–3 minutes. Delays beyond this value significantly increase the probability of abandoning the process.

The share of manual checks. The higher this indicator, the higher the operating costs and the longer the decision-making cycle. The target value for an optimally configured process: an automatic decision (approval or rejection) is made in 80-90% of cases, and manual review remains only for borderline situations. If the share of manual cases is substantially higher, this is an indicator that the threshold values or the quality of the model require calibration.

Which regulatory and security requirements cannot be simplified

Optimizing KYC does not mean arbitrarily excluding checks. A number of requirements are unconditional: their violation entails regulatory sanctions regardless of considerations of conversion or operational savings.

Sanctions screening. Checking the customer against sanctions lists (OFAC, the UN, the EU, and regional lists, including the Russian list of terrorists and Federal Law 115-FZ) is mandatory for any verification level — including SDD. Neither the simplified procedure nor a low-risk customer profile exempts from this step. This is a direct requirement of FATF Recommendation 10, duplicated in the national legislation of most jurisdictions.

PEP screening. Checking for the status of a politically exposed person is a mandatory element of standard verification. The detection of PEP status automatically moves the customer to the EDD regime regardless of other parameters.

Record retention. Verification results, decisions made, and accompanying data must be stored for the period established by the regulator — as a rule, at least five years after the relationship with the customer ends. In Russian legislation, this requirement is enshrined in Federal Law 115-FZ; in European legislation — in the AML directives. Archiving is not an optional function of the system.

Liveness check. Protection against presentation attacks — the use of printed photographs, video recordings, or synthetic images — is not an optional enhancement. In remote identification scenarios, where the customer’s physical presence is not confirmed by other means, liveness/PAD constitutes a mandatory layer of protection against identity fraud. Disabling this check or lowering its sensitivity to increase conversion creates a vulnerability that attackers exploit systematically.

Ongoing monitoring. A one-time verification at onboarding does not fully close the regulator’s requirements. The customer’s transactional behavior and risk profile must be reviewed throughout the entire lifecycle. The specific frequency and triggers for review depend on the assigned risk level and industry requirements — this question is examined in detail in the corresponding section of the article.

How to build remote KYC into customer onboarding

Onboarding is the first point of real contact between the customer and the product, and it is here that KYC becomes either an invisible step or a barrier because of which the user leaves. According to the same Fenergo study (2025), the average level of incomplete applications during KYC in financial services is about 10%. This figure can be reduced not by simplifying the checks but by their correct integration: at the right moment, with the minimum necessary set of steps and a clear division of the flows into automatic approval, manual review, and rejection.

At which stage of onboarding to request documents and a selfie

The key principle is to request verification when the user already has a reason to pass it rather than at the very beginning, when they have not yet decided to stay.

In practice, one of two models works depending on the regulatory requirements and the risk level of the scenario.

Deferred verification is suitable for services where access to the basic functionality is possible before full identification. The user registers with minimal data (email, phone), gets limited access, and passes KYC at the moment they reach a trigger action: withdrawing funds, exceeding a transaction limit, accessing financial instruments. This approach reduces the initial friction and gives the user time to be convinced of the value of the product before being asked to upload a passport.

Upfront verification is mandatory where it is directly prescribed by the regulator: financial organizations under Federal Law 115-FZ, payment services, crypto exchanges. Here KYC is a condition of admission, and there is neither a legal nor a technical possibility of deferring it. In such scenarios, the task is to make the data collection as fast and clear as possible: one screen for the document, one for the selfie, no excessive manual-entry fields.

How to check the document, the face, and the live presence

Full-fledged remote identity verification is built from three sequential levels of checking, each of which closes off a separate class of threats.

The first level — document verification. The user photographs their identity document or uploads a scan of it. The AI-OCR (Intelligent Document Processing) system extracts the text fields, determines the document type and country, checks the machine-readable zone (MRZ), and assesses the integrity of the security features: fonts, microprint, holograms, zone structure. In parallel, the image quality is analyzed: overexposure, blur, framing, signs of digital retouching. Sufficient image quality is a necessary condition for the correct operation of all subsequent modules.

The second level — biometric face comparison. The system compares the photo from the document with the selfie taken during the session. This is a one-to-one comparison (face matching 1:1): the system calculates a similarity score and compares it with a threshold value. The quality of the comparison directly depends on the quality of the document photo and the conditions of the selfie shot — poor lighting and blur reduce accuracy regardless of the power of the algorithm.

The third level — the live presence check (liveness/PAD). The task is to make sure that a live person is in front of the camera rather than a photograph, a video recording, a mask, or a deepfake. Two approaches are distinguished: passive liveness analyzes a single frame or a series without any actions on the user’s part; active liveness requires a gesture (blink, turn the head, smile). The passive approach gives less friction and is preferable from the standpoint of conversion, but the active one is more resistant to a number of attacks with synthetic artifacts.

The industry standard for assessing the resistance of liveness modules to attacks is ISO/IEC 30107-3 — an international standard for testing protection against presentation attacks (PAD). Level 1 checks resistance to basic attacks: photographs, video recordings, paper masks. Level 2 tests protection against more complex artifacts: realistic masks made of resin, latex, and silicone, synthetic faces. Confirmed compliance with ISO/IEC 30107-3 is the minimum standard for regulated scenarios.

All three levels are built into a single pipeline: a failure at any of them means that the session cannot be automatically approved without an additional check.

When to connect anti-fraud, database checks, and AML

The anti-fraud layer, the basic checks, and AML screening solve different tasks and are launched at different times — mixing them or putting them sequentially in a queue leads to unnecessary delays.

Anti-fraud starts working earliest of all — from the moment the session opens. Before the user has uploaded the first document, the system is already analyzing technical and behavioral signals: an emulator or a real device, a VPN or a non-standard IP, the speed of interaction, atypical form-filling patterns. This is called device intelligence and behavioral signals — they are launched in parallel, not adding time to the user path. Based on the initial session, a preliminary fraud score is formed, which is supplemented with data from document verification and liveness. In mature systems, anti-fraud includes 30-40 algorithms covering documentary, behavioral, and technical anomalies.

Database checks (FSSP, tax debt, bankruptcy registers, court decisions, wanted lists, full-name-to-phone and full-name-to-email links) are advisable to launch after the document has been successfully recognized and identified. It is precisely at this moment that the system has the verified full name, date of birth, and other identifiers necessary for the query. Such checks are performed asynchronously — in parallel with liveness and biometric comparison, so as not to lengthen the wait.

AML screening (checking against sanctions lists, PEP lists — politically exposed persons, adverse media) is mandatory for financial organizations under Federal Law 115-FZ and the international FATF standards. Its launch is logically tied to the moment when the document is verified: it is then that the customer’s identifiers are reliable enough for the screening results to have legal force. Sanctions list screening delivers a result within seconds; an adverse media check — a bit longer depending on the depth of source coverage. If necessary, the AML results arrive as a separate attribute in the final decision on the case.

The architecture rule: everything that can work in parallel should work in parallel. A sequential chain of “document → face → liveness → databases → AML” increases the total verification time by a factor of 3-4 compared with a parallel pipeline without any gain in decision quality.

How to divide automatic approval, manual review, and rejection

The output of the KYC pipeline is not a binary “yes/no” but three decision categories, each of which requires separate threshold settings and operational rules.

Automatic approval — cases with a high level of system confidence across all checks: the document is recognized, the security features are normal, the face match is confirmed, liveness is passed, the fraud score is low, the databases are clean. Such cases are completed without human involvement within a few seconds. A realistic benchmark for a mature scenario with quality content is 70-85% of automatic decisions; the specific value depends on the document type, the geography of the users, and the configured thresholds.

Manual review — cases with uncertainty: poor photo quality, a disputed liveness result, a borderline fraud score, a data discrepancy between the document and a database, a non-standard document type. Such cases are routed to operators with a full package of data: images, extracted fields, the results of all checks, flags, and the reasons for the uncertainty. The SLA for manual review — as a rule, from 15 minutes to several hours depending on the type of service — must be defined in advance, and the expected response time communicated to the user immediately after the application is submitted. Transparency of the wait substantially reduces churn at this step.

Automatic rejection is applied in the case of unambiguous signs: clear manipulations with the document, a critical liveness failure (an attack recorded with high reliability), a match on a sanctions list or a wanted list, exceeding the acceptable fraud score threshold. The reasons for rejection are recorded in the log with codes — this is necessary both for the regulator’s audit and for the internal analysis of false rejections.

How to increase conversion without a growth in risk

Most losses in the KYC funnel are not connected with the customer being a fraudster or deliberately evading verification. Users leave because of excessive steps, unclear errors when uploading a photo, and the absence of a second chance in case of a technical failure. Eliminating them is a task of precisely tuning the process rather than weakening the checks.

How to remove unnecessary fields and steps

Every excess screen in the KYC flow is a standalone exit point from the funnel. The optimization principle is simple: request only what is genuinely necessary at the current stage and for the specific verification level.

Autofill from the document. If the system has already extracted the data via AI-OCR — name, date of birth, document series and number — re-entering these fields manually does not add accuracy but creates friction. The data from the recognized document is substituted automatically; the user only checks and confirms. Depending on the document type, this reduces the number of manual fields by 60-80%.

Phased data collection. Registration — a minimal identifier (email or phone number). Identity verification (document + selfie) — only when moving to an action that requires it. An extended profile (address, source of income, additional documents) — only when raising a limit or reaching a level that requires in-depth verification on regulatory grounds. This approach — progressive disclosure — reduces the perceived load and retains the user at exactly the moment when they are ready to move on.

Eliminating duplicate confirmations. A typical unnecessary step is re-uploading a document if a quality image has already been saved from a previous session, or confirming an email in a flow where the phone number has already been verified. Each step must be justified: either it collects new data or it performs a check unavailable based on the existing data. Everything else is a candidate for removal.

How to reduce rejections due to photo and video quality

A significant share of incomplete KYC sessions is technical capture problems: a blurred image, glare on the document, insufficient lighting when taking the selfie, partial capture of the document in the frame. Such losses are not connected with the customer’s risk level and are eliminated at the level of the interface and preprocessing.

On the client side — real-time guidance during the shoot: a visual frame indicates how to position the document; autocapture triggers only when the quality threshold is reached (sufficient sharpness, even lighting, the absence of glare). The prompts “remove the glare”, “bring it closer”, “turn toward the light” must appear at the moment of the problem — not after clicking “Submit”. Feedback before submission fundamentally reduces the share of poor-quality images that enter the system.

On the server side — preprocessing before the image is passed to OCR and face matching: perspective correction, glare suppression, exposure equalization. This makes it possible to accept shots that look visually imperfect but contain enough information for accurate recognition. Additionally: an Image Quality Score assessment before the full check cycle is launched. If the shot is below the threshold, the user gets a request to retake immediately, without an unnecessary processing delay.

How to configure a retry and a transfer to an additional check

Not every unsuccessful result is grounds for rejection. The type of error determines the user’s route.

Three basic routes after a failure:

Category	Description
The first — a retry	Applied when the cause is technical: low image quality, poor lighting, the document out of frame. The user gets a specific instruction and the opportunity to retake. The acceptable number of attempts is, as a rule, two to three; after that, the system moves to the next route.
The second — an additional check	Applied for borderline results: a confidence score near the threshold value, a minor data mismatch, a document from a category with high formatting variability. The case goes to manual verification with a full package of data and flags for the reason. For the user, this should not look like a rejection: a “processing” status with a clear response time preserves conversion and does not create unnecessary anxiety.
The third — a rejection	Issued for clear signals of fraud: signs of document forgery, a biometric mismatch above the acceptable threshold, a match with anti-fraud databases. The rejection is formed unambiguously — without an offer to retry in a few minutes with a different document.

An operational detail that is often missed: in your analytics, separate the causes of each failure by route. A growth in the share of cases going to an additional check is a signal to reconsider the threshold values or refine the capture for a specific document type. A growth in the share of retries with a successful completion is a sign of working real-time guidance, but with potential for improvement.

The key end-to-end metric is the auto-approval rate: the share of applications that passed fully automatically without manual intervention. With a mature, configured process, most low-risk applications should pass without an operator. A significant deviation from the planned level is a sign of either excessively strict thresholds, or problems with capture quality, or a growth in fraud in the channel. Each of these cases requires a different action: the first two are solved by configuration, the third — by tightening the anti-fraud rules.

How to keep risk manageable after launch

Launching a KYC process is not the finish line but the beginning of an operational cycle. The customer profile changes: documents expire, new transactional patterns appear, sanctions lists are updated. The risk that was acceptable at the moment of onboarding may grow substantially several months later without additional checks. The task of post-launch management is to identify such changes in a timely manner without overloading the system with excessive checks where the situation has not changed.

Which events trigger a repeat customer check

The triggers for repeat verification fall into two types: scheduled and event-driven. Distinguishing them is fundamental, because they solve different tasks.

Scheduled re-verification is tied to the customer’s risk category. The logic of the risk-based approach, enshrined in the FATF recommendations and translated into the regulatory requirements of most jurisdictions (Federal Law 115-FZ for Russian companies, 4AMLD/6AMLD in the EU, the BSA in the US), prescribes reviewing the customer’s profile with a frequency corresponding to their risk level. For high-risk customers — at least once a year, for medium-risk ones — once every two to three years, for low-risk ones — once every five years or upon a material change in circumstances. These intervals are not universal: the industry regulator has the right to narrow them, and the company’s internal policy — to tighten them.

Event-driven triggers are more important than scheduled ones, because risk does not wait for the next cycle. Typical signals for an unscheduled check:

• a sharp change in the transactional profile — a growth in turnover, an atypical geography of payments, a switch to new payment methods without an explainable reason;
• a login from a new device or geolocation incompatible with the historical patterns;
• the expiration of the document used at onboarding;
• the customer’s inclusion in updated sanctions lists, PEP registries, or adverse media;
• a complaint or an incident directly connected with the account;
• for legal entities — a change of the UBO (ultimate beneficial owner) or key directors.

Which thresholds and rules need to be calibrated regularly

After a KYC system is launched, the threshold values — biometric comparison scores, liveness detection thresholds, anti-fraud engine rules — begin to “age”. The composition of the audience changes, attacking techniques evolve, data on real cases accumulates. A threshold set at the start based on reference data may, after three to six months of real operation, either let through new types of fraud or reject bona fide users with atypical shooting conditions.

What exactly is calibrated:

Biometric thresholds. The face similarity threshold in face matching affects the ratio of FAR (False Acceptance Rate, letting a fraudster through) and FRR (False Rejection Rate, a false rejection of a bona fide user). Tightening one parameter worsens the other. The optimal point depends on the audience profile, the type of devices, and the target risk level. It needs to be recalculated on a current sample — not on test data from six months ago.

Anti-fraud engine rules. Signs that were valid fraud markers at the moment of launch may lose their discriminating power. New attack vectors — in particular, deepfake injections, the complexity of which, according to a number of vendors, grew by more than 30% in 2024 — require adding new signs and reworking the weights of existing rules. Rules based on hard-coded conditions (IP ranges, device lists) require more frequent updating than models based on anomalous behavior.

AML screening thresholds. Sanctions databases and PEP lists are updated continuously. The rules by which the system prioritizes alerts must take into account the current composition of these databases rather than the version as of the launch date.

A practical benchmark: each calibration iteration requires three components — a sample of cases for the period (approved, rejected, and routed to manual review), current FP/FN statistics for each rule, and the operators’ recorded decisions on disputed cases. Without this data, calibration turns into manual tweaking without a basis in facts.

How to track false rejections and erroneous approvals

False rejections and erroneous approvals are two opposite in nature but equally costly types of errors. A false rejection (FRR) — a bona fide customer did not pass the check. An erroneous approval (FAR) — a fraudster passed. The first hits conversion and reputation, the second — security and compliance.

The problem is that these errors are not symmetrical in visibility. An erroneous approval is recorded by the system after the fact — when an incident has already happened. A false rejection is often not registered as an error at all if the customer simply leaves without trying to appeal the decision. Both categories require specially built monitoring.

To track false rejections it is necessary to:

• Introduce an appeal channel and record how often it is successful. If the operator overturns the automatic decision in 10% of cases or more — this is a signal to reconsider the thresholds.
• Analyze the reasons for rejections by breakdown: image quality, a face mismatch, a liveness failure, a rejection based on document data. If one category dominates, the problem is not in the threshold but in the UX or the quality of data capture.
• Measure the share of customers who reapplied after a rejection, and the conversion of the repeat attempts. A growth in this indicator says that the problem is fixable on the client side; its decline — that the system cuts off valid users too rigidly.

To track erroneous approvals it is necessary to:

• Conduct a regular selective audit of approved cases — especially those that passed near the lower boundary of the threshold range.
• Track post-approval signals: violations by previously approved customers, their appearance in fraud incidents, the triggering of AML alerts. Correlate these events with the characteristics of the profile at the moment of onboarding — this makes it possible to retroactively check whether there were warning signals that the system missed.
• Separate the metrics by verification channel: mobile application, web widget, SDK. Different channels give different data quality and distribute errors differently.

According to a KYC2020 study, traditional AML screening systems generate a share of false positives in the range from 42% to 95% of the total number of alerts. This means that most signals are not threats but noise that overloads the manual review team and masks real risks. A transition to AI models trained on current data makes it possible to reduce the share of false positives by 50-66%, according to the same studies. The reduction remains sustainable only with the regular retraining of the models on a current sample — a static model degrades as the audience profile and fraud patterns change.

The final principle: risk is manageable not when the system is launched but when it is observable — when every decision is traced, every error is categorized and becomes the input data for the next calibration cycle. It is precisely this that turns KYC from a one-time compliance step into a living risk management loop.