Document Tampering Detection is an addition to NIGO Document Validation. When a signer uploads a supporting document — a bank statement, pay stub, utility bill, or tax return — OneSpan Sign can also check whether the document shows signs of having been altered, before anyone relies on it. Tampering Detection results appear in the same document preview modal that NIGO validation already uses.
To enable this feature, contact our Support Team.
Four rule-based checks run on each uploaded PDF:
Unexpected source. Reads the PDF's producer and creator metadata. A document that should have come from an institution but was produced in a consumer editor (such as Canva, Word, or Photoshop) or by an AI generator is flagged. Ordinary re-savers and print-to-PDF tools (Preview, Microsoft Print to PDF, Chrome) are treated as normal. A blank or unrecognized producer is reported as source unverified rather than as a problem.
Edited after creation. Inspects the file's internal structure for appended revisions, which indicate the document was changed after it was first created. Fillable forms are exempt, so normal form-filling does not trigger this check.
Inconsistent file dates. Flags impossible or future-dated timestamps, such as a file modified before it was created, or dated in the future. A tolerance is built in to absorb clock and timezone differences.
Dated after its period. Compares the file's last-modified date against the document's own date, drawn from NIGO's existing extraction, and flags a file saved long after the period it covers.
Limitations — what it does not detect
This is a set of heuristics over a PDF's structure and metadata. It is not fraud detection, and it cannot establish that a document is genuine.
It does not read the content of the document to judge whether the content is true. It cannot tell you that an income figure was altered, that a name is not the signer's, or that the document was issued to someone else.
It is largely blind on scanned and photographed documents. A PDF that is entirely a scanned image supports only the check on the producing tool; every other check reports as not assessed. A photo or screenshot uploaded directly as an image supports none of the checks. Because a great many legitimate attachments are scans or phone photos, not assessed is a common and expected outcome — and it is not a pass.
Detection of the producing tool reads only the PDF's own metadata. A file whose producer and creator fields have been stripped, or set to something unrecognised, reports as not assessed rather than a failure. Anyone able to edit a PDF is also able to edit those fields.
A finding is not proof, and the absence of findings is not proof of authenticity. Re-saving a bank statement through a browser's print-to-PDF, or downloading a statement months after its stated period, are ordinary behaviours that can produce a warning.
How the Verdict Is Formed
Each check that fires contributes to a combined score, which maps to one of four tiers: Clear, Low, Medium, or High.
No single check can produce a High result on its own, with one exception: the Unexpected Source check. For every other check, a High result requires two or more independent signals to fire together. This keeps a legitimately re-downloaded statement from being flagged, while still catching a document that, for example, was produced in Canva, edited after creation, and dated months after its period.
Where Results Appear
An Integrity section in the document preview modal shows the overall verdict alongside each individual check in its pass or fail state, with a plain-language reason for anything flagged. The combined verdict also drives the document's status chip in the document list.
The same result — status, confidence, and reasons — is available on the API payload and via webhooks. Tampering checks run server-side regardless of whether the transaction originated in the Sender UI or through the API.
Reviewer Actions
Document Tampering Detection is advisory: nothing is auto-blocked. A flagged document can still be uploaded, signed, and completed. The existing reject-or-request affordance (see Rejecting a Document) remains the action available to the reviewer, who decides how to proceed.
Every flag is explainable, and every evaluation and reviewer action is logged with a timestamp, the document, the signals that fired, and the actor.