Supported document type
Detect tampered and deepfake Application Form
An altered application form is rarely a forged document in the usual sense, because the form is genuine and only one box on it has changed. An income figure raised, a date of birth moved across an eligibility threshold, an address swapped for one in a serviceable postcode. The edit happens either before the applicant signs or after the scan reaches the intake team, and those two leave quite different traces. TamperCheck reads each field box against its neighbours rather than the page as a whole.
API slug: application_form
Last updated:
What a genuine application form contains
A form is a fixed grid before anyone writes on it: a form number and version in the footer, printed field labels, and boxes sized for a particular answer. Completed, it carries the applicant's name, date of birth, contact and address fields, the declared figures the decision turns on - income, employment dates, account or policy numbers - eligibility tick boxes, sometimes an affixed photograph, and a signature and date at the foot. A staff-use section with a reference number, a received stamp, and a processor's initials is usually added after submission.
Because the layout is printed and versioned, every entry has a correct position, size, and baseline, and the version number in the footer is what says which. That makes a field outlier visible against its own page rather than against any external standard: a value sitting off the baseline, at the wrong size, or in a different hand from the box beside it. Declared figures also repeat elsewhere in the file, with income appearing again on the payslip and the date of birth on the identity document. The received stamp fixes a date after which nothing on the form should have changed.
How application form forgeries are made
Single-box value replacement
One field on the scanned form is painted over and retyped: a salary figure, a year of birth, the last digits of an account number. Everything else is authentic, including the signature. The replaced characters sit on their own compression and rendering history, which is why field-level analysis finds them where page-level review does not.
Fields completed in a second sitting
Boxes are filled in later, by a different person or with a different pen, to correct an answer that would have failed. Ink density, stroke width, and letterform habits shift between the original entries and the added ones, and the additions frequently crowd their boxes because the writer was working around a form that was already signed.
Photograph replacement
An affixed photograph is lifted and another put in its place, or a face is composited into the scan. A genuinely attached photo shares the lighting and capture conditions of the page it was scanned with, and its edges show adhesive, staples, or a stamp crossing from the photo onto the form.
Layout that contradicts the stated version
Where the form was rebuilt rather than filled in, the reconstruction drifts from the template it names: a field the quoted version does not have, a label reworded, a column at the wrong width. The footer says which version this is supposed to be, and the page does not match it.
Signatures and received stamps added afterwards
A signature is copied in from elsewhere in the same application bundle, or a received stamp is added to an unsubmitted form to place it inside a deadline. Both arrive as clean layers over the existing page, with no pen pressure and no contact with the paper texture underneath.
Forms rebuilt and typed into digitally
A blank form is reproduced from a published PDF, completed on screen, and output to look like a scan. Alignment is perfect, which is itself the anomaly, since a real hand-completed form never sits that precisely in its boxes. Uniform text rendering and the absence of scanner noise complete the picture.
What TamperCheck checks on an application form
TamperCheck runs 200+ forensic checks across three layers and returns a risk score from 0 to 100 with plain-English findings tied to specific regions of the document. These three carry the most weight on this document class.
Signature forgery analysis
Signature regions are assessed for ink consistency and for how the stroke sits on the page, which distinguishes a genuine pen stroke from a pasted image of one.
Reference and document number checks
Document, account, and reference numbers are checked for issuer format conformance and against every other place the same value appears on the page.
Field-level forensics
Every text region is analysed in its own right rather than as part of one whole-page image. This catches the smoothed and feathered edits that whole-image Error Level Analysis misses entirely.
And many more checks
The three above are the layers that carry the most weight on an application form. Every upload runs the full suite of 200+ checks regardless of document class, spanning file structure and metadata, pixel-level forensics, font and text rendering, optical and print characteristics, provenance signals, AI-generation signatures, and many more checks.
Who verifies an application form, and why
Onboarding and intake teams processing service, job, or membership applications. In each case the document is being used to unlock money, access, or a legal status, which is exactly what makes it worth forging.
How to verify an application form in 4 steps
Check the fields against each other
Read declared income, dates of birth, and address fields together rather than one at a time. Forgers typically change one value and leave the rest of the document describing the original.
Inspect the file metadata
Open the document properties and look at the producer, creation date, and modification date. A document produced by a consumer PDF editor, or created long after the date printed on its face, is worth a closer look.
Ask for a second document
Request a corroborating document from the same issuer or an adjacent period. Forgery effort concentrates on one file, so inconsistencies surface as soon as there are two to compare.
Run a forensic check
Manual review catches obvious edits but not field-level pixel manipulation or synthetic generation. TamperCheck runs 200+ forensic checks on an application form and returns a risk score from 0 to 100 within seconds, at $0.50 per document.
Frequently asked questions
How do I detect an altered application form?
Compare each field against the boxes around it rather than reading the form as a page, because a form is a printed grid and a single edited box breaks against its own neighbours. Look for a value off the baseline, a different hand or ink, crowding inside the box, or a figure that contradicts the payslip or identity document filed with it.
Can you tell if a scanned form was edited?
Yes. A region retyped into a scan does not share the compression artefacts, noise floor, or ink characteristics of the scanned text around it, even when it is visually seamless. Field-level analysis compares every box on the form against the rest of the page and returns findings tied to the specific regions that differ.
What does it mean if one field looks different from the others on a form?
It means that field was produced separately from the rest of the page, which is the definition of an edit. The benign explanation is a correction made and initialled at the time; the fraudulent one is a value changed to clear a threshold. The distinguishing evidence is whether the difference is ink and pen, or rendering and compression.
How can you check a photograph on an application form is the original one?
Check whether the photograph and the form were captured together. A photo genuinely attached before scanning shares the page's lighting, focus, and noise, shows adhesive or staple evidence at its edges, and often has a stamp or signature crossing from the form onto the photo itself. A replacement carries its own capture characteristics and a clean boundary.
TamperCheck analyses application form uploads with a hybrid forensic and AI pipeline tuned for this document class. Upload endpoints accept PDF and common image formats; class is inferred automatically. See the API & MCP documentation for authentication, async jobs, and webhooks.