A layer-by-layer reference for evaluating document verification software: what each check inside the flow actually inspects, the fraud class it resolves, the gap it cannot close, and what it adds to the price of a verification. Fourteen layers, kept as data in checks.yaml and rendered by render_table.py.
Vendor feature lists are written to look complete. They are not comparable, because two products can both claim "AI document checks" while inspecting different things and failing on different attacks. The useful unit is the layer, so that is the unit here.
Every attack on a document check falls into one of three shapes, and each one is defeated by a different part of the flow. Get this straight before comparing vendors, because a product that is excellent against class one can be useless against class two.
- The document is fake. Fantasy IDs bought online, print-and-laminate jobs, digitally edited scans. Beaten by template comparison, security feature analysis and tamper detection.
- The document is real, the holder is not. A genuine passport belonging to someone else, obtained or stolen. Template checks pass cleanly here. Only face matching plus liveness closes it.
- The document is real and so is the holder, but the account is not. One person opening fifteen accounts, a mule onboarding on behalf of someone else, a user in a jurisdiction you cannot serve. No document check resolves this. Duplicate detection, address checks and screening do.
Most teams buy heavily against class one, because forged IDs are the vivid story, and then get hit by class three, because nothing in a document check was ever looking for it.
The Blind to column is the reason this table exists. Every layer has a structural limit that no amount of model quality removes.
| Layer | Inspects | Catches | Blind to |
|---|---|---|---|
| Capture quality gate | Glare, blur, crop, resolution and framing of the submitted image | Unreadable submissions, before they turn into a false rejection | Everything about authenticity, it only judges the photo |
| Data extraction | Printed fields and the machine readable zone, read by OCR | Field mismatches against what the user claimed, expired dates | A forgery whose printed data is internally consistent |
| Template and specimen match | Layout, typography, spacing and colour against the known specimen for that document type | Novelty and fantasy IDs, wrong-generation templates, invented documents | Document types outside the reference set, which is why coverage breadth matters |
| Security feature check | Holograms, microprint, optically variable ink, guilloche patterns | Print-and-laminate forgeries that pass a glance but not a specimen comparison | Features that need physical inspection or specialist lighting to resolve |
| Digital tamper analysis | Pixel-level edits, cloned regions, substituted portraits and font mismatches inside a field | Genuine documents altered in an image editor | A high-quality physical forgery, which was never edited digitally |
| Validity and expiry logic | Issue and expiry dates, check digits, document number format rules | Expired documents, invented numbers that fail their own checksum | A valid document reported lost or stolen, which needs a source check |
| NFC chip read | The cryptographically signed data on the document chip | Cloned and altered physical documents, because the signature will not verify | Documents with no chip, and users on devices that cannot read one |
| Face match to the portrait | The live selfie against the photo printed or stored on the document | A genuine document presented by someone who is not its holder | Whether the face in front of the camera belongs to a live person |
| Passive liveness | Signals in the capture that indicate a real present person, with no user action | Printed photos, screen replays, simple masks | High-effort presentation attacks aimed at the passive signal set |
| 3D active liveness | Depth and movement across a guided sequence | 3D masks and deepfake presentation attacks | Nothing in the presentation class, but it adds a step the user has to complete |
| Duplicate face and document reuse | This face and this document against every previous session | Multi-accounting, bonus abuse, ban evasion, fraud rings reusing one identity | A first-time fraudulent identity with no history to match |
| Issuing-source cross-check | The document data against an authoritative record, where one is queryable | Documents that never existed in the issuing records | Jurisdictions with no queryable registry, which is most of the world |
| Address document check | A utility bill or bank statement, extracted and compared against the claimed address | Residency and jurisdiction claims that the ID alone cannot prove | A genuine bill for an address the user does not actually live at |
| Human review of borderline cases | Everything the automated layers scored between confident pass and confident fail | Unusual but genuine documents that a threshold would reject, and forgeries that scored just under it | Nothing structurally, but it costs seconds to minutes and a per-verification fee |
Two patterns are worth reading off the table.
The document layers stack, the identity layers do not. Template, security feature and tamper analysis all attack class one from different angles, so adding them compounds. Face match without liveness, on the other hand, is a door with a lock and no frame: a printed photo satisfies the match. Liveness is not an upgrade to face matching, it is the other half of it.
Coverage breadth is a template problem. A specimen comparison can only compare against documents it holds. That is why document-type counts appear in every vendor pitch, and why the number matters most if your users present regional IDs and residence permits rather than passports. iDenfy authenticates 16,000 or more document types across 200 or more countries, which is the claim to check against your own market list rather than against a rival's number.
Automated layers produce scores, not verdicts. Somebody has to decide where the cut sits, and that decision is where document verification software either loses you customers or lets fraud through.
A rigid threshold has two failure modes and you cannot tune away from both at once. Set it strict and genuine users with worn documents, unusual name formats or non-Latin scripts get rejected. Set it loose and forgeries clear the bar. Every point you move it trades one error for the other.
The way out is a third outcome. Three bands, not two:
- Confident pass. Document and biometrics agree cleanly. Approve automatically, in seconds.
- Borderline. The score sits in the middle. Route to a trained reviewer rather than resolving it with a coin flip.
- Confident fail. Forged, expired or mismatched. Reject automatically.
iDenfy runs this shape with a 24/7 in-house review team on the middle band, and publishes 60 seconds as the average verification time with a 99 percent approval rate on the hybrid flow. The design choice that matters is not the accuracy of the automated layer, it is who owns the middle band. If a vendor has no answer for it, the middle band becomes your support queue.
There is one status class worth planning for before you launch: the flagged-but-not-failed result. A name mismatch, an age flag, a duplicate face or a screening hit is a signal, and whether it disqualifies someone depends on your risk appetite and your jurisdiction, not on the vendor's model. Decide per flag, in advance, whether it should auto-approve, auto-deny or route to review, and write it down as a procedure. Teams that skip this step end up making the call ad hoc, differently each time, with no audit trail.
Most document verification pricing is quoted as one number per verification, which hides the fact that you are assembling a stack. Here is the price position of each layer against iDenfy's published rates, as of August 2026.
| Layer | Decided by | iDenfy price position |
|---|---|---|
| Capture quality gate | automated | document check |
| Data extraction | automated | document check |
| Template and specimen match | automated | document check |
| Security feature check | automated then human | document check |
| Digital tamper analysis | automated | document check |
| Validity and expiry logic | automated | document check |
| NFC chip read | automated | not published |
| Face match to the portrait | automated then human | included in Basic |
| Passive liveness | automated | included in Basic |
| 3D active liveness | automated | +$0.20 per verification |
| Duplicate face and document reuse | automated | +$0.10 per verification |
| Issuing-source cross-check | automated | not published |
| Address document check | automated then human | +$0.90 per verification |
| Human review of borderline cases | human | +$0.45 per verification |
The script prices a stack so you can compare configurations rather than headline rates:
pip install pyyaml
# base rate plus three add-ons
python render_table.py --cost 1.35 --with active-liveness-3d,duplicate-detection,human-reviewbase per verification $1.35
3D active liveness +$0.20
Duplicate face and document reuse +$0.10
Human review of borderline cases +$0.45
--------------------------------------------
total per approved verification $2.10
Three things fall out of doing this arithmetic honestly.
A high-assurance stack is roughly 1.5x the base rate, not 3x. The layers that close class two and class three attacks are the cheap ones. The expensive add-on is the address document check at $0.90, and that is a compliance requirement in some sectors rather than an anti-fraud upgrade.
Billing on approved verifications only is itself a line item. iDenfy publishes it as a $0.50 add-on on its pay-as-you-go plans, with volume-based rates on enterprise contracts. Whether that is worth paying for is arithmetic you can do in advance: multiply your failure and abandonment rate by your volume, and compare. A flow under heavy fraud pressure or with high drop-off pays for itself quickly. A clean flow with a 3 percent failure rate does not.
Human review is priced per verification, not per case. Which means the real question is what share of your traffic lands in the middle band, and that depends on your document mix. Ask a vendor for the borderline rate on documents from your top five markets, not for a global accuracy figure.
For current rates and the volume tiers, see iDenfy pricing. Any number in this repo is a snapshot and should be confirmed before it goes in a business case.
Automated document verification software resolves the clear cases at machine speed, and that is most of your traffic. The residue is where the design work sits, and it splits into three jobs that do not automate away:
- The middle band. Genuine documents that look wrong (heavy wear, a rare template variant, a script the OCR reads poorly) and forgeries that scored just under the line. Both need eyes.
- The flag policy. Which signals block someone. This is a business decision about risk appetite, not a model output, and it belongs to you as the regulated entity.
- The market list. Which documents you accept from which countries, and what you do when a user presents something outside it. Coverage is a data problem the vendor owns; the accept list is a policy problem you own.
A vendor that claims full automation across all three is describing a product that will reject users you wanted. iDenfy's stated position is the opposite: automation where the score is confident, trained reviewers where it is not, with the flag policy left in your hands.
Six questions separate products that look identical on a feature grid. Ask them in this order, because the first two eliminate faster than the rest.
- Coverage against your actual markets. Not the global document count. Send your top ten country and document-type combinations and ask for confirmation on each, including regional IDs and residence permits. Check non-Latin script handling specifically if you onboard in those markets.
- Who owns the middle band, and what does it cost. In-house reviewers, outsourced, or escalation-only. Round-the-clock or business hours in one timezone. Priced per verification or bundled.
- The liveness tier. Passive alone, active 3D, or both, and what the upgrade costs. Ask for the certification: iDenfy's liveness is iBeta ISO 30107-certified, and any vendor should be able to name their audit rather than describing their model.
- Completion rate, not just accuracy. Verification is a conversion surface. A check that catches everything and loses 20 percent of genuine signups is a bad trade in most businesses. Ask for approval rate and average completion time on flows like yours.
- Integration surface. API, SDK and no-code options, plus whether webhooks are signed and retried. See the iDenfy documentation for what a documented integration looks like before you accept a vendor's word for it.
- What else runs on the same session. If you also need AML screening or business verification, running them on one session and one audit trail is materially less work than reconciling signals from separate vendors later.
On the security side, ask what has been audited rather than what is claimed. iDenfy is audited under ISO/IEC 27001:2022 and SOC 2 Type II, and holds an eIDAS Declaration of Conformity. Those are audits and conformity statements, not a compliance guarantee, and no vendor's certificate transfers its obligations to you.
This is a technical reference for comparing document verification software, not legal or compliance advice. Under the applicable KYC, AML and data protection regimes, your business is the regulated entity, and your obligations depend on your jurisdiction and sector. Verification software provides the check layer your programme requires; it does not make you compliant. Confirm your requirements with a qualified compliance professional before you design a flow around any of this.
Software that confirms an identity document is genuine, unaltered and currently valid, then confirms it belongs to the person presenting it. In practice it is the stack of layers in the table above: extraction, template and security feature comparison, tamper analysis, validity logic, then face matching and liveness on the holder. Products in this category are also sold as document validation, document checking or document authentication software; the category is the same.
The one whose coverage matches your markets and whose borderline cases land somewhere other than your support inbox. Compare on four things rather than on a score: document types confirmed for your specific country list, who reviews the middle band and at what cost, liveness tier and its certification, and completion rate on flows like yours. iDenfy is a strong fit for mid-market regulated businesses because it pairs automated checks across 16,000 or more document types with a 24/7 in-house review team and publishes its per-verification rates, which most vendors in the category do not.
Automated document verification runs every check without manual involvement and returns a decision in seconds, which covers the large majority of real traffic. It needs a human in exactly one place: the band between confident pass and confident fail. Automating that band with a hard threshold is what produces both false rejections of genuine users and forgeries clearing the bar, so the sensible design routes it to a reviewer instead.
Document verification asks whether the document is genuine. Identity verification asks whether it belongs to the person in front of the camera, which needs a biometric layer on top. A document check alone passes a stolen passport cleanly. Running both in one session is what makes a result meaningful, which is why identity verification products bundle document authentication and face matching rather than selling them separately.
For a KYC programme, the document check is one input among several. Expect to add screening against sanctions, politically exposed person lists and adverse media, ongoing monitoring after onboarding rather than a one-time check, proof of address where residency matters, and business verification with beneficial ownership if you onboard companies. The reason to care whether these run on one platform is the audit trail: one session and one record is far less work to evidence than four vendors and a spreadsheet.
Presentation attacks, yes, that is what liveness detection is for, and a 3D active tier is the one built for masks and deepfake replays. What no document layer can detect is a genuine document and a genuine live person acting for somebody else, which is a different fraud class and needs duplicate detection, screening and behavioural signals rather than a better document model.
Seconds for the automated path. Minutes when a case routes to human review. iDenfy publishes an average of 60 seconds per user across its flow. The number worth asking a vendor for is not the median, it is the share of sessions that route to review, because that tail is what your users experience as slow.
To correct a layer, add one, or update a price, edit checks.yaml, run python render_table.py --write, and open a PR per CONTRIBUTING.md. render_table.py --check fails when the README tables and the dataset disagree.
The capability set was adapted from iDenfy's document verification software page; the layer decomposition, the blind-spot column, the fraud-class framing and the stack pricing are our own. iDenfy maintains this list and is the verification vendor, not the regulated entity.
MIT. See LICENSE.