The Outlier Lab

Case Management Systems

The system of record for fraud alerts, investigations, decisions and outcomes, linking evidence, entities and actions so cases are consistent, auditable, reportable and usable as labels.

What it is

A case management system (CMS) is the fraud team's system of record. Alerts from rules, models, customers, support, partners and law enforcement land there. Analysts work them, gather evidence, take actions and record outcomes. Regulators, auditors and lawyers later ask what happened, and the CMS is where the answer lives.

It's listed as a control because of what you lose without one. Without a CMS you can't measure catch rate, you can't train models on investigator decisions, you can't prove you met regulatory deadlines, and you can't see that the case you closed yesterday is linked to the ring you're investigating today.

What it stops (and what it doesn't)

Enables:

  • Consistent investigation: templates, checklists and required fields by case type (Investigation Standards).
  • Entity-centric investigation: cases attached to people, accounts, devices and destinations as well as transactions, so related cases appear automatically.
  • Regulatory timelines: SAR deadlines, Reg E deadlines, Rule 2165 notification and hold timelines, all tracked with alerts.
  • Labels: structured outcomes feed Fraud Labeling and Feedback Loops.
  • QA and audit: every decision is reviewable (Fraud QA Program).
  • Incident coordination: grouping cases into an incident or ring for coordinated action (Fraud Incident Response).

Doesn't do:

  • Detect fraud. It routes and records.
  • Fix poor investigation practice. If every field is free text, the CMS is an expensive notebook.

Design considerations

Alerts and cases

Keep alerts and cases separate. Alerts are signals: high volume, mostly closed fast (queue operations are in Alert Review Operations). Cases are investigations: lower volume, longer-lived, evidence-heavy. One case can roll up many alerts, and many cases can roll up into one incident or ring. A clean data model for alert → case → incident saves years of reporting pain.

Entity-linked cases

Each case links to the resolved person, accounts, devices, payment instruments, payout destinations and counterparties. Opening a case should show every other open or closed case touching those entities. That's where ring detection often starts in practice (Graph Analytics).

Structured outcomes

Required fields on closure include:

  • Disposition (confirmed fraud, not fraud, inconclusive, customer error)
  • Fraud type from your taxonomy (Loss Taxonomy and Attribution)
  • Actor type (third-party, first-party, insider, scam victim)
  • Dollar amounts: attempted, prevented, lost, recovered
  • Actions taken
  • Regulatory filings (SAR filed or not, with no SAR content in fraud-wide views)

Free text supplements structured fields and never replaces them.

Evidence standards

Attach artifacts (screenshots, documents, images, logs, call recordings, graph exports) with provenance and timestamps. Make evidence immutable after closure. These standards support representment, law enforcement referrals, litigation and SARs (Case Documentation Standards).

Access and confidentiality

SAR-related information must be restricted. Fraud teams may need to see that a case was escalated to the BSA team without seeing whether a SAR was filed. Insider-fraud cases need restricted visibility, because the subject may be a colleague (Insider Access Controls). Use role-based access and log every view.

Deadlines

Encode regulatory and policy clocks as case attributes with alerts: SAR filing windows, Reg E investigation deadlines, Rule 2165 hold periods and notification deadlines, chargeback representment deadlines.

Integration with decision systems

Analysts should act from the CMS (hold, release, restrict, contact, add to list) with actions logged back automatically. Re-keying between systems causes errors and lost audit trail.

Downstream contributions

Case closure should be able to trigger downstream contributions: deny-list entries, consortium submissions, 314(b) requests, law enforcement referrals (Negative Lists and Deny Lists, Consortium and Data Sharing).

Diagram: Rules and model alerts, Alert, Customer and support reports, Partner, consortium, law enforcement, Case: entity-linked, Evidence and actions, Incident or ring grouping, Structured outcome, Labels, SAR and regulatory workflows, Lists and consortium contributions, QA sampling

Implementation path

StageWhat it looks likePrerequisites
CrawlTicketing tool or spreadsheet with a standard template; manual deadline tracking; outcomes as categorical fieldsA case taxonomy; a named owner
WalkDedicated CMS (built or bought); alert/case/incident model; entity linking; structured outcomes; deadline alerts; role-based access; evidence attachmentsEntity resolution; integration with decision systems; Fraud QA Program
RunRelated cases and graph shown on open; one-click actions with audit; automated label export; SAR workflow integration with confidentiality controls; analytics on handling time, outcome and quality; consortium and list contribution from closureGraph Analytics; Fraud Data Architecture; BSA-AML and SAR Filing workflows

Customer friction and trade-offs

A CMS adds no direct customer friction. Indirectly, a good one shortens time-to-decision for held customers and lets support see case status without exposing sensitive details. A poor one makes customers repeat themselves across contacts. Give support a limited, safe view of case status.

Measuring effectiveness

  • Structured outcome completeness: share of closed cases with all required fields.
  • Time to close by case type, and deadline adherence (SAR, Reg E, Rule 2165, representment).
  • Linked-case discovery: share of cases where related cases were found automatically.
  • QA error rate on case documentation.
  • Label latency: time from case closure to label availability for models.
  • Audit findings related to case records.

Common failure modes

  • Free-text outcomes that can't be reported or used as labels.
  • Transaction-centric cases with no entity links, so rings stay invisible.
  • SAR information visible to everyone with fraud access.
  • Deadlines tracked in people's heads.
  • Actions taken in other systems with no record in the case.
  • Insider cases visible to the subject's team.
  • Several case tools across teams (fraud, AML, disputes, support) with no shared entity view.

Regulatory and policy notes

  • SAR confidentiality: SARs and information revealing their existence are confidential. Supporting documentation must be retained for five years from filing. The CMS must enforce both (BSA-AML and SAR Filing).
  • SAR timing: the 30-day filing clock (60 if no suspect is identified) starts when review determines activity is suspicious. Continuing activity reviews follow a 90-day cycle with filing within 120 days of the prior SAR.
  • FINRA Rule 2165 requires records of the hold, the basis, who authorized it, notifications, the internal review, and reasons for any extension. FINRA exams have found firms that didn't retain records of the internal review behind holds (Trusted Contact and Senior Investor Holds).
  • Reg E error investigations need documented findings and timelines (Regulation E and Unauthorized Transfers).
  • Data retention and privacy: align case retention with legal holds, regulatory minimums and privacy limits (Privacy and Data Use in Fraud Prevention).

Mechanisms addressed

Fraud Rings and Collusion · Money Mules · Account Takeover (ATO) · Elder Financial Exploitation · Authorized Push Payment (APP) Scams · Insider Fraud · ACATS Transfer Fraud · Synthetic Identity Fraud · Seller Non-Delivery and Fake Listings

Manual Review Queues · Graph Analytics · Negative Lists and Deny Lists · Consortium and Data Sharing · Insider Access Controls · Trusted Contact and Senior Investor Holds · Controls Index

Sources and further reading