Fraud Detection
On products where fraud detection is enabled, each eligible document attached to a claim is analysed automatically before it reaches a claims manager. This page explains what that analysis looks for, how to read the score and verdicts, when it runs, and how the short AI summary at the top of each claim is produced.
What happens to each document
Every supporting document runs through the same automated pipeline. Each document is analysed on its own, so a single altered payslip is never hidden by clean documents around it.
- Uploaded
The claimant attaches the document to the claim.
- Classified
AI identifies the document type: payslip, IBAN, ID card, and so on.
- Data extracted
Key fields are read from the document: amounts, dates, names, identifiers.
- Fraud analysis
The checks below run on the file and its extracted fields, producing a score and a verdict.
- Result forwarded
Once the verdict is final, it is sent to the insurer alongside the document.
The signals it looks for
The analysis is Korint's own — there is no third-party fraud vendor. Findings combine Korint's AI checks with in-house rule-based checks across several layers: the document's content and identity fields, its digital history, the pixels of the image itself, and an AI reading of the document as a whole.
The checks below always run on every eligible document.
| Check | Layer | What it looks for |
|---|---|---|
| AI document examiner | AI vision | Reads the whole document like a trained examiner: typography consistency, completeness of the expected content, and signs that the document was generated or altered by AI. This is a primary tamper signal. |
| Partner checklist (vision) | AI vision | Applies the documentary-fraud rules specific to the partner, including provider and geographic-distance plausibility (for example, a repair invoice from a garage implausibly far from the incident). |
| Pixel forensics | Pixel tampering | Runs on every image: Error Level Analysis highlights regions re-saved or edited after the original, and copy-move detection finds areas duplicated within the same image to cover or fabricate content. |
| MRZ reconciliation | Identity documents | On an ID card or passport, decodes the machine-readable zone and compares it to the printed face: document number, expiry date, birth date. A mismatch is conclusive tampering. |
| Field validation | Content | Checks extracted values against their own rules, e.g. an IBAN that fails its mod-97 control key. |
| Company registry | Content | Reconciles a SIREN/SIRET against the official registry to confirm the named company exists and matches. |
| Date consistency | Content | Cross-checks dates within and across documents, e.g. a footer timestamp earlier than the transaction it describes. |
| Digital history | Metadata | File created, modified, or produced by editing software after the date it should have been issued. |
Experimental checks
The following pixel-level checks are experimental and off by default. They are enabled selectively and are not currently active for the live partner.
| Check | Layer | What it looks for |
|---|---|---|
| OCR glyph geometry | Pixel tampering | Re-typed text: a word whose letter spacing, baseline, or character size no longer matches the rest of the line. |
| Noise residual (PRNU) | Pixel tampering | Inserted content: an area missing the faint, uniform sensor and paper grain present everywhere else on the page. |
| Background continuity | Pixel tampering | Erased or painted-over fields: a flat patch of uniform colour sitting inside a block of text. |
The score and the verdict
Each document gets a score from 0 to 100, where higher means more suspicious. The score maps to one of three verdicts you see on every document row.
- Clean
No meaningful signal. The document looks consistent and untouched.
- Review needed
One or more signals worth a human look before deciding. Not a conclusion.
- Fraud suspected
Strong evidence of tampering or a major inconsistency in the document.
The claim-level verdict
Above the documents, each claim carries a single verdict and score rolled up from its documents: the worst verdict wins and the score is the highest of any document, so one tampered piece is never diluted by clean ones. The same rollup drives the claim list — the risk sort, the verdict filter and the triage counts.
Only documents currently attached to the claim count towards it. When a claimant replaces a document or you remove one, its analysis is kept as history but stops feeding the claim verdict, the claim score, the "documents flagged" counts and the AI summary. So a claim whose only suspicious document was replaced drops back to the verdict its remaining documents justify, and a claim whose scored documents have all been removed shows no verdict at all until something new is analysed.
Your verdict comes first
The automated verdict is a starting point, never the final word. On any document you can set Clean, Review needed, or Fraud yourself and add a note. Your verdict overrides the automated one everywhere it is shown, and the claim summary updates to reflect it.
The AI summary
At the top of each claim, a few short bullets restate the document findings so you can triage at a glance. Each bullet links to the document it refers to.
It only restates, it never invents. The summary is generated strictly from the findings already on the documents. It adds no conclusion, figure, or recommendation of its own. The per-document analysis remains the source of truth.
When you override an automated verdict, the summary notes that one or more verdicts were modified by a manager.
When the analysis runs
Fraud detection is enabled per product and per partner, so it does not run on every claim across the platform — today it runs for a single partner. On products where it is enabled, a document is still skipped from analysis when:
- The file is infected — a document flagged by the antivirus scan is never analysed.
- The claim is below the minimum amount — claims under a configured threshold (for example €500) skip analysis, so low-value claims are not held up.
On the roadmap
Per-partner geographic and amount plausibility already ship today through the partner checklist check. The next step is claim-wide reasoning that cross-references documents against each other and against the outside world. Directions we are building toward (subject to change):
| Direction | Status | Question it answers |
|---|---|---|
| Geographic plausibility | Shipping (per partner) | Are the distances between the declared locations realistic for the incident described? |
| Amount / provider-distance coherence | Shipping (per partner) | Do the amounts reconcile, and is the provider plausibly located for the declared incident? |
| Cross-document date coherence | Next | Do the dates across every document in the claim tell one consistent story? |
| Identity reconciliation | Exploring | Name, date of birth, address, and IBAN holder agree across the ID, RIB, payslip, and claim form. |
| Reused-document detection | Exploring | The same receipt, photo, or PDF submitted across several claims, or a reused template. |
| Incident corroboration | Exploring | Cross-check the declared date and place against external data: weather, events, registries. |