AML Case Management Buyer’s Guide

An investigator should be able to answer four questions from the case record: what happened, what evidence was reviewed, why the decision was made, and who approved it. If the answers live across screenshots, inboxes, spreadsheets, and undocumented judgment, a new case platform has a precise job to do.

Case management organizes work after a detection, referral, screening alert, or risk event. It can support triage, investigation, escalation, quality assurance, reporting decisions, remediation, and feedback. It does not itself detect every risk or determine whether a report is legally required. Buyers should resist treating workflow coverage as detection coverage.

Decision context

Map every intake route and decision path before reviewing products. Include transaction-monitoring alerts, screening alerts, customer-risk events, employee referrals, fraud cases, law-enforcement requests, quality findings, and external notifications where applicable. For each route, identify the owner, priority, required evidence, service expectation, decision authority, escalation, downstream action, and closure condition.

Define the failure to solve. It may be fragmented evidence, inconsistent decisions, poor queue visibility, repeated manual data collection, weak access control, delayed reporting, inability to link related activity, or no dependable feedback to detection and customer risk. Quantify current volumes, aging, handoffs, rework, quality findings, and missing evidence. Do not promise productivity gains before measuring what investigators actually do.

The FCA’s money-laundering guidance asks how unusual activity is reviewed, how firms decide whether behavior is suspicious, and how monitoring findings feed back into customer risk. The Wolfsberg monitoring statement points to case management, external data, oversight, and exploratory analytics as areas for improvement. These are useful design prompts, not a prescribed workflow.

Requirements checklist

Intake and linkage

Accept alerts and referrals with stable identifiers, source timestamps, source versions, and required evidence.
Prevent silent loss, duplicate creation, or double processing.
Link customers, accounts, parties, transactions, alerts, prior cases, and related events while preserving original records.
Show lineage back to the originating control.
Support controlled merging, splitting, reopening, and reassignment.

Investigation workflow

Configure stages, tasks, checklists, approvals, service targets, and escalation by case type and risk.
Distinguish system decisions, investigator decisions, quality review, and management approval.
Capture structured disposition reasons and free-text rationale without forcing a misleading code.
Request and track information with due dates and evidence attachments.
Support conflicts, recusals, absence coverage, and segregation of duties.

Evidence and audit

Record every material view, change, assignment, decision, override, export, and approval with actor and time.
Preserve the data and policy or configuration context used at decision time.
Provide immutable history and readable evidence exports.
Version templates, workflows, reason codes, and access rules.
Apply retention, legal hold, redaction, and deletion controls according to applicable requirements.

Management and feedback

Report intake, inventory, aging, dispositions, rework, quality findings, reporting outcomes, and bottlenecks using defined denominators.
Allow drill-down without exposing restricted cases to unauthorized users.
Route findings to customer-risk review, control tuning, data remediation, training, or policy change.
Track whether agreed remediation happened.
Distinguish operational throughput from investigation quality.

Security and resilience

Apply least-privilege roles, strong authentication through the institution’s identity service, and monitored administrative access.
Protect sensitive narrative, identity, transaction, and law-enforcement information.
Reconcile inbound and outbound integrations.
Define backup, recovery, outage operation, and restoration procedures.
Provide testable export and exit capabilities.

Evidence to request

Request workflow models, permission matrices, audit-event dictionaries, data schemas, API specifications, retention controls, sample evidence packages, reporting definitions, service and recovery evidence, release history, and customer responsibility matrices. Ask the provider to show one case from source alert through closure, including a correction, reassignment, escalation, approval, export, and later audit.

For automated prioritization or summarization, request intended use, input data, performance and validation evidence, known limitations, override behavior, monitoring, and preserved source references. Generated text should not replace investigator judgment or conceal the evidence behind a decision.

FinCEN’s culture-of-compliance advisory stresses adequate resources, information sharing, leadership, and independent testing. FINRA’s AML overview identifies detection and reporting, risk-based customer identification, and independent testing as core program elements for member firms. A case platform should support the institution’s program and evidence; its existence does not satisfy those responsibilities.

Proof-of-concept test plan

Create scenarios from real operating patterns with masked or synthetic data. Include a simple alert, a multi-customer network, a repeated alert, an urgent referral, an incomplete intake, a data correction, a potential conflict, an information request, a quality rejection, a reopened case, and a case that requires no external report.

Run the proof of concept through seven stages:

Intake reconciliation. Submit normal, duplicate, late, malformed, and retried messages. Confirm counts and error handling.
Investigation. Have actual users collect evidence, link records, document reasoning, and reach a decision without supplier assistance.
Governance. Reassign work, enforce segregation, escalate an overdue case, reject it in quality review, and approve the corrected record.
Evidence. Reconstruct what the investigator saw and export a complete, readable package.
Feedback. Send an outcome to customer risk or detection, then prove receipt and action.
Change. Modify a workflow or reason code through approval, deployment, effective dating, and rollback.
Outage and recovery. Interrupt an integration, operate under the documented fallback, restore service, and reconcile cases.

Measure intake completeness, duplicate handling, investigator task time, navigation effort, handoffs, rework, queue effects, evidence completeness, access-control results, export quality, and recovery. Sample decision quality separately through qualified review. Faster closure is not beneficial if evidence or judgment deteriorates.

Commercial and implementation questions

Clarify licensing for investigators, occasional users, approvers, auditors, administrators, environments, storage, API volume, reporting, analytics, and document processing. Model retained evidence, peak users, growth, implementation, integration maintenance, upgrades, and exit. Ask what professional services are required for workflow changes after launch.

Migration can dominate the project. Ask:

Which open and closed cases must move, and at what level of detail?
Will historical records remain searchable and legally usable?
How are identifiers, attachments, audit history, reason codes, and user references mapped?
Who reconciles migrated counts and evidence?
How are active service clocks and assignments preserved?
What read-only access remains to the old system?
How will changes during the migration window be controlled?
When can the legacy platform be retired safely?

Assign ownership for workflow design, access, data, integrations, reporting definitions, quality assurance, training, migration, validation, and operational readiness. Include an exit schedule and usable data format in the contract.

Red flags

Pause when the demonstration uses only a straight-line case. Other warnings include editable audit history, broad administrator access, no reconciliation of intake, metrics with hidden exclusions, screenshots as the main evidence export, unclear time-zone handling, and a reporting module that cannot trace a number to cases.

Be cautious when automated summaries omit source citations, bulk actions bypass reasons, or related-case views merge data without preserving provenance. A graph can help an investigator explore connections; it is not evidence by itself.

Procurement implications and limitations

Score investigation fit, evidence, governance, data and integration, reporting, security, resilience, migration, implementation, usability, and cost. Give investigators meaningful test time. Require compliance approval of decision paths, privacy and security approval of data handling, technology approval of integrations, and audit access to evidence.

Proof-of-concept users learn quickly, which can make later tests look faster. Synthetic cases cannot reproduce all legal restrictions or investigative ambiguity. Migration samples can miss damaged legacy records. The final decision should record these limits, the remaining manual controls, migration reconciliation, training and staffing needs, validation work, and the measures that will trigger post-launch correction.