Fraud Operations and Case Management Guide: Queues, Investigations, Reporting and QA

Most fraud losses that reach the press were flagged somewhere first, then sat in a queue, got closed without evidence, or never reached the person who could act on them. Fraud operations is the human layer between detection and outcome: the review queues, investigations, customer contact, regulatory reports and quality checks that turn an alert into a decision that holds up later. This guide covers how to design queues and triage, run the case lifecycle, collect evidence, contact customers safely, meet the regulatory clocks for disputes, scam reimbursement and suspicious activity reports, and assure quality. It is written for fraud operations managers, investigators, team leads and the product and security teams that build case tooling. Detection logic is covered in the Fraud Rules and Machine Learning Models Guide and money laundering programme design in AML programme and transaction monitoring; this page is about running the work.

Key takeaways

• Design queues around time to harm: a payment that can still be stopped outranks a closed account takeover, so queue priority must follow how fast the money moves, not alert score alone.
• The case file is the product: a decision without recorded evidence and reasoning cannot be defended to a customer, an ombudsman, a regulator or a court.
• Regulatory clocks start earlier than teams think: Regulation E gives 10 business days to investigate or provisionally credit, a US bank SAR is due 30 calendar days after a review finds activity suspicious, and UK scam victims are mostly reimbursed within five business days.
• Customer contact is an attack surface: fraudsters impersonate fraud teams, so outbound contact needs a verifiable pattern and inbound callers need step-up verification.
• Quality assurance closes the loop: sampled second review, calibration and feedback into rules are what stop the same miss from recurring.

What fraud operations covers

Fraud operations sits between detection (rules, models, consortium data, customer reports) and outcomes (blocked payments, recovered funds, closed accounts, reports to authorities). It typically owns five functions.

Fraud and AML teams overlap heavily. The FFIEC BSA/AML examination manual expects departments researching related activity, such as BSA and fraud, to keep communication lines open. Many firms run a shared case platform with separate queues and permissions; see Fraud and Cyber Convergence Guide.

Queue design and alert triage

Queue structure

• Separate by response window: real-time holds, same-day alerts and investigation backlogs need different staffing models. Mixing them lets slow work starve urgent work.
• Separate by skill: account takeover, first-party fraud, scams, merchant fraud and internal fraud need different evidence and different questions. See the First-Party Fraud Guide and Authorised Push Payment (APP) Fraud Guide.
• Prioritise by recoverability then value: funds still in the institution or in a receiving account that can be frozen come first, then exposure, then model score.
• Link before you work: group alerts by customer, device, payee and beneficiary account so one analyst sees the whole pattern instead of five analysts closing fragments.

A triage standard that holds up

1. Confirm the alert facts: transaction, channel, device, session and the rule or model that fired.
2. Check customer context: tenure, KYC risk rating, recent changes (address, phone, email, device, payee), prior cases.
3. Check linked entities: other customers sharing the device, IP range, beneficiary or contact details. See Money Mule Detection Guide.
4. Decide: close with a reason code, contact the customer, or escalate to a case.
5. Record the reason in structured form (reason code) and in free text (one or two sentences a reviewer can follow).

The FFIEC manual makes a point that matters for clocks: for SAR purposes, initial detection does not occur when a system merely flags a transaction; it occurs when an appropriate review determines the activity is suspicious. Triage must therefore be timely, because a backlog of unreviewed alerts is itself an examination finding.

The case lifecycle

Case record fields that matter: case type and fraud taxonomy, linked entities, timeline of events, every action with actor and timestamp, evidence items with source, customer contacts, decision and approver, reporting decision with reasons, financial impact (gross, recovered, net), and closure reason. Our Security Case Management Guide covers platform-level design; fraud cases add money movement, liability and regulated outcome fields.

Investigation and evidence

• Collect what the decision needs: transaction records, authentication and session logs (device fingerprint, IP, login method, step-up results), customer communications, call recordings, payee history and receiving institution responses.
• Preserve originals: US bank SAR rules require keeping the original or business-record equivalent of supporting documentation for five years from filing, and that documentation is deemed filed with the SAR. Store exports with hashes and record who retrieved them.
• Do not try to prove the crime: the FFIEC manual is explicit that banks are not required to investigate or confirm the underlying crime; that is law enforcement's job. Investigate enough to make the business and reporting decision.
• Handle legal process carefully: a grand jury subpoena should prompt a review of the customer's activity but should not be mentioned in any resulting SAR.
• Share within the law: use formal routes for information requests between institutions; see the Fraud Data Sharing and Consortium Intelligence Guide.

Customer contact and outreach

Contact is where fraud operations meets fraudsters most directly: impersonation of bank fraud teams is a standard scam script, and inbound callers claiming to be victims may be the attackers.

• Outbound pattern: publish what your fraud team will and will not do (never ask for one-time codes, PINs or a transfer to a "safe account") and keep every script consistent with it.
• Verify through the customer's own channel: prefer in-app messages or push confirmations; for calls, invite the customer to hang up and call the number on their card.
• Inbound step-up: verify callers with a factor bound to the device or account, not knowledge-based answers the fraudster may hold. See the Help Desk Identity Verification Policy Template and SIM Swap Fraud Guide.
• Scam victims: coaching by the fraudster is common, so ask open questions about how the payee was introduced and who suggested the payment. Record answers verbatim.
• No tipping off: customer messages must never reveal that a suspicious activity report exists or is being considered. US SAR confidentiality and UK tipping-off offences (POCA sections 333A and 342) both apply.

Regulatory clocks: disputes, reimbursement and suspicious activity reports

Build these as due dates on the case record that start automatically from the right event (claim received, review concluded suspicious), with escalation before breach. For UK reimbursement detail see the Authorised Push Payment (APP) Fraud Guide.

Writing the report

• Narrative first: the FFIEC manual says a narrative cannot just say "see attachment"; describe who, what, when, where, why it is suspicious and how the activity was carried out.
• Use advisory terms: include key terms from relevant FinCEN advisories and tick the matching boxes so the report can be found.
• Document no-file decisions: record the specific reasons for filing or not filing; examiners test the process rather than second-guess single judgments.
• Corrections: FinCEN asks filers to note corrections at the start of the narrative of an amended SAR.
• Board reporting: notify the board or a committee that SARs were filed, in a form that preserves confidentiality.

Quality assurance and calibration

• Risk-based sampling: sample more from closures with high value, new analysts, new fraud types and "no further action" outcomes; sample fewer from mature, low-value work.
• Score against a rubric: evidence sufficient, reason code correct, customer outcome correct, regulatory clock met, report decision justified, record readable by a stranger.
• Calibrate: have several analysts work the same cases monthly and discuss differences; disagreement shows unclear policy.
• Feed back: every confirmed miss creates a rule, model or process ticket with an owner. See the Fraud Metrics and KPIs Guide.
• Decision maker separation: the FFIEC manual describes findings going to a final decision maker or committee with a defined way to resolve disagreement; keep investigator and approver distinct for reporting and high-value refunds.

Team structure, tooling and the identities behind it

Case tools hold some of the most sensitive data a firm has, and fraud analysts hold powerful actions (refunds, account unlocks, contact detail changes). Insiders and compromised analyst accounts are a real risk.

• Least privilege and separation: analysts cannot approve their own refunds or change contact details on accounts they investigate.
• Phishing-resistant MFA for analysts: case and back-office tools are targets for social engineering of staff.
• Machine identities: the service accounts and API keys that pull data from core banking, card processors and consortium feeds, or that let automation and AI assistants draft narratives, should be scoped per integration, vaulted and rotated. An AI assistant may draft; a named human decides and files.
• Tamper-evident audit: log every view, export and action on a case and protect the log from editing.

Detection and measurement

• Time to first touch by queue against target (minutes for real-time holds, hours for daily alerts).
• Regulatory clock compliance: percentage of Regulation E claims, reimbursement claims and SARs completed inside the deadline.
• Alert to case conversion and case to confirmed fraud rate, by rule, to show where analysts waste time.
• QA pass rate and the share of QA failures by category.
• Recovery rate: funds recovered as a percentage of funds lost on confirmed cases.
• Backlog age: number of alerts unreviewed beyond target, a leading indicator of examination risk.

How to implement

1. Map the work: list every alert source, claim channel and external request, the queue it lands in and the regulatory clock it carries.
2. Define the taxonomy and reason codes: agree fraud types and closure reasons before building reports.
3. Build the case record and due dates: configure the lifecycle states, mandatory fields and automatic clocks.
4. Pilot on one queue: run a single queue on the new process for four to six weeks with daily review; keep the old process available as a fallback until clocks and QA results are stable.
5. Add QA and calibration: start sampling from day one, then tune sample rates.
6. Connect feedback: route confirmed misses and false positive patterns to rule owners with service levels.
7. Review access: recertify analyst and service account permissions quarterly.

Small versus large teams: a team of five can run one queue with a spreadsheet of clocks and a weekly QA sample, as long as evidence and reasons are recorded. Large operations need a case platform with linked entities, automated clocks, workforce management and a separate QA function.

Framework mapping

Common failure patterns

• Score-only queues: high-score but unrecoverable alerts are worked first while a stoppable payment ages out.
• Fragmented investigations: linked alerts worked by different analysts, so a mule network looks like five unrelated low-value events.
• Clocks started late: claims logged when picked up rather than when received, breaching Regulation E or reimbursement deadlines on paper.
• Thin closure notes: "no fraud found" with no evidence, which cannot be defended to an ombudsman or examiner.
• Tipping off through templates: customer letters that say an account is closed "following a suspicious activity review".
• Over-powered analyst accounts: one compromised or corrupt analyst can change contact details and approve refunds; separation of duties is missing.

Practitioner checklist

• Split queues by response window and fraud type, and prioritise by recoverability.
• Link alerts by customer, device and beneficiary before assignment.
• Use a written triage standard with reason codes and short free-text reasons.
• Configure automatic due dates for Regulation E, scam reimbursement and SAR deadlines from the correct trigger event.
• Preserve evidence originals with hashes and keep SAR supporting documents for five years.
• Publish and follow a customer contact pattern that fraudsters cannot imitate easily.
• Check every customer template for tipping-off risk.
• Separate investigator and approver for SAR and high-value refund decisions.
• Run risk-based QA sampling and monthly calibration, with feedback tickets to rule owners.
• Scope and recertify analyst and service account access quarterly.

Standards and references

• eCFR: 31 CFR 1020.320 Reports by banks of suspicious transactions
• eCFR: 12 CFR 1005.11 Procedures for resolving errors (Regulation E)
• FFIEC: BSA/AML Examination Manual, Suspicious Activity Reporting
• FinCEN: Frequently Asked Questions Regarding the FinCEN Suspicious Activity Report
• National Crime Agency: Suspicious Activity Reports
• Payment Systems Regulator: APP scams
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: AML programme and transaction monitoring · Security Case Management Guide · Fraud Metrics and KPIs Guide · Fraud Prevention Guide for Digital Businesses · EU AML Regulation and AMLA Guide