Document Tampering Detection: Catching Edited IDs in Chat

Most fraudulent onboarding attempts do not use fully counterfeit documents. They use real documents with small edits: a changed date of birth, a swapped photo, a corrected name to match a stolen account. These alterations are cheap to make and, if you only read the printed fields, easy to miss. Detecting them means checking whether a document is internally consistent with itself.

What Tampering Actually Looks Like

Edits cluster around a handful of high-value fields. In practice you will see:

• Photo substitution — a new face pasted over the original, often with compression artifacts or edge halos that differ from the surrounding print.
• Date manipulation — a date of birth adjusted to pass age gates, or an expiry pushed forward to reactivate an old document.
• Field mismatches — a printed name that no longer agrees with the machine-readable zone because only the visible text was edited.
• Digital recapture — a screen photographed instead of a physical card, adding moiré patterns and reflections.

The attacker's mistake is almost always the same: they change one representation of the data and forget the others.

Checksum Math Does the First Pass

Machine-readable travel documents follow ICAO Doc 9303, which builds check digits into the MRZ. Each check digit is a weighted modulo-10 calculation over a field: passport number, date of birth, expiry date, and a composite over the whole zone. Recomputing them takes microseconds and requires no external service.

The value here is deterministic. If someone edits the printed date of birth but leaves the MRZ untouched, the two disagree and you catch it. If they edit the MRZ text without recomputing the check digit, the checksum fails. To pass cleanly, an attacker has to change the visual field, the corresponding MRZ field, and the check digit consistently — a much higher bar than a photo editor makes obvious. Cross-referencing every printed field against its MRZ counterpart turns a single sloppy edit into a hard failure.

Visual and Metadata Signals

Beyond field consistency, the pixels carry evidence. Error Level Analysis highlights regions saved at a different compression level than their surroundings, which frequently reveals a pasted photo or overwritten text. Font and kerning analysis catches characters that were retyped in a face the issuer never used. Security features — microprint, guilloché patterns, and where supported, optically variable elements — degrade under editing and recapture.

File metadata adds another layer. An image whose EXIF data names a desktop editor, or whose dimensions match a known template rather than a camera sensor, warrants scrutiny. None of these signals is conclusive alone; a genuine document photographed in poor light can trip several. Treat them as weighted inputs to a risk score, not as automatic rejections, and route borderline cases to human review with the specific failing checks attached.

Handling It in a Chat Flow

A conversational channel changes the operational picture in useful ways. You can request a live capture rather than an uploaded file, which reduces the window for offline editing and lets you nudge the user — "tilt the card so we can see the hologram" — when a security feature is not visible. That turns a static upload into an interactive check.

The privacy consequence matters just as much. Tampering detection needs the image only at decision time; it does not require you to retain the raw document afterward. The disciplined pattern is to run checksum, consistency, and visual analysis in-flow, persist the results and the check that failed, then discard the image on a short, configurable schedule. You keep a defensible audit trail of why a document was accepted or rejected without accumulating a breach-worthy archive of identity photos.

This is general information, not legal advice. Calibrate thresholds and review workflows to your own risk appetite and regulatory obligations.