Document fraud detection works best as a layered process rather than a single pass or a simple “approved” result. This guide provides a reusable review workflow, a reference table for common warning signs, and clear rules for deciding when automated identity document verification should move to manual review.
Overview
Teams use identity document verification to establish whether a document appears genuine, whether it belongs to the person presenting it, and whether the information is suitable for the intended transaction. Those are related questions, but they are not identical. A document can look authentic while being presented by an impersonator. A real document can also contain outdated information, be damaged, or fail a capture-quality check without proving fraud.
A reliable identity proofing process therefore combines several controls:
- Document inspection: Check the document type, issuing jurisdiction, expiry status, visible fields, security features where supported, and signs of editing or construction.
- Data consistency: Compare names, dates of birth, document numbers, addresses where relevant, and other fields across the document, application, and available verification sources.
- Person-to-document matching: Compare the applicant’s face and other required attributes with the document portrait or approved identity signals.
- Presence and liveness: Where a selfie or video step is used, assess whether the capture represents a live person rather than a photograph, replay, mask, or other presentation attack.
- Risk screening: Apply the checks appropriate to the use case, which may include sanctions screening, PEP screening, duplicate-account detection, device signals, or related fraud controls.
Accepted document types should be defined before onboarding begins. Common examples may include passports, national identity cards, driver’s licences, residence permits, or business authority documents, but availability and acceptability vary by jurisdiction, product, and risk level. Do not treat a provider’s supported-document list as a complete policy. Your process should state which documents are acceptable, which conditions require escalation, and what alternatives are available when a customer cannot provide the preferred document.
Template structure
The following structure can be used for a reviewer playbook, verification API decision flow, or internal control document.
1. Define the verification objective
Record what the check is intended to establish: access to an account, investor or founder verification, business onboarding, a regulated transaction, or another decision. The objective determines the required assurance level, acceptable documents, retention rules, and escalation path.
2. Capture the document and applicant data
Capture images according to the provider’s technical requirements. Record the document type, issuing country, document number where permitted, expiry date, extracted fields, applicant-provided fields, and the result of any selfie or liveness step. Keep the data collection proportionate to the purpose and limit access to authorized reviewers.
3. Run automated checks
Automation may assess image quality, document structure, optical character recognition, field consistency, portrait matching, expiry, duplicate use, and signs of manipulation. Treat automated output as a risk signal, not as an unexplained final decision. Your system should retain the reason codes or evidence needed for an authorized reviewer to understand the outcome.
4. Apply a decision rule
Use at least three outcomes: pass, manual review, and decline or retry. A retry is appropriate when the issue is likely capture quality, such as glare or an unreadable image. Manual review is appropriate when signals conflict or the consequence of a false acceptance is material. Decline should follow documented policy and should not be based solely on an opaque score.
5. Record the rationale
For every exception, record which signal triggered review, what evidence was examined, who made the decision, and whether the case should affect future fraud rules. This creates a feedback loop for fraud prevention software and helps distinguish recurring capture problems from genuine document fraud.
Reference table: common document-fraud signals
| Signal | What to examine | Recommended response |
|---|---|---|
| Possible tampering | Uneven fonts, misaligned text, altered spacing, inconsistent background patterns, cropped edges, or evidence that a field was covered and replaced. | Pause automatic approval. Request a fresh capture or escalate for manual review, especially when the altered field affects identity or validity. |
| Altered image or portrait | Unnatural edges, compression differences, lighting inconsistencies, image overlays, or a portrait that does not align with the document layout. | Compare against available document checks and person-to-document matching. Escalate if signals conflict. |
| Mismatched personal details | Name, date of birth, document number, nationality, or other fields differ between the document, application, and verification record. | Check for transcription, transliteration, or legitimate name-change explanations. Do not resolve material mismatches without evidence. |
| Expired or invalid credential | The expiry date has passed, the document is outside the permitted validity window, or the document type is not accepted for the use case. | Request an acceptable current document. Escalate only when policy permits an exception or the validity information itself appears manipulated. |
| Template inconsistency | Layout, wording, fonts, symbols, machine-readable zone, or security-feature placement does not match the expected version for that document type. | Verify the jurisdiction and document version. Route unusual but potentially legitimate formats to a trained reviewer. |
| Liveness failure | The person cannot complete the required movement or capture, or the session suggests a replay, photograph, mask, or other presentation attack. | Offer a controlled retry where appropriate. Escalate repeated or high-confidence failures rather than weakening the control. |
| Possible synthetic identity | The document may pass basic checks, but identity details, device behavior, account history, or reuse patterns do not form a coherent profile. | Combine signals across the account and transaction. Apply enhanced review or hold the decision under documented fraud rules. |
How to customize
Start by mapping the workflow to the risk of the decision. A low-risk account recovery flow may need a different combination of document, possession, and secure authentication checks than investor verification, a high-value payment, or business onboarding compliance.
Next, define your document policy in operational language. List accepted document classes, minimum image quality, permitted expiry conditions, supported languages and scripts, and the treatment of damaged or temporary documents. Include a path for customers who have a legitimate accessibility, privacy, or availability concern. A policy that only says “verify identity” is difficult to apply consistently.
Separate technical failure from fraud suspicion. Glare, a poor camera, a missing edge, or an unsupported format may justify a retry. A deliberate-looking alteration, repeated use of one document across unrelated identities, or a liveness failure combined with other anomalies may justify escalation. This distinction improves customer treatment and reduces false positives.
Set manual escalation rules before a difficult case occurs. Escalate when a material field mismatch cannot be explained; document authenticity signals conflict; a person-to-document comparison is inconclusive; a liveness check repeatedly fails; the document is outside the accepted set but the business wants an exception; or multiple accounts share unusual identity attributes. For higher-risk cases, require a second reviewer or a compliance owner, and restrict reviewers from overriding controls without recording a reason.
Finally, review privacy and security controls alongside fraud controls. Collect only the evidence needed for the stated purpose, define retention and deletion rules, protect images and extracted data, and limit internal access. For organizations integrating a verification API, document which data is sent, what is returned, how decisions are logged, and how a customer can be routed to a human review process. See How to Choose a Verification API and How to Integrate a Verification API for related implementation considerations.
Examples
Example 1: A clear capture-quality problem
An applicant submits a valid document, but glare obscures part of the machine-readable area. The extracted name matches the application, and there are no other risk signals. The correct action is a guided retry with capture instructions, not an immediate fraud decline. If the second attempt remains unreadable, route it to manual review under the documented quality rule.
Example 2: A material mismatch
The document shows one spelling of a name while the application uses another, and the date of birth also differs. Transliteration or a recent name change may explain a name variation, but two material differences require evidence. Pause approval, request an appropriate explanation or supporting documentation if your policy allows it, and escalate when the discrepancy remains unresolved.
Example 3: A coherent-looking synthetic identity
The document passes basic image checks and the selfie matches the portrait, yet the same contact details or document attributes appear across several unrelated applications. No single signal proves fraud, but the pattern warrants a broader review of account history, device and session information, and related applications. Avoid relying on document verification alone when the risk concerns an identity assembled from real and fabricated details.
For venture and private-market workflows, document checks may form only one part of investor, founder, director, or beneficial-owner verification. Pair them with the relevant KYC, AML, sanctions, and ownership checks rather than treating a genuine document as proof of every claim. The related manual review guide can help turn these signals into an escalation policy.
When to update
Review this process on a scheduled basis and whenever a trigger changes the reliability of your controls. Update it when your verification provider adds or removes document support, a jurisdiction changes document formats, a new capture or liveness method is introduced, fraud patterns appear in investigation records, or reviewers identify repeated false positives. Also revisit the workflow after a material product change, such as launching a new country, accepting a new document type, adding investor accreditation verification, or changing account limits.
Use a simple maintenance checklist:
- Sample recent passes, retries, manual reviews, and declines.
- Group cases by root cause: capture quality, mismatch, document concern, liveness, synthetic identity, or policy gap.
- Check whether reviewers reach consistent decisions using the current guidance.
- Confirm that accepted documents, escalation owners, retention rules, and provider reason codes are still accurate.
- Test revised rules against legitimate edge cases before deployment.
- Record the version, effective date, owner, and reason for each change.
The goal is not to reject every unusual document. It is to make risk decisions explainable, proportionate, and repeatable. Treat document fraud detection as a living control: combine automation with trained judgment, preserve the evidence for important decisions, and update the workflow when documents, attack patterns, or business requirements change.
