What a document authenticity analysis architecture has to do
A document authenticity pipeline answers a narrow question: does this file show evidence that it was forged, altered or generated, and how much of it could we actually examine? It does not decide whether the person is who they claim, whether a business is legitimate or whether a loan should be approved. Those are separate decisions that consume its output.
The inputs fall into two groups with different evidence. Captured ID documents arrive as photos or video frames of a physical card or passport, where physical security features and capture conditions matter. Native digital documents such as PDF bank statements, payslips and registration certificates carry internal structure, fonts, metadata, revision history and sometimes digital signatures. A good architecture routes each type through the views that apply and records which views were skipped.
Intake, preservation and sandboxed parsing
Every analysis starts by making the original immutable. Compute a cryptographic digest, record declared and detected file type, size, encryption state and how the file was acquired, and store the original read-only. All later work happens on copies, because flattening or re-saving a PDF can remove the incremental updates and embedded objects that reveal editing.
Untrusted documents are also an attack surface. Parse and render them in an isolated environment with active content and external retrieval disabled, and enforce limits on pages, objects, decompression ratio, memory and execution time. Password-protected, corrupted, oversized and unsupported files each need their own outcome code rather than a generic error.
- Hash the original, every rendered page and every extracted artifact.
- Record parser, renderer, OCR and model versions with each run.
- Disable scripts, external fonts and remote resources during analysis.
- Return distinct states for encrypted, corrupted, unsupported and resource-limited files.
The five evidence views and what each can find
Each view looks at the document in a different way and fails in a different way, which is why they should run independently and report separately. A hidden text layer shows up in the structural view but not the rendered one; a photographed card has no native structure at all.
NIST SP 800-63A-4 gives several anchors for captured identity documents. Automated validation must meet stated document false acceptance and false rejection performance measures, must compare MRZ or barcode data with the printed data where present, and must use live capture with document presence checks. It also notes that its physical-evidence requirements do not apply to validation that relies on PKI or other cryptographic technology embedded in the evidence.
| View | Inputs | What it can find | Typical blind spot |
|---|---|---|---|
| Structural | Native file objects, fonts, metadata, revision history, attachments | Incremental edits, mismatched producers, inserted objects, hidden layers | Flattened files and photos have little or no structure |
| Visual | Rendered page or captured image | Splicing, copy-move, inconsistent fonts or alignment, generative image traces | Heavy compression and recapture blur the evidence |
| Textual | Native text and OCR, MRZ and barcodes | Field inconsistencies, MRZ check digits or data that disagree with printed fields | OCR errors on poor captures |
| Capture and security features | Live capture frames, document presence signals | Screen or print recapture, missing holographic response, static image submitted as live | Not applicable to native PDFs |
| Cryptographic and provenance | Digital signatures, eMRTD chip data, C2PA manifests | Proof of integrity and issuer within a trust chain | Absence proves nothing; many genuine documents are unsigned |
How AI-generated documents change the design
Generative AI shifts the threat from editing a real document to producing a new one. FinCEN's alert FIN-2024-Alert004 of 13 November 2024 reports criminals using generative AI to alter or generate images for driver's licences and passport cards and books, sometimes paired with stolen or fake personal data. 404 Media reported in February 2024 that a site called OnlyFake sold AI-generated ID images for $15 and that one passed a cryptocurrency exchange's verification.
Three design consequences follow. First, the visual view needs models trained to recognise generated imagery, not only splicing and copy-move. Second, live capture becomes more important, because a generated ID exists only as pixels; requiring a live, multi-frame capture of a physical card raises the cost of using one. Third, cross-document and cross-field consistency checks gain weight: FinCEN lists inconsistencies among multiple identity documents, and between a photo and the stated date of birth, among its red flags. The page on AI-generated document fraud detection covers the fraud side in more depth.
Designing the output: findings, coverage and component states
The pipeline's output should let a reviewer and an auditor answer three questions: what was examined, what was found, and how sure the system is. A single authenticity score hides all three.
Model partial analysis honestly. A document can parse structurally while one page fails to render, or render while its signature cannot be validated because a trust resource was unavailable. Calculate coverage by page and view, and never let a skipped view read as a pass.
- Per view: status (completed, failed, skipped, encrypted, unsupported), findings, confidence and version.
- Per finding: page, region coordinates or object reference, description and supporting artefact.
- Coverage: pages and views analysed versus total, with reasons for any gaps.
- Provenance: signature validity, trust chain and timestamp status, or a clear statement that none was present.
- Overall: a risk band for routing, always accompanied by the per-view detail.
Review routing and testing the pipeline
Route on the per-view findings, not only the overall band. A failed cryptographic check on a document that should be signed is a stronger signal than a font anomaly on a scanned letter. Reviewers need the preserved original, page previews with highlighted regions, extracted text with confidence, structural observations and processing limitations in one view. The guide to human review routing describes how to size and staff that queue.
Test every view and failure path with approved fixtures: scanned and native pages, hidden text, annotations, attachments, signed and unsigned files, encrypted and damaged files, recaptured screens and prints, and generated ID images. Inject parser, renderer, OCR and trust-resource failures and check that the output reports them. Keep old findings intact when parser or model versions change so earlier decisions remain explainable.
Where Neural Defend fits in a document analysis architecture
NeuroDetect is the Neural Defend component for document review. Analysts upload an authorised document, image, audio or video into a case; each analysis keeps model and version context, and detailed views, including explainability heatmaps, point to specific regions. The downloadable forensic report records observations, uncertainty, provenance, model context and analyst notes, and structured results can be exported into the review package described above.
NeuroVerify covers the face half of an identity check, analysing selfies, video and audio across six signals in one API call with under 200 ms p95 on eligible image requests. It does not analyse ID documents, so the document views in this architecture come from your document verification vendor and NeuroDetect review.
The detection models build on ARCAS 1B, Neural Defend's own detection model; the ARCAS paper reports pooled accuracy of 99.99% on GenImage and 99.82% on AIGC-Detect for AI-generated imagery. Those are image benchmarks, not document benchmarks, so test on your own document fixtures. Deployment options run from managed cloud to on-premises and air-gapped.
Evidence boundary
Limitations
- No single view proves authenticity; a document can pass every check and still carry false data issued genuinely.
- Absence of a signature, metadata or C2PA manifest is not evidence of manipulation.
- NeuroVerify does not analyse ID documents, and ARCAS benchmark figures are for images, not documents.
- NIST SP 800-63A-4 thresholds apply to identity evidence in US federal identity proofing and may not match other regulators' expectations.
Source record
Sources and references
- National Institute of Standards and TechnologySP 800-63A-4, Digital Identity Guidelines: Identity Proofing and EnrollmentPublished July 1, 2025. Verified October 19, 2026.
- Financial Crimes Enforcement Network (FinCEN)FIN-2024-Alert004: FinCEN Alert on Fraud Schemes Involving Deepfake Media Targeting Financial InstitutionsPublished November 13, 2024. Verified October 19, 2026.
- 404 MediaInside the Underground Site Where 'Neural Networks' Churn Out Fake IDsPublished February 5, 2024. Verified October 19, 2026.
- Coalition for Content Provenance and Authenticity (C2PA)C2PA Technical Specification 2.2Verified August 7, 2026.
- National Institute of Standards and TechnologyNIST AI 100-4: Reducing Risks Posed by Synthetic ContentPublished November 1, 2024. Verified October 19, 2026.
- arXivBenchmarking Neural Defend ARCAS 1B: A Foundational Multimodal Deepfake Detection ModelPublished September 21, 2026. Verified October 19, 2026.







