Fraud Prevention

Tuteliq’s fraud prevention doesn’t rely on a single signal. Every verification runs 7 independent cross-referencing layers that compare data from different sources on the same document. A forger must defeat all layers simultaneously — editing one field on the front of a document will be caught by mismatches against the MRZ, barcode, back side, or declared metadata.

Cross-referencing layers

1. MRZ vs. OCR text

When a document contains a Machine Readable Zone (passports, many ID cards), Tuteliq compares the MRZ-extracted fields against the OCR-extracted labels from the visible printed text.

Compared field	How it catches forgery
Date of birth	MRZ says 1990-06-15 but printed DOB reads 1995-06-15 — front-side text was edited
Name	MRZ shows SMITH but printed name shows JONES — name was changed on the visible side
Document number	MRZ number doesn’t match the printed number — number was altered

This is the highest-value fraud signal because the MRZ is protected by ICAO check digits that are difficult to recalculate correctly without specialized knowledge.

2. Barcode vs. OCR text

For US and Canadian driver’s licenses, the PDF417 barcode on the back encodes all personal data independently of the printed text. Most forgers only edit the visual side.

Compared field	How it catches forgery
Date of birth	Barcode says 1985-03-20 but front OCR reads 1990-06-15 — front was edited, back barcode wasn’t
Name	Barcode says JOHNSON but front says SMITH — front name was changed

3. Document front vs. back

When both sides of a document are provided, Tuteliq extracts name and DOB from each side independently and compares them.

Signal	What it catches
Name mismatch	Front says JOHN SMITH, back says JANE DOE — mismatched front/back from different documents
DOB mismatch	Different dates on front and back — poorly assembled forgery

4. Document type consistency

If the user declares a document type (e.g., “passport”) but the MRZ indicates a different type (e.g., ID card with I< prefix), the mismatch is flagged.

Scenario	Signal
Declared passport, MRZ says `I<`	Document type mismatch
Declared national_id, MRZ says `P<`	Document type mismatch

5. IP vs. document country

Tuteliq compares the document’s country of origin against the geographic origin of the API request. A Brazilian CPF submitted from a Vietnamese IP address isn’t necessarily fraud, but it’s an anomaly worth flagging.

Geographic inconsistency is a soft signal — it generates a flag but doesn’t cause automatic failure. Diaspora populations, travelers, and VPN users can legitimately trigger this. It’s included in failure_reasons for your review logic to handle appropriately.

6. Age consistency (document vs. selfie)

When both a document and selfie are provided, Tuteliq compares the age calculated from the document’s DOB against the age estimated from the selfie by AgeNet, our own model. A discrepancy greater than 10 years is flagged.

Scenario	Signal
Document says age 25, selfie suggests ~45	The document may belong to someone else
Document says age 60, selfie suggests ~20	Using a parent’s or older person’s document

7. OCR confidence gating

When OCR confidence falls below 60%, all extracted data is flagged as potentially unreliable. This prevents the system from making verification decisions based on garbage OCR output from blurry, damaged, or deliberately obscured documents.

Document validation

Document checks are deterministic. Extracted fields are validated against each other and against per-country norms, with no image sent to any model.

Check	What it validates
Age consistency	Age derived from the document’s date of birth against the age estimated from the selfie. A large discrepancy is flagged.
Issue-date plausibility	Age at the point of issue, cross-checked against the document type.
Validity period	Issue-to-expiry span against the expected period for that country and document type (for example a Swedish passport is 5 years, a German driving licence 15).
Structured-data integrity	MRZ check digits per ICAO 9303, and PDF417/AAMVA barcode decoding where present.

Each check returns a pass or fail with a human-readable reason, so a reviewer can see which specific check failed rather than an opaque score.

{
  "document_validation": {
    "age_document_consistent": true,
    "age_discrepancy_years": 1.4,
    "age_at_issue": 27,
    "issue_date": "2019-04-02",
    "validity_period_days": 3652,
    "validity_period_normal": true,
    "checks": [
      { "check": "mrz_check_digits", "passed": true, "detail": "All ICAO 9303 check digits valid" },
      { "check": "validity_period", "passed": true, "detail": "10y matches expected range for GBR passport" }
    ]
  }
}

Image-based forgery and recapture detection are not part of this pipeline. They were removed in July 2026 under a privacy requirement: no user image in the verification flow may reach a language model. If they return, they will run as a local model on our own infrastructure. Everything documented above is deterministic and involves no model inference on the document image.

Failure reasons

Every fraud signal generates a specific, human-readable failure reason:

{
  "failure_reasons": [
    "DOB mismatch: MRZ shows 1990-06-15 but document text shows 1995-06-15 — possible tampering",
    "Geographic inconsistency: document from BRA but request originated from VNM"
  ]
}

These reasons are designed to be:

Actionable — your moderation team can understand exactly what went wrong
Specific — each reason identifies the exact data points that disagree
Auditable — included in the API response for compliance logging

Hard vs. soft failures

Signal	Severity	Result
Liveness failed	Hard	`failed`
Face mismatch	Hard	`failed`
Selfie liveness spoof detected (screen or printout)	Hard	`failed`
MRZ check digit invalid	Soft	`needs_review`
Name/DOB cross-reference mismatch	Soft	`needs_review`
Document expired	Soft	`needs_review`
Low OCR confidence	Soft	`needs_review`
Geographic inconsistency	Soft	`needs_review`
Age inconsistency (document vs. selfie)	Soft	`needs_review`

Use the failure_reasons array to build custom review workflows. For example, you might auto-reject failed results but route needs_review results to a human moderator queue with the specific reasons displayed.

Getting Started

SDKs

MCP Server

Integrations

Verification

Advanced

Compliance

Fraud Prevention

Cross-referencing layers

1. MRZ vs. OCR text

2. Barcode vs. OCR text

3. Document front vs. back

4. Document type consistency

5. IP vs. document country

6. Age consistency (document vs. selfie)

7. OCR confidence gating

Document validation

Failure reasons

Hard vs. soft failures

Next steps

Document Checks

Liveness Detection

​Cross-referencing layers

​1. MRZ vs. OCR text

​2. Barcode vs. OCR text

​3. Document front vs. back

​4. Document type consistency

​5. IP vs. document country

​6. Age consistency (document vs. selfie)

​7. OCR confidence gating

​Document validation

​Failure reasons

​Hard vs. soft failures

​Next steps

Document Checks

Liveness Detection

Cross-referencing layers

1. MRZ vs. OCR text

2. Barcode vs. OCR text

3. Document front vs. back

4. Document type consistency

5. IP vs. document country

6. Age consistency (document vs. selfie)

7. OCR confidence gating

Document validation

Failure reasons

Hard vs. soft failures

Next steps