Case Study: Fraud Signalling (Not Fraud Detection)
This page is deliberately titled differently from what you might expect. Hoziron does not ship a standalone fraud-detection or fraud-scoring product, and there is no real ML-based fraud model, network-analysis agent, or automated "fraud score → SIU" decision pipeline in the codebase today. What exists is a fraud-signalling step inside the FNOL claims pipeline — real, packaged, and specifically designed to stop short of a determination. This case study describes that.
What actually exists
fnol-fraud-signal-agent (packages/agents/analysis/fnol-fraud-signal-agent) is Phase 3a of the six-agent FNOL pipeline (see claims-intake.md). Its package metadata categorizes it as insurance/fraud/detection, but its own instructions state the boundary explicitly:
Under the FAIS Act and South African market-conduct rules, a fraud finding is a human, accountable decision. You produce signals only — evidence and a tier recommendation. You never state, imply, or record that a claim is fraudulent, that a claimant is dishonest, or that a claim should be repudiated for fraud.
This is enforced as an agent-level constraint (fais-advisory-boundary, no-decisions competencies), not left to prompt discipline alone.
The signal model
Given the intake record, validation report, and prior-claims summary, the agent evaluates a fixed set of SA-calibrated signals and outputs, for each: name, fired (true/false), evidence, and weight (low/medium/high):
| Signal | What it checks |
|---|---|
inception_proximity | Policy incepted < 90 days before the loss |
recent_coverage_upgrade | Coverage increased/added < 30 days before loss |
claim_frequency | More than one claim in the trailing 12 months |
geographic_clustering | Loss location anomalous vs. the insured's known area, or matching a known cluster pattern |
temporal_pattern | Time-of-loss consistent with known SA crime patterns for the loss type |
description_inconsistency | Internal contradictions, or mismatch between described damage and loss type |
documentation_gaps | Missing SAPS case number, missing required evidence |
vehicle_or_identity_mismatch | Carried forward from the validation phase |
The agent sums to a fraud_signal_count, assembles an evidence chain a human reviewer can follow fact-by-fact, and recommends a triage tier — none / low / elevated — explicitly labeled a recommendation, not a determination. Per the FNOL human-handoff matrix, 3+ fraud signals route the claim to the Special Investigations Unit (SIU) for human review before the claim progresses.
What you can actually see run today
Phases 1, 2, and 3a of the real 6-agent pipeline execute against the pipeline's own packaged agents and prompts; the full pipeline does not currently complete past Phase 3b (severity scoring — Issue #589, see claims-intake.md). The --reduced 4-step sandbox stand-in that runs end-to-end today does not include a fraud-signalling step at all — it is a simplified intake → draft → confirm → notify chain built to prove the autonomous trigger mechanism, not the full regulatory pipeline. So today, in the sandbox, you can inspect and run fnol-fraud-signal-agent directly as an installed agent package, but you cannot yet watch it hand off cleanly to Phase 4 in one unattended run.
What is not real (and not planned as described)
There is no ML-trained fraud model, no cross-claim network-analysis agent, and no automated "fraud score above threshold → auto-flag" decision path anywhere in the codebase. The FNOL specification explicitly scopes "basic fraud signals (pattern-matching, not ML)" to the current phase and defers "advanced fraud scoring (ML-based, trained on carrier data)" to a later phase — check the product roadmap for current sequencing before committing to a timeline with a carrier.
Related: