Fraud and data quality
Red flags, and how constraints protect the numbers.
Two things undermine every number an analyst reports: claims that should not be paid, and data that should not exist.
Red flags
Fraud teams look for patterns that are more common in dishonest claims, then investigate; a flag is a reason to look, not proof. Harbour Mutual's adjusters record flags in each claim's file (claim_documents.doc -> 'fraud_flags'):
- Loss soon after inception: a claim within 30 days of cover starting, as if the policy was bought for a loss already expected.
- Reported late: months between loss and report, when evidence is harder to check.
- Inconsistent account: the story changes, or does not match the damage.
- Repeated claims: the same customer, or the same item, again and again.
Of Harbour Mutual's 1,534 claims, 156 carry a flag; 17 of those were rejected (11%), against 75 of the 1,378 unflagged claims (5%). The flags are doing their job: they pick out claims more likely to be refused.
Data quality
Bad data produces confident, wrong answers: a policy that ends before it starts has negative exposure; a duplicate policy number double-counts premium. The dimensions analysts check:
| Dimension | Question | What the database can enforce |
|---|---|---|
| Completeness | Is every required value there? | NOT NULL |
| Validity | Is each value possible? | CHECK (end_date >= start_date) |
| Uniqueness | Is each thing recorded once? | UNIQUE, primary keys |
| Consistency | Do related records agree? | foreign keys, triggers |
On Day 5 you will add these rules to Harbour Mutual's tables; on Day 7, a trigger that refuses a claim outside its policy period; on Day 9, you will search the adjusters' files for flags.
Check your understanding
Answer every question, then check.