Document Fraud Detection Vendor: Questions to Ask
This article is a snapshot – content was accurate as of November 2026 (code examples tested against the API as of October 2026). The product evolves actively; specific counts, examples, and detection rules may have changed since publication – see the changelog for the current state.
You have a shortlist, a trial window and a meeting where someone will ask which tool to buy. A convincing demo does not show how a tool handles your files. This checklist is for the part after the demo: what the tool’s output means, what happens when it is wrong, and what it costs to find out.
One scoping note first. These questions cover tools that do structural analysis to check whether a file was modified after it was created. Identity verification, issuer verification and checking whether the content is true are different jobs, done by different tools and processes. Structural analysis of the file complements them; it does not replace any of them.
The short answer
Judge a document fraud detection vendor on three things before the headline features: what its verdict proves and what it does not, how it reports the cases it cannot decide, and whether you can test it on files where you already know the answer. Then check that its data handling and pricing are written down plainly enough to put in a contract. If you are still deciding whether to buy at all, the build-vs-buy question comes first.
What does the verdict prove, and what does it not?
Every tool returns a result. The question is what that result is a claim about. A check on the file can tell you whether the file shows evidence of change after it was made. It cannot tell you whether the person is honest or whether the figures on the page are real.
Ask each vendor:
- What exactly does a ‘clean’ result claim, in one sentence?
- What can produce a clean result even though the document is not genuine?
- Does a flagged result say what was found, or only that something was?
- Is the result phrased as a statement about the file or about the person?
A vendor that answers the second question without hesitating is telling you something useful. A reasonable standard for that answer: content that was false from the start carries no evidence of a later edit, so a file check cannot catch it. And intact means no modification was detected, not that the document is genuine. You want every vendor’s documentation to draw that line as clearly, whatever words it uses.
How does it report the cases it cannot decide?
Some files cannot be judged by a given method. A document made in ordinary office software has no original to compare against. A scan or a filled form can be redone from scratch. Sometimes the file’s history simply cannot be established, and sometimes the analysis does not finish. A tool that forces each of these into ‘pass’ or ‘fail’ is hiding a limit, not removing it.
Ask:
- Is there a separate result for ‘cannot decide’, or does every file get a yes or no?
- Does that result say why: the kind of file, missing history, or an analysis that did not finish?
- Does the documentation say what to do next for each reason?
- Is an undecided result described as an honest limit, or as a warning sign about the person?
The last question matters for your own process. An undecided result should lead to a defined step, such as asking the issuer for a fresh copy, not to a rejection. If you want a worked example of reason-based handling, see what an inconclusive result means.
How are false positives reviewed?
Any automated check will sometimes flag a legitimate file. A vendor that claims otherwise is making a claim you cannot test. What you can test is what happens next.
Ask:
- Does each flag come with a named reason that a reviewer can read?
- Are those reason names stable, so you can build your own handling on them?
- Who reviews a disputed result: your team, the vendor, or both? Is that route written down?
- When the detection changes, can you see which version produced an old result?
- Does the vendor tell you not to use the verdict as the sole basis for an adverse decision?
Treat any confidence label as a description of the evidence, not a guarantee. If a person can be refused on the strength of the result, your own process needs a human review and a way for that person to contest the outcome.
Which files stay with the vendor, and for how long?
Ask for the answer in writing, separately for each way files reach the vendor:
- Are file bytes stored after analysis? Does that differ between a web upload and an API call?
- Are customer files used to train or improve the product?
- What is stored about each check, and for how long?
- How do you request deletion, and how quickly is it done?
- Can you delete your data yourself, or only by request?
- Who are the subprocessors, and where do they process data?
Your security team will have its own questionnaire. For a worked example of the answers a reviewer should expect, see data handling in a PDF fraud API.
Can you test it on your own known cases?
This is the step that tells you most. Build a small set of files where you already know the answer:
- documents you approved in the past and have no reason to doubt;
- files you know were edited, from past cases or made by your own team for the test;
- legitimate files that went through ordinary handling, such as being re-saved, merged or signed. Label these by what happened to the file, not by whether it is legitimate: a tool that reports modification may correctly flag an honest re-save or merge.
Run them all and record agreement case by case, not as a single percentage. Score each file against what happened to it, not against whether you trust it. Look hardest at the disagreements and at how each one was explained. Keep part of the set back and run it only once, after any settings have been agreed, so you are not simply tuning the trial to your sample.
Ask whether the trial runs real analysis. A sandbox that returns fixed sample results is good for testing your integration, but it tells you nothing about detection on your files.
Is pricing readable before you sign?
You should be able to work out next month’s bill from the price page. Ask:
- What exactly is billed: a file, a page, a check, a seat?
- What happens to errors, timeouts and retries? Are they charged?
- What happens when you run out: are checks refused, or charged at a different rate?
- Are there minimum terms, setup fees or credits that expire?
A one-page scorecard
| Question | A good answer includes | Ask for as evidence |
|---|---|---|
| What does a clean result claim? | A one-sentence limit, including what it cannot catch | The wording in the API or product docs |
| How are undecided cases reported? | A separate result with a stated reason and a next step | The list of reasons and their meanings |
| What does a flag say? | Named, stable reasons a reviewer can read | Sample results and the reason catalogue |
| How are disputed results reviewed? | A written route, and who owns it | The terms and any review procedure |
| What is kept, and for how long? | Per-channel retention, training use and deletion process | Privacy policy, DPA, subprocessor list |
| Can we test on our own files? | Real analysis on your files during the trial | Trial terms, and what the sandbox does |
| Can we predict the bill? | Billing unit, retry rules, behaviour when credits run out | Price page and the billing terms |
Apply these questions to us too
HTPBE? does structural PDF tamper detection. Here are our answers, limits included.
| Question | HTPBE?’s answer |
|---|---|
| What does it prove? | Whether the file shows evidence of modification. intact means no modification was detected, not that the document is genuine; content that was false from the start carries no evidence of a later edit. It does not judge whether the content is true. Scans and screenshots never come back intact. |
| Undecided cases | inconclusive, with the reason in status_reason. |
| False positives | Our terms say false positives will occur. Every result carries usage_caution.safe_for_automated_adverse_decision, always false. |
| Disputes | No self-serve dispute or review flow. Our terms require your own process to give an affected person a way to contest a decision. |
| Retention | Website uploads may be retained and used to improve detection. Through the API, the file is analysed once and its bytes are not stored. For both, the check record (verdict, findings and metadata, including the filename) is kept for up to 3 years under our Privacy Policy. |
| Deletion | Email [email protected]; processed within 30 days, subject to legal retention duties. A retained web copy already used in evaluation may not be individually retrievable. No self-serve deletion. |
| Testing | Test keys return synthetic results, so they test integration, not detection. Your own files need live credits: new accounts get 5 welcome credits, then pay-per-check. |
| Running out | Checks are refused until credits are added, the plan is upgraded or its monthly quota resets. An inconclusive result marked analysis_incomplete uses a credit; a request that ends in an error uses none, and a retry with the same idempotency key is not charged again. Reading a result again is free. |
If you are comparing specific vendors, our side-by-side pages are here: Inscribe alternative, Ocrolus alternative and Bynn alternative.
Frequently asked questions
Should we ask a vendor for its accuracy figure?
Ask, but do not let one number decide. A rate measured on someone else’s files tells you little about yours. A trial on your own known cases, scored case by case, tells you more than any headline figure.
Can a document fraud detection tool replace identity or issuer checks?
No. A tool that checks whether a file was modified answers a question about the file. Whether the person is who they claim to be, or whether the issuer actually produced the document, are separate checks that still need to run.
What should happen to a file the tool cannot decide on?
It should go to a defined next step, such as a fresh copy from the issuer or a manual review. An undecided result is an honest limit of the check, not a finding against the person who sent the file.
Is a free trial enough to judge detection quality?
Only if the trial runs real analysis on your own files. A sandbox that returns fixed sample results tests your integration, not the detection.
Run your own known cases
If you are evaluating an integration, the API documentation covers the request, the result fields and the test keys. To run your known cases, see pricing for credits and plans, or check files through the website on pay-per-check.