Three words get used as if they mean the same thing: authentication, validation and verification. They do not. And in our experience, the gap between them is exactly where fraud gets through.
Here is the short answer, up front. Authentication proves where a document came from and that nobody touched it after it was signed. Validation checks that the data inside the document follows the rules: correct format, plausible numbers, dates that make sense. Verification, in the forensic sense, proves that the document itself was not manipulated before it was ever handed to you. Different jobs. Different blind spots.
The reason buyers conflate them is that vendors conflate them too. A signature provider sells “verification”. An onboarding tool sells “validation”. A KYC platform sells “authentication”. Everyone uses whichever word polls best. So when a lender, an insurer or an accountant asks us “do you authenticate documents?”, the honest reply is: that depends on what you think the word means. Let’s pin it down.
Document authentication proves origin, not honesty
Authentication answers one question: did this come from who it claims to come from, and has it been altered since?
The cleanest definition lives in cryptography. NIST defines a digital signature as a cryptographic transformation that, properly implemented, provides three things: origin authentication, data integrity and signer non-repudiation. In plain terms, a valid signature tells you the file came from a specific key holder and that not a single byte changed after they signed it.
In Europe this is governed by eIDAS. The EU’s own eSignature FAQ is precise about what a qualified signature validation confirms: integrity, meaning no modification was made to the signed data after signing, and authenticity, meaning the signature is backed by a qualified certificate that identifies the signatory. For PDFs specifically, the relevant standard is PAdES (PDF Advanced Electronic Signatures), defined in ETSI EN 319 142-1. It embeds the signature inside the file and supports long-term validation, so the signature stays checkable for years.
Sounds airtight, right? It is, for what it covers. But notice the recurring phrase: “after it has been signed.” Authentication starts the clock at the moment of signing. It says nothing about whether the content was already a lie when the pen, or the key, hit the page.
We made this exact point in our post on why digital signatures are not enough to catch fake PDFs. A fraudster can take a forged bank statement, sign it with a perfectly valid qualified certificate, and now you hold a document that passes authentication and is still completely fake. The signature faithfully protects a forgery. The cryptography did its job. The document is a lie anyway.
Document validation checks the rules, not the truth
Validation is the layer most onboarding teams already run, often without calling it that. It asks: does the data conform to the expected shape?
NIST’s identity guidelines describe it well. In SP 800-63A, evidence validation means confirming that presented evidence is authentic, accurate and valid: identification numbers follow standard formats, encoded data matches the plain-text, security features are present and the document is unexpired. For a financial document, the equivalent checks are things like: does the IBAN pass its checksum, do the running balances add up, do the transaction dates fall on business days, does the stated period match the figures.
This is genuinely useful. A surprising amount of crude fraud fails validation outright because amateurs do not bother making the maths reconcile. If a bank statement’s closing balance does not equal the opening balance plus the transactions, you have caught something with arithmetic alone.
But here is the problem, and it is the same problem every rules engine has eventually. Validation only catches documents that break the rules. A competent fraudster reads the rulebook too. They make the IBAN valid. They make the balances reconcile. They put the dates on weekdays. Modern fakes are internally consistent precisely because the people building them know what gets checked.
We see this constantly. About 80% of the fake documents we process started life as a genuine document, with a small alteration grafted in. Change one salary figure, nudge one balance, and the rest of the document, the part that passes validation, stays perfectly intact. Validation waves it straight through, because nothing about the data is structurally wrong. It is just false.
Forensic verification proves the file itself was not tampered with
This is the layer most people miss, and it is the one that does the work authentication and validation cannot.
Forensic verification ignores the question of who signed it and whether the numbers add up. It interrogates the file as an artefact. How was this PDF constructed? What software touched it, and when? Do the internal object structures, the fonts, the compression, the incremental save history and the metadata tell a coherent story, or do they betray an edit that the visible page hides?
A genuine bank statement exported from a banking portal has a specific internal fingerprint: a known producer, a single clean generation pass, fonts and object streams laid down in one go. A statement that was opened in Adobe Acrobat or a free PDF editor, had one number changed and was saved again carries the scars of that edit in its structure, even when the page looks flawless to the naked eye. That is what forensic verification reads.
This is the difference between OCR and real document forensics, which we dug into in why OCR alone cannot detect document fraud. OCR reads the words on the page. A document can be 100% machine-readable and 100% fake. Forensic verification reads the page and the layers underneath it, which is where manipulation actually lives.
Here is the uncomfortable part. The content-consistent fakes that defeat both authentication and validation are exactly the ones forensic verification is built to catch. The signed forgery? Authentication passes it; verification flags the edit history. The reconciled-but-false statement? Validation passes it; verification spots that the figures were typed over an original. The two layers everyone already trusts are blind in precisely the spot where the good fakes hide.
Authentication vs validation vs verification: a side-by-side
To make the three concrete, here is what each layer does, what it catches and what it misses.
| Layer | The question it answers | What it catches | What it misses |
|---|---|---|---|
| Authentication | Where did this come from, and was it changed after signing? | Tampering after signing, forged or absent signatures, untrusted certificates | A genuine signature applied to an already-fake document |
| Validation | Does the data follow the rules and formats? | Broken checksums, balances that do not reconcile, impossible dates, missing fields | A fake built to pass every rule: valid IBAN, reconciled balances, plausible dates |
| Forensic verification | Was the file itself manipulated before it reached me? | Edits hidden in the PDF structure, suspicious producers, inconsistent metadata, altered numbers grafted onto a real document | Fully fabricated source data that never existed in any genuine file (rare, and usually caught by cross-referencing) |
Read across the “what it misses” column and you see the design flaw in running only the first two layers. Authentication trusts the signer. Validation trusts the rulebook. Both assume the document was honest before it entered the process. Verification is the only layer that questions that assumption.
Why most compliance stacks stop at the first two layers
If verification is the layer that catches the dangerous fakes, why do so few teams run it?
Partly because the first two layers are easier to buy and easier to explain. “We use qualified signatures” sounds like a complete answer in an audit. “Our system validates the data” sounds thorough. Both tick a box. Neither requires anyone to understand PDF internals.
Partly because the words themselves create false confidence. A team that “authenticates” documents genuinely believes it has verified them. We covered a version of this in our guide to document verification for accountants: a client’s statement gets used in a tax return, the tax return becomes evidence of income for a loan, and nobody ever questioned the original PDF. Every party trusted the layer before them. None of them ran forensic verification.
And partly because, for years, the fakes were bad enough that validation alone caught most of them. That era is over. The forgeries are content-consistent now. They are signed. They reconcile. They look right. The only layer that still sees through them is the one that examines the file as an object rather than as a set of claims.
What to actually run, and in what order
You do not have to pick one. The three layers are complementary, and the strongest pipelines use all of them in sequence.
-
Validate first. Run the cheap rule checks at intake: formats, checksums, reconciliation, date logic. This filters out the lazy fakes for almost nothing and flags obvious structural nonsense before anything else touches the document.
-
Verify forensically next. Before a human ever reviews the data, run the document through forensic verification. This is the step that catches the signed forgeries and the reconciled-but-false statements that validation just waved through. It is the layer doing the work no other layer can.
-
Authenticate where signatures exist. If the document carries a digital signature, check it. A broken or untrusted signature is a real red flag. Just remember what a valid one does and does not tell you: it proves origin and post-signing integrity, not that the content was honest to begin with.
-
Cross-reference at the end. Compare documents against each other. A payslip’s salary should roughly match the deposits on the bank statement. This catches the rare fully fabricated source that survives the first three steps.
VerifyPDF lives at step two, the forensic layer that most stacks are missing. We analyse the internal structure of every PDF, checking for the signs of manipulation that authentication and validation are not built to see, and we return a risk rating in under five seconds. Run it on intake, before a document becomes the basis for a decision.
The word that matters is verification
If you take one thing from all of this: when a vendor or a regulator uses the word “verify”, ask what they actually mean. If they mean checking a signature, that is authentication. If they mean checking the data conforms, that is validation. Useful, both of them, and both blind to a signed, reconciled, content-consistent fake.
Forensic verification is the layer that asks the only question the others skip: was this file tampered with before it ever reached you? In a world where the good forgeries pass every other check, that is the question that actually protects you.
Want to see which layer your documents are really getting? Try a free document check and watch what shows up under the hood, or get in touch to build forensic verification into your pipeline.