Detect Fake Documents — Government, Benefits & Specialised PDFs
A category hub for fake-document detection use cases that don’t fit the major document buckets — government scheme PDFs, retirement and superannuation statements, regional benefit forms. The same structural API that powers our other hubs, applied to specialised document types.
Scope
HTPBE? analyzes the structural layer of the PDF file. We do not validate the document against the issuing authority’s database (NDIS portal, ATO, individual super funds, etc.). For database-verification workflows, combine HTPBE? with the issuer’s verification API where one exists. HTPBE? catches the editing and fabrication layer that database lookups miss.
Government, scheme, and regional documents come from a heterogeneous set of issuers — some institutional, some via Office or letterhead templates. INCONCLUSIVE verdicts must be interpreted in the context of the specific issuer. The page-level guides below explain the expected producer fingerprints for each document type.
Specialised documents fly under the fraud radar
Visa officers, benefits administrators, lenders, insurers, and HR teams all accept specialised documents — NDIS plans, superannuation statements, benefit award letters, regional permits — as proof of eligibility, income, or status. These documents rarely have central verification APIs, so reviewers fall back on visual inspection.
Visual inspection misses every form of structural fabrication. A specialised document edited in a consumer PDF tool looks identical to its source — until the binary is examined. The producer field, the cross-reference table count, the modification timestamps tell a story the rendered page hides.
Each spoke under this hub addresses a specific document type with the patterns and signals unique to that issuer. The hub aggregates the patterns; the spokes deliver the depth.
Why specialised docs are high-fraud
- Few central verification databases for reviewers to query
- Long-tail issuers — no per-document AI training data
- Visual templates are easy to clone; structural origin is harder to fake
- Reviewers default to visual checks when database access is unavailable
- Fraud rings target categories with the weakest verification infrastructure
How structural analysis works on specialised documents
Same engine, document-type-specific interpretation
Producer fingerprint matched to known issuer profile
Each spoke under this hub maintains a profile of expected producer fingerprints for the document type. NDIS plans come from the NDIS portal export. Superannuation statements come from fund-specific reporting systems. A producer mismatch is the most reliable structural fraud signal.
Incremental update detection
A clean issuance carries one cross-reference table. Any edit appends a second xref. The marker fires regardless of document type — the meaning depends on the issuer profile.
Modification timestamp gap
Issuance date should match the embedded creation timestamp. Gaps between Issue Date / CreationDate / ModDate are high-confidence flags on documents where issuance is supposed to be a single event.
Image-stream artefacts on official seals
Government and scheme documents typically embed institutional seals or logos as part of the template. Lifted seals carry mismatched compression characteristics that structural analysis exposes immediately.
Why this hub exists
Structural fraud detection for documents without their own category
One API, many specialised types — same /api/v1/analyze endpoint handles every PDF
Clear per-document-type signal interpretation in each spoke page
Self-serve from $15/mo with API key at signup, no sales call
New specialised document types added based on customer reports of recurring fraud patterns
Returns named markers (KNOWN_EDITOR_IN_PRODUCER, INCREMENTAL_UPDATE, MODIFIED_AFTER_SIGNATURE) for fraud-team triage
Five forensic layers, one deterministic verdict
Every PDF we receive passes through the same structural pipeline — no model training, no thresholds to tune.
Metadata analysis
Creation and modification timestamps, producer and creator fields, XMP metadata — the first layer exposes basic tampering.
File structure
Xref tables, trailer chain, incremental updates. Any edit after export leaves a structural fingerprint here.
Digital signatures
Signature chain integrity and post-signature modifications produce deterministic markers. Certainty-level signal.
Content integrity
Fonts, objects, embedded content, page assembly. Multi-session edits and inserted objects are visible at this layer.
Verdict with markers
Deterministic output: INTACT / MODIFIED / INCONCLUSIVE, with named markers for every finding — suitable for audit trail.
Customer Stories
Teams that stopped document fraud
Compliance, finance, and risk teams use HTPBE? to catch manipulated PDFs before they become costly mistakes.
Caught an invoice where the total had been changed by less than a thousand dollars. Without this I would have approved it without a second look.
Sarah M.
AP Manager
United States
We had three applicants in the same week with bank statements that looked completely fine. Two of them were flagged as modified. You simply cannot see this by reading the document — it is in the file structure.
Lars V.
Risk Analyst, Online Lending
Netherlands
Salary slips were coming with altered figures. We identified two problematic files before the placement was finalised.
Priya K.
HR Operations Lead
India
Since we started checking documents this way, we stopped two applications early in the process that would have been very difficult to reverse later.
Julien R.
Fraud Analyst, Fintech
France
Some applicants were sending PDFs that looked authentic but had been edited in ways not visible to the eye. We now ask for verified originals when something is flagged. Already saved us from a few bad decisions.
Marta S.
Compliance Coordinator
Spain
One invoice was caught because there was a mismatch between the document dates and structure. That particular case would have cost us significantly.
Tariq A.
Finance Manager
United Arab Emirates
Integrate in minutes
Two calls: POST the document URL, then GET the forensic verdict. Same engine across every spoke.
Request
curl -X POST https://api.htpbe.tech/v1/analyze \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-storage.com/specialised-document.pdf"}'Result (GET /v1/result/{id})
{
"id": "5c8d7e2f-1a3b-4c6d-9e0f-7a4b2c8d3e5f",
"status": "modified",
"modification_confidence": "high",
"modification_markers": [
"Known PDF editing tool detected",
"Producer mismatch with expected issuer system",
"Different creation and modification dates"
],
"tools_detected": [
{ "name": "Microsoft Word", "category": "consumer-editor" }
]
}Per-document interpretation: Each spoke under this hub maintains an issuer profile — what producer fingerprints, signature chains, and timestamp patterns are normal for that document type. INCONCLUSIVE means the structural signature does not match the expected issuer profile, which itself is often a high-confidence fraud signal.
Pricing
Self-serve plans. No sales call, no procurement process.
Starter
$15/mo
30 checks/mo
Manual spot-checks for small operations teams
Growth
$149/mo
350 checks/mo
Mid-volume KYC and benefits-administration teams
Pro
$499/mo
1,500 checks/mo
Government contractors and large compliance ops
Enterprise (unlimited, on-premise available) — see full pricing and docs
API key on signup. Free test environment on every plan. No card required.
Frequently Asked Questions
Which specialised documents does this hub cover?
Currently NDIS plan documents (Australia) and superannuation member statements (Australia). New types are added based on customer demand — typical additions are regional benefit award letters, government scheme correspondence, and member statements from financial schemes that don’t fit other hubs.
How does this differ from the top-level Document Fraud Detection API?
The /document-fraud-detection-api page is the top-level API hub for developers. This page is a use-case hub that groups specialised document types together. Both are powered by the same engine — this hub adds document-type-specific guidance.
Can I request a new specialised document type?
Yes. Most additions are reactive — when a customer reports a recurring fraud pattern on a document type that doesn’t fit existing hubs, we add a spoke under this hub with the issuer profile and known patterns.
Are these documents region-specific?
Yes, frequently. NDIS is Australian. Superannuation is Australian. Other regional documents — Indian benefit letters, UK scheme correspondence, EU national-document fraud — fit the same model. The structural API is region-agnostic; the page guidance is regional.
Secure your workflow
Create your account — API key on signup, free test environment on every plan.
From $15/mo. No sales call. Cancel any time.
Related: Document Fraud Detection API →
Integrate specialised document fraud detection
One API endpoint covers every spoke under this hub — NDIS plans, superannuation statements, and any future regional documents.
# Step 1: Submit PDF for analysis
curl -X POST https://api.htpbe.tech/v1/analyze \
-H "Authorization: Bearer htpbe_live_..." \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/document.pdf"}'
# Returns: {"id":"3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21"}
# Step 2: Retrieve full results
ID="3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21"
curl -s "https://api.htpbe.tech/v1/result/$ID" \
-H "Authorization: Bearer htpbe_live_..." \
| jq '.status'