# Document Tampering Detection Software: How to Choose One in 2026 > A buyer's guide to document tampering detection software: the nine evaluation criteria that matter, how to test a fake bank statement detector, what free online tools miss, and build vs buy. *Published 2026-09-19 · 12 min read · TamperCheck.ai* Canonical: https://tampercheck.ai/blog/document-tampering-detection-software --- There is a gap between *knowing* document tampering detection exists and *choosing* a system to run it. The first is a technology question, and we have covered it at length in [how document tampering detection works](https://tampercheck.ai/document-tampering-detection). The second is a procurement question, and it has a different answer: most of what separates good detection software from bad has nothing to do with the forensic algorithms, which are largely public and broadly similar across vendors. It has to do with coverage, explainability, and what happens on the documents that *aren't* obviously fake. This guide is the evaluation checklist. It assumes you have already decided you need something and are now trying to work out what to ask for. - **200+**: forensic checks a production system should run per document - **~1 min**: reasonable verdict latency for a full analysis - **9**: criteria that actually differentiate vendors ![Evaluation matrix for document tampering detection software showing nine criteria scored across candidate vendors](https://tampercheck.ai/images/blog/tampering-detection-software.png?v=2) *The demo will show you a caught forgery. The evaluation should tell you what happens on the other 999 documents.* ## What document tampering detection software actually does Document tampering detection software takes a submitted file - a PDF, a scan, a phone photo - and answers one question: *was this document issued the way it claims to have been issued?* That is narrower than it sounds, and it is worth being precise, because three adjacent categories get sold under the same banner: | Category | What it answers | What it does **not** answer | |---|---|---| | **OCR / IDP** | What does this document say? | Whether what it says is true | | **Liveness / biometrics** | Is the person real and present? | Whether their document is genuine | | **Database verification** | Does this record exist at the issuer? | Anything, when no issuer API exists | | **Tampering detection** | Was this file edited after issue, or synthesised? | Whether the original facts were correct | A lot of failed deployments trace back to buying one of the first three while believing it covered the fourth. If you extract a salary figure with OCR and route on it, you have automated the *acceptance* of a forged payslip, not the detection of one. That distinction is unpacked in [tampering detection vs OCR](https://tampercheck.ai/document-tampering-detection-vs-ocr), and the biometric version in [liveness detection vs document forensics](https://tampercheck.ai/liveness-detection-vs-document-forensics). > **WARNING:** If a vendor's answer to "how do you detect tampering" is "we extract the fields and check them for consistency", they are selling you OCR with validation rules. That catches typos and lazy fakes. It does not catch a competently edited PDF where the arithmetic was recalculated. ## The nine criteria that separate vendors ### 1. Check breadth, and whether every check runs every time Ask how many independent forensic checks run per document, and - more importantly - whether they all run on every document or only when a classifier decides they are relevant. Conditional pipelines are cheaper to operate and quietly create blind spots: the check that would have caught the fraud never fired because an upstream classifier mislabelled the document. The checks worth confirming are present: Error Level Analysis and recompression signatures, font metric comparison across text elements, arithmetic and running-balance validation, PDF object and producer metadata inspection, text-layer versus rendered-raster comparison, MRZ check digits for IDs, template and layout matching against known issuer formats, and AI-generation detection. [The complete guide](https://tampercheck.ai/document-tampering-fraud-complete-guide) covers what each one catches. ### 2. File-type and origin coverage A digitally-born PDF, a flatbed scan, and a photo taken at an angle in bad light are three different forensic problems. Metadata analysis is powerful on the first and nearly useless on the third; pixel-level noise analysis is the reverse. Ask what happens to each. Ask specifically about: - Multi-page PDFs where only page 3 was altered - PDFs that have been "flattened" or re-printed to PDF to destroy the edit history - Photographs of screens, which are a rapidly growing fraud vector - Password-protected and certificate-signed PDFs ### 3. Explainability, in a form a human can act on A risk score on its own is not usable evidence. When a document is flagged, your reviewer needs to know *what* was flagged, *where* on the page, and *how confident* the system is - both to make a decision and, in regulated workflows, to defend it later. Insist on seeing a real output. A usable finding looks like this: ```json { "category": "ela_anomaly", "severity": "high", "description": "Compression anomalies detected in the closing balance region.", "region": { "page": 2, "bbox": [412, 690, 548, 712] }, "confidence": 0.89 } ``` Not this: ```json { "risk": 0.71 } ``` A vendor that cannot show you region-level findings has either not built them or is hiding a model it cannot interrogate. Ask for a [sample report](https://tampercheck.ai/sample-report) before the call, not during it. ### 4. The false-positive rate, asked about honestly This is the question that separates a serious evaluation from a demo. Any system can be tuned to catch every fake by flagging everything. The operational cost of detection is almost entirely false positives: genuine documents sent to manual review, genuine customers delayed. Ask two things. First, what the false-positive rate is on clean, genuine documents of the type you actually process - a scanned Indian savings account statement behaves very differently from a digitally-issued UK payslip. Second, and more revealing: *how do they know?* A vendor with a real answer has a labelled corpus and re-validates suppression rules against all of it. A vendor without one will give you a round number. > **TIP:** Bring 50 documents you know are genuine - ideally awkward ones, with scanner artefacts, creases, and stamps - and count the flags. This single test is worth more than the entire vendor deck. ### 5. Latency and how it degrades A sub-second verdict usually means a shallow analysis. Full forensic work on a multi-page PDF takes real compute; about a minute is a reasonable target. What matters more is the shape of the degradation: does latency hold at your peak hour, and what is the behaviour when the system is saturated - queue, or fail open? A detection system that fails open under load is a detection system that is off precisely when a coordinated fraud attempt is most likely. ### 6. Integration surface Most teams need an API, not a portal. Confirm there is a single endpoint that accepts any document type and auto-classifies, rather than one endpoint per document type that forces you to know what you are submitting before you submit it. Confirm webhooks exist with signed payloads, so you are not polling. Confirm the response schema is versioned. The [developer guide](https://tampercheck.ai/document-verification-api-developer-guide) shows what a complete integration looks like end to end. ### 7. Data handling Documents submitted for verification are among the most sensitive files your business touches. Establish: whether document content is persisted after analysis or processed in memory, what job metadata is retained and for how long, where processing happens geographically, and whether your documents are used to train models. Get the last one in writing. ### 8. Pricing that survives contact with volume Per-document pricing is the only model that is straightforwardly comparable. Watch for: minimum monthly commitments that make a pilot expensive, separate charges for AI inference on top of the per-document fee, and per-check or per-page multipliers that turn a 12-page bank statement into twelve billable units. A flat per-document price - [ours is $0.50](https://tampercheck.ai/pricing) - means your forecast is your volume times one number. ### 9. What happens when detection is wrong Every system will miss something and flag something it should not have. Ask what the escalation path looks like, whether findings can be manually overridden with an audit trail, and whether overrides feed back into tuning. A vendor that treats its verdict as final has no mechanism to improve on your document mix. ## Testing a fake bank statement detector specifically Bank statements are the highest-volume fraud target in lending, rental screening, and income verification, and they are the document type where generic detection most often fails. If bank statements are your primary use case, the general checklist above is necessary but not sufficient. Add these. **Running balance arithmetic must be verified, not just present.** The crude fake changes one transaction amount and breaks the chain. The competent fake recalculates every subsequent running balance so the arithmetic is internally perfect. Ask how the system catches the second kind - the answer should involve cross-referencing totals, opening and closing balance declarations, and the summary block against the transaction ledger, because forgers reliably forget one of them. **Partial edits must be localised.** A tampered statement is typically 95% genuine. Whole-document scoring dilutes a strong local signal into a mediocre global one. The system must analyse regions independently and report where the anomaly is. **Statement-specific structure must be checked.** Column alignment drift, row height inconsistency where a row was inserted, date sequence gaps, and transaction descriptions whose formatting does not match the issuer's template. The seven signals that matter are broken down in [how to detect a tampered bank statement](https://tampercheck.ai/tampered-bank-statement-detection), and the region-by-region manual equivalent - useful for building your own evaluation test set - is in [what to check inside a bank statement](https://tampercheck.ai/bank-statement-verification-checklist). **The test set must include an AI-generated statement.** Statements produced whole-cloth from a prompt have no edit history at all - there is nothing for ELA or metadata analysis to find, because nothing was edited. Detection has to come from generation artefacts and template mismatch instead. A detector tuned entirely for edits will pass these cleanly. > **DANGER:** A detector that scores a genuine statement and an AI-generated one within a few points of each other has not been tested against synthetic documents. Put one in your evaluation set and watch what happens. ## Free online detectors: what they can and cannot do Search for a fake bank statement detector online and most of the free results fall into two groups, neither of which is detection software. The first group is **metadata viewers**. They read the PDF's producer field, creation and modification timestamps, and embedded fonts, then show them to you. This is genuinely useful - a statement whose producer string says a photo editor rather than a banking system is a real signal, and you can check it yourself in seconds with a [PDF metadata extractor](https://tampercheck.ai/tools/pdf-metadata-extractor) or an [EXIF viewer](https://tampercheck.ai/tools/exif-viewer). But metadata is trivially stripped, and any forger competent enough to worry about has stripped it. Clean metadata is weak evidence of authenticity; dirty metadata is strong evidence of a problem. The second group is **single-algorithm image tools**, usually an ELA heatmap. ELA is one of the two hundred signals a real system uses, and in isolation it is close to unreadable: JPEG recompression, scanner sharpening, and ordinary photocopying all produce the same bright regions that an edit does. Without a baseline for what normal looks like for that document type, the heatmap tells you nothing you can act on. What free tools genuinely cannot do is the part that carries the weight: run two hundred checks in combination, weight them against each other, calibrate against a corpus of known-genuine documents of the same type, and produce a defensible verdict. That requires a labelled corpus and continuous tuning, which is why it is not free. If you are checking one document, once, for your own information - a manual look at metadata plus a careful read of the arithmetic is a reasonable start, and costs nothing. If a decision with money attached depends on the answer, or you are doing this more than occasionally, it is the wrong tool. **Test it with your own document**. Upload a real statement - or a deliberately edited one - and see the full finding set, region by region. Free credits to start, no contract, no demo call. (https://tampercheck.ai) ## Build versus buy Building is a reasonable choice in exactly one situation: you have a forensic specialist on staff, a labelled corpus of your own fraud, and document volume high enough that per-document pricing exceeds a salary. The reason it usually is not reasonable has little to do with the algorithms. ELA, font metric comparison, and metadata parsing are each a few hundred lines. The cost is everything downstream of that: - **Calibration.** A check produces a number. Turning that number into a verdict requires knowing the distribution of that number across thousands of genuine documents of that exact type. Without it you have a heatmap, not a decision. - **False-positive suppression.** Every suppression rule you add to stop flagging creases and scanner scratches risks silencing a real signal. Validating each one requires replaying it across your entire corpus - and the first cuts almost always kill true positives. - **Adversarial drift.** Fraud techniques change. Generative models improve. A system tuned in March is measurably weaker by September unless someone owns it full time. - **Explainability and audit.** Producing a finding a compliance officer can defend is substantially more work than producing a score. The realistic middle path is to buy detection and build the workflow around it - your routing thresholds, your review queue, your audit log, your escalation rules. That is where domain knowledge actually pays, and it is the part no vendor can do for you. ## A 30-minute evaluation you can run this week 1. **Assemble 50 genuine documents** of the type you actually process, including the ugly ones - creased scans, phone photos, stamped and signed pages. Count false positives. This is your operational cost. 2. **Assemble 10 fakes across three tiers**: one crude edit, one competent edit with recalculated arithmetic, one fully AI-generated document. Most systems catch tier one. Tier two separates the field. Tier three separates it again. 3. **Read one full report end to end.** Can a reviewer with no forensics training act on it? Can they tell a regulator why the document was rejected? 4. **Submit the same document twice.** The findings should be materially the same both times. Run-to-run instability in a forensic verdict is a serious finding about the vendor. 5. **Check the price of your actual annual volume**, including multi-page documents, and including whatever resubmissions your workflow generates. If a vendor resists any of this - particularly step 1 or step 4 - that is your answer. ## Where this is going Two changes are worth planning for. Generated documents are displacing edited ones, which shifts detection away from edit-history forensics toward generation artefacts and template matching; a system architected only around "find the edit" is on a shortening clock. And explainability is moving from a nice-to-have to a requirement, as regulators increasingly expect an automated adverse decision to come with a reason a human can inspect. Both favour systems that run broad, independent check batteries and surface their reasoning, over systems that return a single opaque score. ## Related reading - [Document Tampering Detection: How It Works](https://tampercheck.ai/document-tampering-detection) - the forensic checks themselves, in plain English - [Document Tampering and Fraud: The Complete Guide](https://tampercheck.ai/document-tampering-fraud-complete-guide) - how documents are tampered with, and who gets targeted - [How to Detect a Tampered Bank Statement](https://tampercheck.ai/tampered-bank-statement-detection) - the seven signals, in detail - [Document Verification API: A Developer's Guide](https://tampercheck.ai/document-verification-api-developer-guide) - what integration looks like - [Automated document tampering detection](https://tampercheck.ai/automated-document-tampering-detection) - the product overview ## FAQ ### What is document tampering detection software? Document tampering detection software analyses a submitted file to determine whether it was altered after issue or generated synthetically. It runs forensic checks the human eye cannot perform - compression analysis, font metric comparison, PDF object inspection, arithmetic validation, template matching - and returns a verdict with supporting findings. It is distinct from OCR, which extracts text without verifying it, and from biometric liveness, which verifies a person rather than a document. ### How much does document tampering detection software cost? Pricing is usually per document. TamperCheck is $0.50 per document with no minimum commitment and free trial credits. Watch for vendors who charge per page, per forensic check, or who bill AI inference separately on top of the per-document fee - those models make annual cost hard to forecast from volume alone. ### Is there a reliable free fake bank statement detector online? Not in a meaningful sense. Free tools are generally either metadata viewers or single-algorithm image tools such as ELA heatmaps. Both produce real information, but neither calibrates that information against known-genuine documents of the same type, which is what turns a signal into a verdict. Free metadata checks are a sensible first look at a single document; they are not a basis for a decision with money attached. ### Can detection software catch an AI-generated bank statement? Yes, but not through edit-detection techniques. An AI-generated statement has no edit history, so ELA and metadata analysis have nothing to find. Detection relies instead on generation artefacts, template mismatch against the issuer's real format, and internal consistency errors that generative models still make. Always include an AI-generated document in a vendor evaluation - it is the case where results diverge most. ### What false-positive rate should I expect? It depends heavily on your document mix, which is why a headline number from a vendor deck is not informative. Scanned, stamped, and photographed documents flag more readily than digitally-issued PDFs. The practical approach is to run 50 documents you know are genuine and representative through the system and measure the rate yourself, then weigh the manual-review cost of those flags against the fraud caught. ### Should we build document tampering detection in-house? Rarely. The individual forensic algorithms are well documented and not difficult to implement. The expensive parts are calibration against a large labelled corpus, false-positive suppression that does not silence true positives, keeping pace with adversarial drift, and producing auditable explanations. Most teams get better results buying detection and building their own routing, review queue, and audit workflow around it. ### How long should a document verification take? About a minute is a reasonable target for a full forensic analysis of a multi-page document. Sub-second responses generally indicate a shallow check set. What matters as much as the average is the behaviour under load - confirm the system queues rather than failing open when saturated.