The Outlier Lab

Case Documentation Standards

What a good fraud case record contains: structured fields, narrative structure, SAR-ready notes, reason codes, retention and access, with copyable templates for alerts, investigations and referrals.

Core components

Structured fields vs narrative

ElementStructured fieldNarrative
DispositionYes (required picklist)Summarized
Fraud type / mechanismYes (taxonomy; see Loss Taxonomy and Attribution)Explained if ambiguous
Actor typeYes (third-party / first-party / organized / insider / victim-authorized)
Amounts: attempted, lost, prevented, recoveredYes
Actions takenYesRationale
Linked entitiesYes (IDs)Link rationale
Evidence reviewedYes (checklist)Key findings
ReasoningYes
ReferralsYes (with timestamps)
Customer contactYes (log)Summary

Structured fields feed labels, metrics and models (see Fraud Labeling and Feedback Loops). The narrative supports judgment, QA and SARs. A case needs both, and neither substitutes for the other.

Narrative structure

Every case narrative follows Facts → Analysis → Conclusion → Action:

  1. Trigger. Why the case exists (alert, referral, complaint)
  2. Facts. What the evidence shows, in chronological order, with sources
  3. Analysis. What the facts mean; indicators present and absent; innocent explanations considered
  4. Conclusion. Finding and confidence level (see Investigation Standards)
  5. Action. What was done, and why it's proportionate

Writing rules

  • Use facts instead of adjectives. "Three withdrawals totaling $4,200 to a debit card added 12 minutes after a phone-number change" beats "suspicious withdrawals."
  • Source every fact. "Per login logs," "per customer call recording," "per device report."
  • Dates and times in a consistent time zone.
  • Distinguish observation from inference. "Device ID matches 6 other accounts (observed). Likely common control (inference)."
  • Record exculpatory evidence. "Customer has 4-year tenure and prior withdrawals to a similar bank."
  • No speculation about protected characteristics. No opinions on the customer's character.
  • No detection-method detail in customer-facing fields.
  • Plain language. Expand acronyms on first use for readers outside fraud.
  • Write for a stranger. Someone with no context should be able to reconstruct the decision.

How to build it

SAR-ready notes

Where a case may lead to a SAR, the case record should already contain what the BSA function needs to write the narrative. The classic structure is who, what, when, where, why and how (see BSA-AML and SAR Filing):

ElementWhat to capture
WhoSubjects (account holders, linked parties); victims; identifiers as held in records
WhatThe activity: instruments, transaction types, amounts, accounts
WhenDates and time span; date of initial detection
WhereAccounts, branches or channels, locations, counterparties' institutions
WhyWhy it's suspicious: the indicators and how they deviate from expected activity
HowHow the scheme operated, conceptually: the MO and the money flow

Also capture:

  • Date of initial detection. This starts SAR clocks: generally 30 days for banks, extendable to 60 if no suspect is identified.
  • Relevant FinCEN SAR key terms where an advisory or alert asks for one (e.g., the 2023 pig-butchering alert and the 2024 deepfake alert each specify one)
  • Supporting documentation location. For banks, supporting documentation is treated as filed with the SAR and must be retained for five years.

Reason codes

Every customer-facing action needs:

  • An internal reason code (specific, from the taxonomy)
  • A customer-facing message category (general, approved by legal and compliance)
  • A support script reference

This lets support explain actions consistently without exposing detection logic, and lets complaints teams trace outcomes to rules (see Rule Governance and Change Management).

Regulatory documentation

ContextDocumentation requirement (summary; confirm with compliance)
Reg E claimsDate of notice, investigation steps, provisional credit dates and amounts, findings, notices to the consumer, and timing against the 10-business-day / 45- or 90-day windows (see Regulation E and Unauthorized Transfers)
Card disputes / representmentCompelling evidence per network rules (see Card Network Dispute Rules)
ACH returns and claimsReturn codes, authorization evidence, Nacha-required records (see Nacha Rules and ACH Risk)
Broker-dealerTrusted contact use, temporary holds and their basis (see Broker-Dealer Obligations (FINRA and SEC))
Account closuresBasis for closure, notices sent, funds disposition

Retention and access

  • Retention periods set with legal and compliance by record type. SAR supporting documentation for banks: five years from filing.
  • Access to case records is least-privilege and logged (see Insider Access Controls)
  • Edits to closed cases are versioned with reason
  • Attachments stored in the case system rather than personal drives or chat
  • Privacy requirements for sensitive data (see Privacy and Data Use in Fraud Prevention)

Artifacts and templates

Alert decision note (short form)

Trigger: [Rule/model ID] – [one line]
Evidence reviewed: [checklist items]
Key facts: [2–4 bullet facts with sources]
Assessment: [why this is / isn't consistent with fraud; innocent explanations considered]
Decision: [disposition] | Confidence: [level]
Action: [what was done]
Reason code: [code]

Investigation case summary (long form)

1. Case ID / tier / investigator / dates
2. Trigger and investigation question
3. Subjects and linked entities (IDs + link rationale)
4. Timeline of key events (dated, sourced)
5. Money flow: in → movement → out; amounts; recoverable funds
6. MO and actor classification
7. Analysis: indicators present/absent; exculpatory evidence
8. Conclusion and confidence
9. Actions: account, recovery, victim remediation
10. Referrals: AML/BSA (date), legal, law enforcement, partners
11. Label updates (all entities)
12. Lessons / rule & model feedback

Referral to BSA/AML template

Referral date/time | Date of initial detection
Subjects (internal IDs) | Accounts involved
Activity summary (who/what/when/where/why/how)
Amounts and date range
Relevant FinCEN key term(s), if applicable
Evidence location (case system link)
Fraud team contact

Documentation QA checklist

  • Structured fields complete and consistent with narrative
  • Narrative follows Facts → Analysis → Conclusion → Action
  • Every fact sourced
  • Observation and inference separated
  • Exculpatory evidence considered
  • Action proportionate to stated confidence
  • Referrals timestamped
  • Reason code correct
  • No SAR references in customer-visible fields
  • No unnecessary sensitive data

Metrics

MetricWhy
Documentation QA pass rateQuality (see Fraud QA Program)
Structured-field completenessLabel and metric reliability
Disposition vs narrative consistencyLabel accuracy
SAR referrals returned for insufficient informationReferral quality
Time to document (part of handle time)Efficiency; templates should reduce it

Pitfalls

  • "Suspicious, declined." Notes that record a conclusion without facts.
  • Copy-paste narratives. Templates help structure but shouldn't replace thinking. QA should look for identical narratives across different cases.
  • Narrative contradicts disposition. The model trains on the disposition, so the inconsistency poisons labels.
  • Evidence in chat threads. Chat isn't retained or searchable, so the evidence can't support the decision later.
  • Over-documentation. Pages of screenshots no one reads; capture what supports the conclusion.
  • AI-drafted narratives unchecked. Summaries can omit or invent facts. The analyst owns every sentence.

Sources and further reading