When a retake is genuinely needed
There are three situations where it is precisely the quality of the shot that prevents AI-OCR from extracting the data and making a correct decision. The source image physically does not contain the information necessary for verification, and retaking is the only way to continue the check.
A blurred photo and glare on the document
A smartphone camera focuses on the nearest contrasting object. If the user photographs a passport at a distance of less than 15–20 cm or holds the phone unsteadily, the system gets a frame in which the text fields are smeared to the point that the OCR model is unable to separate adjacent characters. At an effective resolution below 300 dpi, small print and the machine-readable zone (MRZ) turn into a solid stripe.
Glare creates the opposite problem — an area of the image is oversaturated with light, and the pixels in it contain only white without text information. Laminated documents (ID cards, driver’s licenses, plastic passports) glare especially strongly. If the overexposed area covers the surname, date of birth, or document series, AI-OCR returns an empty field, and the check stops.
Both defects are unrecoverable by post-processing. Sharpening algorithms improve the visual perception of the frame but do not recreate data that is not in the source pixels.
The only way out is a new shot under diffused lighting with the device fixed parallel to the surface of the document.
Cropped edges and an incomplete document
It is not enough for the system to see the surname and date of birth — it must make sure that the frame contains the entire document in full. There are three reasons.
First, cropped edges deprive AI-OCR of the ability to determine the document type. The classifier relies on the geometry of the form, the location of the zones, and the security features. If the right edge of the passport is cut off, the algorithm does not see the MRZ and cannot confirm that this is indeed a passport rather than an enlarged fragment of another document.
Second, the anti-fraud module analyzes the integrity of the form: the continuity of the background mesh, the location of the guilloche patterns, the uniformity of lighting across the entire area of the page. Cropping destroys some of these signals, and the system cannot distinguish a real document from a pasted-in fragment.
Third, for a number of documents the check requires several pages or sides. For an internal RF passport, the data is extracted from both the page with the photograph and the registration page. If the user uploads only one side of an ID card, the system gets an incomplete set of fields and is forced to request a retake of the missing side.
The problem is removed by a correct capture frame in the interface: it shows the user that the document has fully fit into the frame before the shot goes to the server.
A screenshot, a copy, or a photo not of the original
When a user uploads a screen screenshot, a photo of a photocopy, or a shot of a document from a monitor, the text in the image may be perfectly readable. OCR will extract the surname, number, and date without errors. Nevertheless, such a frame is rejected — and rightly so.
A photo from a screen or a copy does not make it possible to check the physical security features: holograms, microprint, tactile relief, luminescent marks. Without these signals, the anti-fraud module cannot assess the authenticity of the form. A copy also rules out the analysis of the depth and texture of the surface — the features by which the system distinguishes an original from a digital reproduction.
In practice, attempts to upload a screenshot or scan are most often not connected with fraud. A user may keep a photo of their passport in the phone gallery and decide that it is more convenient to send a ready file than to get out the document. But the regulatory requirements for remote identification prescribe capturing the image directly from the device’s camera.
To prevent such attempts before upload, SDK components for document capture block the selection of files from the gallery and open only the camera in real time. This removes the very possibility of sending a screenshot and spares the user from repeating the step.
When a new shot won’t help
Some refusals are caused by reasons that cannot be eliminated by retaking: an unsuitable document type, data discrepancies, a technical failure at the upload stage, or the triggering of anti-fraud rules. If the interface does not explain what exactly went wrong, the user does the only thing available to them — photographs the document again. The result is predictable: the same data, the same document, the same refusal. With each unsuccessful attempt, irritation grows, and the probability of completing onboarding falls.
For a business, this is a direct loss: the marketing costs of acquisition have already been incurred, while conversion is reset to zero at the last step of the funnel.
Losses at the verification stage are the most costly: the acquisition budget has been spent, and the user leaves due to an opaque refusal. To find and eliminate such break points, you need not just quality OCR but a well-built scenario — from on-device pre-validation to precise wording in error messages.
We will analyze your current onboarding process and show exactly where unnecessary retake cycles arise. Based on the analysis, we will propose a KYC scenario configuration on the NeuroVision platform with on-device frame quality control, a pre-check of the document type and validity period (recognition takes less than 1 second), and the routing of disputed cases to an operator instead of an automatic refusal. The solution is available in the cloud, on-prem, or in a hybrid version — you will choose the format that meets the requirements of your information security policy.
An unsupported or expired document
A KYC system accepts a finite list of document types: as a rule, a passport, a national identity card, a residence permit, or a driver’s license. If the user has uploaded a student ID, a work visa, or a temporary certificate, the check will be refused regardless of the quality of the shot.
The situation is similar with an expired document. AI-OCR extracts the expiration date, checks it against the current date, and records the mismatch. No angle and no lighting will change the date in the document. The user needs not to retake but to replace the document with a valid one.
A third common case is a document issued in a jurisdiction the service does not support, or drawn up in a language not included in the OCR module’s coverage. Platforms with broad coverage process thousands of document types from hundreds of countries, but even they have limitations on rare formats and scripts. If the document type is not recognized, retaking it is pointless — an alternative document from the supported list is needed.
On the product side, checking the type and validity period can be performed before sending the data for the full verification cycle. If the SDK or web widget is able to classify the document and read the expiration date on the client device, the user will get a warning immediately — without waiting for the server’s response and without a feeling of “refusal”.
An expired passport, a document of an unsupported type, the single side of a two-sided ID — all of these are reasons for refusal that do not depend on the angle and lighting. If the check of the type and validity period happens only on the server, the person wastes time waiting and perceives the rejection as an error in the shot.
The NeuroVision platform’s AI-OCR classifies more than 10,000 document types from 200 or more countries in 90 or more languages, including the machine-readable zone. The SDK for iOS, Android, and web applications performs the check of the type and expiration date directly on the device — the user sees a warning instantly, before the frame is sent. We will select a configuration for your geography and list of acceptable documents, connect the SDK, and set up pre-validation on the client side. The trial period is up to 1 month.
The application form data does not match what AI-OCR extracted
When launching a KYC check, the user usually fills in an application form: first name, surname, date of birth, document number. In parallel, AI-OCR extracts the same fields from the photograph. If the values do not match, the system records the discrepancy and blocks the check.
The causes of a mismatch are rarely connected with the photograph. Most often it is a typo in the application form, a difference in the transliteration of the name (for example, «Алексей» in the form and «Aleksei» in the international passport), the use of a shortened or double name, a discrepancy in the date format. Sometimes the user fills in the form based on one document but photographs another — enters the data of an internal passport but shoots an international passport, where the spelling differs.
Retaking in the case of such a refusal is useless: OCR will again extract the same data from the same document, and the discrepancy with the form will remain. The solution is to correct the form or upload a document whose data matches what was entered.
An approach that reduces the number of such errors is to show the user the data extracted by AI-OCR before the final submission for the check. A confirmation screen «We recognized: Ivanov Ivan Ivanovich, 12.03.1990 — is everything correct?» makes it possible for the person to see the discrepancy and correct the form themselves, before the system records a formal refusal.
A discrepancy between the application form and the document is one of the frequent reasons for refusal that cannot be eliminated by retaking. A difference in transliteration, the order of the first and last name, or a banal typo lead to OCR extracting the same data time after time while the system records a formal mismatch.
The NeuroVision platform extracts structured data from a document in less than 1 second with an accuracy of up to 99.85% for printed fields. An intermediate confirmation screen is built into the KYC scenario via an SDK or web widget: the user sees the recognized fields, cross-checks them against the application form, and corrects the discrepancy themselves, before the check is launched. We will configure the scenario so that the data confirmation step appears at the right point in the pipeline, and connect the modules from document recognition to matching against the application form fields.
An upload failure looks like a document refusal
A network timeout, a dropped mobile connection, a server error on the verification provider’s side — all of these are technical failures not connected with the document or the quality of the photograph. If the interface displays them with the same message as a substantive refusal (“The document did not pass the check”), the user perceives the situation unambiguously: the photo is bad, it needs to be retaken.
The person takes a new shot, sends it — and runs into the same failure, because the problem is in the communication channel or in the server infrastructure. After two or three unsuccessful attempts, a significant portion of users leave the process, having decided that the service “doesn’t work” or “doesn’t accept” their document specifically.
Separating technical and substantive errors is a basic requirement for verification UX. The message about an upload failure must differ from the message about a rejected document both in text and visually. In case of a failure, it is appropriate to suggest retrying the submission in a few seconds or checking the connection. In case of a substantive refusal — to explain the specific reason. Mixing these categories leads to the user losing trust in the platform, even though everything is fine with their document.
KYC rules and anti-fraud checks were triggered
Modern KYC platforms are not limited to document recognition and face comparison. In parallel, dozens of checks are launched: a search against sanctions lists and PEP databases, reconciliation with registries of invalid documents, the detection of duplicate accounts by biometrics or document number, the analysis of the device’s digital footprint, the assessment of behavioral patterns. The triggering of any of these rules can lead to a refusal, and the photograph of the document has nothing to do with it.
Typical examples: the document is listed as lost or stolen in the MVD register; the same document number is already registered in another account; the biometric face template matches a profile previously blocked for fraud; the IP address or device is associated with suspicious activity; the person is found on sanctions lists. In each of these scenarios, retaking the document is pointless — the check is refused not on visual but on logical and compliance criteria.
For security reasons, services usually do not disclose the specific anti-fraud rule that was triggered: detailing the reasons could help fraudsters bypass the protection on the next attempt. For a bona fide user, such a “mute” refusal looks identical to a technical or quality one — and again provokes a retake.
Two mechanisms work here. The first is the routing of disputed cases to manual review by an operator instead of an automatic refusal: this makes it possible to sort out the situation without disclosing the logic of the rules. The second is the wording of the refusal, which does not prompt a retake: instead of “Upload the document again”, it is more appropriate to say “To complete the check, contact support” if the reason goes beyond the quality of the shot.
How to reduce the number of repeat attempts during a KYC check
Every document retake is a point at which the user can close the app and not return. The technical reason for a refusal and the way the user sees it are different things. If the interface simply says “upload the document again” without an explanation, the person repeats the same mistake — or leaves.
Five specific points in the KYC pipeline where the problem can be intercepted before it turns into a repeat attempt.
Check the document type, validity period, and required sides before shooting
Some refusals arise not because of a poor shot but because the user chose a document the system does not accept. An expired passport, a student visa instead of an ID card, the single side of a two-sided certificate — all of this can be cut off before the camera takes a shot.
The SDK or web widget on the client side asks the user for the document type and country of issue, then checks against the scenario configuration. If two sides are provided for this type (for example, an ID card), the interface sequentially requests the front and the back. If the document is not on the list of acceptable ones, the user sees a prompt with a list of accepted types — and does not waste time shooting a knowingly unsuitable document.
A separate check is the validity period. For many document types, the expiration date is indicated in the machine-readable zone (MRZ) or in standard fields. AI-OCR is able to extract this date from a preliminary frame in fractions of a second. If the document is expired, the application reports this immediately, without sending the image to the server.
This approach removes a whole class of refusals not connected with the quality of the shot. The user does not understand why a “good photo” does not pass the check — when the reason is that the system expected a different document or the second side.
Stop a poor-quality frame before upload
Blur, glare, insufficient lighting, cropped edges — the most frequent technical reasons for refusal in document verification. If the system detects them only on the server, the user has already wasted time on the upload and waiting for a response.
Modern SDKs for mobile and web applications solve the task on the device: they analyze the video stream from the camera in real time and capture the frame only when it meets a set of criteria. Typical checks are the presence of all four corners of the document in the frame, the absence of significant blur (motion blur and defocus), the absence of glare covering the text fields, and sufficient contrast between the document and the background.
If the frame does not pass the quality threshold, the SDK does not allow the user to send it but shows a specific prompt: “Remove the glare from the second line”, “Place the entire document in the frame”, “Hold the camera still”. This is fundamentally different from the situation where the user uploads a shot, waits for the server’s response, and gets an abstract “poor quality of the document photo”.
The user gets feedback in milliseconds, not in seconds or tens of seconds. Server resources are not spent on processing unusable images. According to industry estimates, client-side quality pre-validation makes it possible to bring the share of automatically approved applications (Straight-Through Processing, STP) above 80%.
Blur, glare, cropped edges, and insufficient contrast are easy to detect before sending if the frame analysis is performed in real time on the user’s device. Without client-side pre-validation, the server spends resources on processing unusable images, and the person learns about the problem with a delay and without a specific prompt.
The NeuroVision SDK for iOS, Android, and web applications analyzes the video stream from the camera and captures the frame only when a set of criteria is met: the presence of all corners of the document in the frame, the absence of significant blur and glare, sufficient contrast between the document and the background. If the frame does not pass the threshold, the user gets a specific prompt on the screen rather than an abstract refusal after a few seconds. Document recognition takes less than 1 second, and the full KYC cycle — including the document check, face comparison, and liveness — is configured through a single platform scenario. To get started, it is enough to connect the SDK and agree on the set of checks; the trial period is up to 1 month.
Show the data after AI-OCR before launching the check
AI-OCR extracts structured data from a document — full name, date of birth, number, validity period. If it goes straight into the check and somewhere diverges from the application form, the user gets a refusal with the wording “the data does not match”. They do not know what exactly did not match, and the only available step is to retake the document. If the discrepancy arose due to transliteration, a different order of the first and last name, or a typo in the form, retaking will do nothing.
An intermediate confirmation screen solves this problem. After recognition, the user is shown the extracted fields — as the system “saw” them. They cross-check the result against the original and against what they indicated at registration. If the name in the form is written differently than in the document (for example, «Наталья» and «Наталия» or a different order of the first and last name in Latin script), the user corrects the discrepancy on the spot — without retaking and without contacting support.
This step also works in the reverse direction: if OCR incorrectly recognized a character (confused «О» and «0», misread a handwritten entry), the user notices the error before submission and can retake purposefully, understanding which fragment needs to be photographed more clearly.
Recognition takes less than a second, data confirmation — one tap. At the same time, a whole layer of refusals leaves the funnel — caused not by image quality but by a data discrepancy that the user could have eliminated in five seconds.
Write the exact reason for refusal and do not confuse it with an upload failure
The wording “the document did not pass the check” without specifying the reason is one of the main sources of pointless repeat attempts. The user does not distinguish the situations “the photo is too dark”, “the document is expired”, “an anti-fraud rule was triggered”, and “the server is temporarily unavailable”. They all look the same — like a refusal after which you need to try again.
The first rule: separate technical failures and the result of the check. If the upload did not happen due to a timeout, connection loss, or a server error, the user must see exactly this: “Failed to send — check the connection and try again”. An upload failure is not a document refusal, and mixing them is unacceptable.
The second: specify the reason for refusal as much as is safe from an anti-fraud standpoint. The phrase “glare detected on the photo” is much more useful than “error uploading the document”. The indication “the document’s validity period has expired” removes the question — the user understands that a different document is needed, not a different angle. The message “the data in the form does not match the document” prompts checking the form rather than photographing the passport again.
There are categories of reasons that cannot be disclosed in detail: triggered anti-fraud rules, suspicion of forgery, a match with the database of previously rejected applications. In such cases, a general wording is acceptable, but it must differ from a technical failure and from a “correctable” refusal — so that the user does not get stuck in useless attempts.
Send disputed cases to manual review instead of a new retake
Not every ambiguous result means that the user must start over. If the anti-fraud system assigned the application a borderline score, AI-OCR is unsure about one character, or the liveness check returned a result close to the threshold, an automatic refusal with a demand to repeat the shooting is not the best solution. With a high probability, a repeat attempt will give the same borderline result.
In such situations, it is more effective to route the application to manual review. The operator sees the source images, the extracted data, the results of all automatic checks, and the reasons why the system did not make a decision. They approve or reject the application, relying on the full context — rather than shifting the uncertainty onto the user.
The critical condition is the correct configuration of the routing thresholds. Too low a routing threshold burdens operators with a flow of applications that could be processed automatically. Too high — lets real fraudsters through or sends bona fide users into a retake loop. Optimal values are selected based on metrics: the false rejection rate, onboarding conversion, the average load on an operator. The industry benchmark is a share of automatically processed applications at the level of 80–90% with a false positive refusal rate of no more than 3%.
For the user, manual review looks simple: “Your application is under review, the result will arrive within N minutes”. This is significantly better than a fifth attempt to photograph the same passport that the system rejects time after time for an unclear reason.
Most repeat attempts arise not because of the user’s inattention but because the system does not help them take the right action on the first try. A blurred frame is prevented by client-side pre-validation. An expired document — by an early check of the type and validity period. A data discrepancy — by an intermediate confirmation screen. A pointless retake loop after an anti-fraud trigger — by a precise refusal wording and routing to an operator. Each of these measures closes off its own class of errors, and together they form a process in which the user either passes the check on the first try or immediately understands what exactly needs to be corrected.
The earlier the interface detects a problem and the more precisely it explains its cause, the fewer steps separate the person from successful verification. For a business, this means preserving conversion at the last stage of the funnel, reducing the load on support, and a predictable onboarding cost — parameters that directly depend on how thoughtfully each step of the KYC scenario is built.
Onboarding conversion is determined not only by recognition accuracy but also by how competently each step of the scenario guides the user: pre-validation of the document type and quality, intermediate data confirmation, the separation of upload errors and substantive refusals, the routing of disputed cases to an operator.
The NeuroVision platform covers this entire chain: an SDK for capturing documents and selfies with real-time quality control, AI-OCR for more than 10,000 document types in less than 1 second, biometric face verification with an accuracy of 99.74%, a liveness check with an accuracy of 99.9%, and an anti-fraud loop of more than 40 algorithms. Scenarios are configured through the platform’s back office: the set of steps, thresholds, routing rules, and refusal wordings.
The connection benchmark for ready-made components via API and SDK is 24 hours, full deployment — from 3 to 7 days depending on the environment and information security requirements. We will agree on a configuration for your channels and volumes and launch a trial period of up to 1 month.
