Legal, Compliance & GovTech
Document Authenticity API
A document that has been altered usually leaves traces. Finding them is useful; calling it fraud on that basis is not.
- Lending and onboarding platforms
- Insurance claims systems
- Letting and property platforms
- Background screening firms
- Public sector case handling
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Any process that accepts documents from the public receives altered ones. Payslips with an edited net pay figure, bank statements with a transaction removed and the balances recalculated, invoices with a changed date, utility bills rebuilt in a word processor to prove an address that was never held. Most are not sophisticated. They are visible if someone looks carefully, and nobody has time to look carefully at every document.
Reviewers develop instincts and apply them unevenly. A statement that looks slightly wrong gets challenged when the queue is quiet and waved through when it is not, and the instinct itself is unevenly distributed — a reviewer unfamiliar with a foreign bank's layout may flag a perfectly genuine document, which is a fairness problem as much as an efficiency one. Consistent, explainable checks applied to every document are better on both counts.
The crucial design decision is what the output claims. Detectable signals — an edited PDF object, a font inconsistency within a figure, arithmetic that does not reconcile, metadata showing editing software after the stated issue date — are evidence that warrants a question. They are not proof of forgery, and the inferential gap is genuine: documents are legitimately re-saved, redacted, scanned, exported from portals and reconstructed by banks. Accusing a real applicant of fraud has consequences — a declined application, a withdrawn offer, a criminal referral, a fraud database entry that follows them for years. The output has to be indicators with reasons, routed to a human, with the benign explanations stated alongside.
Who buys this
Lending and onboarding platforms, Insurance claims systems, Letting and property platforms, Background screening firms, Public sector case handling
What the API returns
What comes back
- Per-document indicator list, each with the specific observation and where it was found
- Confidence per indicator and the known benign explanations for it
- Internal consistency checks — arithmetic, balances, date sequences, totals against line items
- Cross-document consistency across a submitted bundle
- Document structure analysis for signs of editing, splicing or regeneration
- Template conformance against known issuer layouts where a reference exists
- Overall triage priority with an explicit 'no indicators found' outcome
- Review record retaining what was observed, for appeal and audit
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/documents | Submit a document or bundle for analysis |
| GET | /v1/documents/{id}/indicators | Indicators with observations and benign explanations |
| POST | /v1/documents/{id}/consistency | Internal and cross-document consistency checks |
| GET | /v1/documents/{id}/structure | Structural and metadata findings |
| POST | /v1/review | Record a reviewer decision and outcome |
| GET | /v1/performance | Measured indicator precision from recorded review outcomes |
Request and response
illustrativeRequest
{
"case_ref": "case_31882",
"documents": [
{ "doc_id": "d1", "type": "bank_statement", "url": "s3://tenant-12/d1.pdf",
"claimed_issuer": "gb-bank-0041", "claimed_period": "2026-08" },
{ "doc_id": "d2", "type": "payslip", "url": "s3://tenant-12/d2.pdf",
"claimed_period": "2026-08" }
],
"checks": ["structure", "consistency", "cross_document", "template"]
}Response
{
"case_ref": "case_31882",
"analysed_at": "2026-10-21T13:22:40Z",
"documents": [
{
"doc_id": "d1",
"triage": "review_recommended",
"indicators": [
{ "indicator": "arithmetic_mismatch", "confidence": "high",
"observation": "Running balance differs from prior balance plus transactions by 412.00 on 2026-08-14",
"benign_explanations": ["pending transaction excluded", "fee posted outside statement period"] },
{ "indicator": "font_inconsistency_in_numeric_field", "confidence": "medium",
"observation": "Glyph set for one amount differs from the rest of the column",
"benign_explanations": ["portal re-render", "redaction and re-save"] }
]
},
{
"doc_id": "d2",
"triage": "no_indicators_found",
"indicators": [],
"note": "Absence of indicators is not evidence of authenticity."
}
],
"cross_document": [
{ "check": "net_pay_vs_credit", "result": "mismatch",
"observation": "Payslip net pay 2,418.60; no matching credit in statement period",
"benign_explanations": ["paid outside statement window", "split payment"] }
],
"disposition": "human_review_required",
"not_a_verdict": "Indicators are evidence for a reviewer. This response makes no finding of fraud."
}Where the data comes from
| The submitted documents themselves | Processed under your own lawful basis, with retention and deletion governed by your policy rather than ours |
| Issuer template references | Known layouts for common issuers, built from genuine documents your customers have already verified — coverage is inevitably partial and biased towards large issuers |
| Document format specifications | PDF, image and office format internals, which is where structural editing evidence actually lives |
| Your historical review outcomes | Confirmed genuine and confirmed altered documents, which is the only way indicator precision can be measured honestly |
| Authoritative verification routes | Open banking, payroll APIs and issuer confirmation — where available these replace authenticity analysis entirely and should be preferred |
| Your fraud policy and decision rules | Not a data source but a constraint: what happens after an indicator is raised has to be your documented decision, not an API default |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Structural analysis of document internals — incremental updates, object generations, embedded font subsets, producer metadata — which is where editing traces survive most reliably
- Arithmetic and consistency checking against the document's own stated figures, which catches more real alteration than any image-forensic technique
- Cross-document reconciliation across a bundle, since an altered figure usually fails to agree with something else the applicant submitted
- Template conformance where a verified reference exists, with explicit absence of a reference reported rather than treated as non-conformance
- A benign-explanation set attached to every indicator type, maintained deliberately, because an indicator presented without its innocent explanations will be read as an accusation
- Calibration against reviewer-confirmed outcomes with precision reported per indicator, so your team knows which indicators are worth acting on and which are noise
- Bias testing across issuer, country and document origin, because an indicator that fires disproportionately on foreign or small-issuer documents will produce discriminatory outcomes even with accurate mechanics
- No overall authenticity score — deliberately. A single number invites an automated decision on evidence that does not support one
What it changes for the business
Consistent review
Every document gets the same checks, which removes the variance between a careful reviewer and a busy one.
Reviewer time where it matters
Triage concentrates attention on documents with specific, stated observations rather than on a random sample.
Defensible decisions
An indicator record with observations and benign explanations supports a decision and survives an appeal.
Measured usefulness
Per-indicator precision from your own outcomes tells you which checks earn their review time.
How it fits into your product
How it embeds
- REST submission with webhooks on completion, since bundle analysis is not synchronous
- Indicator output designed for a review interface — observation, location and benign explanations side by side
- Review decision endpoint capturing the outcome, which is what makes precision measurement possible
- Deployment inside your infrastructure, which is the normal arrangement for customer identity and financial documents
- Hand-off to authoritative verification where it exists, so open banking or payroll confirmation is preferred over inference
- Configurable retention and deletion, with indicators retrievable after the document itself has been deleted
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Does this prove a document was forged?
No, and that limit is deliberate throughout the design. It reports observations — arithmetic that does not reconcile, a font inconsistency inside one figure, editing metadata dated after the stated issue date — each with the benign explanations that could also account for it. Documents are legitimately re-saved, redacted, scanned and regenerated by issuers. The output is evidence for a human reviewer to weigh, and we do not return an overall authenticity score, because a single number gets wired into an automatic decline.
What happens if you flag a genuine document?
A person reviews it and, with the benign explanations in front of them, often resolves it in under a minute. That is why the indicators carry explanations rather than verdicts. The failure mode we design hardest against is an automated decline on an indicator alone: a wrongly accused applicant can face a withdrawn offer, a referral and a fraud database entry that follows them for years, and none of that should rest on a font anomaly.
Can it detect every alteration?
No. A competently rebuilt document with internally consistent figures and no structural traces can pass every check here. 'No indicators found' means exactly that — the API says so explicitly rather than returning a clean bill of health. Where an authoritative route exists, such as open banking for statements or a payroll API for income, use it instead; it is stronger evidence than any authenticity analysis and we would recommend it over our own output.
Will it work on documents from issuers you have no template for?
Partially. Structural and arithmetic checks work regardless of issuer. Template conformance needs a verified reference, and coverage skews towards large issuers in major markets. We report the absence of a reference as absence, never as non-conformance — otherwise every small or foreign issuer's documents would look suspicious, which is a fairness failure before it is an accuracy one.
How do you stop it being unfair to certain applicants?
By measuring it. Indicator rates are tested across issuer, country and document origin, and an indicator that fires disproportionately on foreign or unfamiliar documents is retuned or retired. We also report per-indicator precision from your own confirmed outcomes, so an indicator that generates review work without catching anything can be switched off on evidence rather than opinion.
Related blueprints
Credential Verification API
Verification of education and professional qualifications through authorised issuers and registers, returned as a single call with a documented evidence trail.
Contract Intelligence API
Clause extraction, obligation tracking and renewal alerting across a contract portfolio, as an API your legal or procurement software embeds.
Regulatory Change Monitoring API
Monitoring of regulatory and legislative change, mapped to the functions it affects, delivered as an alert feed inside compliance software.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.