Fraud Incident Response

How to run a fraud attack war room: declaration criteria, severity levels, roles, the first-hour checklist, containment levers, communications, regulatory clocks and blameless post-mortems.

Core components

When to declare a fraud incident

Declare when any of these is true. Keep the threshold low, because downgrading is cheap.

Fraud loss or exposure is accumulating faster than normal controls are absorbing it
A new or unexplained pattern is hitting a money path at volume
A logic flaw, promo misconfiguration or pricing error is being exploited, or is being discussed publicly
A credential-stuffing or bot wave is hitting login, sign-up or payment endpoints (see Credential Stuffing, Card Testing)
A coordinated ATO wave, SIM-swap cluster or recovery-abuse spike (see Account Takeover (ATO))
An insider or vendor-staff compromise is suspected (see Insider Fraud)
A partner (network, bank, processor, retailer) notifies you of an attack or compromise
Controls are failing: a rules engine outage, a scoring timeout defaulting to approve, a vendor signal outage

Severity levels (illustrative, calibrate to your scale)

Level	Criteria	Examples	Response
SEV-1: Critical	Uncontained loss well beyond normal daily loss; or customer funds at broad risk; or public/viral exploitation; or regulatory, partner or press exposure likely	Viral promo or funding logic exploit; mass ATO with withdrawals; decisioning outage defaulting to approve	War room within 15–30 min; exec notified; 24/7 until contained; updates every 1–2 hours
SEV-2: High	Significant loss or exposure, contained or containable within hours; limited segment	Ring cashing out referral rewards; card testing on a funding endpoint; ATO cluster at one payout method	Incident commander assigned within 1 hour; business-hours plus on-call; updates every 4 hours
SEV-3: Moderate	Elevated, localized activity; normal controls mostly working	A new receipt manipulation pattern at one retailer; elevated mule inbound	Owned by strategy on-call; daily updates
SEV-4: Low / watch	Anomaly under investigation; no confirmed loss	Unexplained sentinel spike	Logged; reviewed at the next strategy stand-up

Severity should reflect exposure, meaning what could leave if nothing changes. Confirmed loss lags badly during an attack.

How to build it

Roles

Role	Responsibilities	Typical holder
Incident commander (IC)	Owns the incident; sets priorities; makes containment calls within delegated authority; declares severity changes and closure. Does not do hands-on analysis.	Senior fraud strategist or fraud manager on the IC rotation
Fraud analysis lead	Sizes the attack, finds the signature, proposes containment logic, monitors effect	Strategy analyst / data scientist
Ops lead	Queue surges, manual actions (holds, freezes), analyst briefings, SOP deviations	Fraud ops manager
Engineering lead	Deploys blocks, kill switches and config changes; investigates logic bugs; preserves logs	On-call engineer from the owning product, plus a risk engineer
Communications lead	Internal updates; coordinates customer messaging, support macros, and external or press statements with comms and legal	Fraud program manager plus corporate comms
Support liaison	Briefs support; collects customer contacts; adjusts verification during the incident	Support operations lead
Compliance / legal liaison	Regulatory clocks, SAR considerations, Reg E obligations, law enforcement contact, partner notifications, evidence preservation	Compliance / BSA, legal counsel
Scribe	Timeline, decisions, actions, owners. The source for the post-mortem.	Anyone not otherwise assigned
Exec sponsor (SEV-1)	Air cover, cross-org resourcing, risk acceptance for drastic actions (e.g., pausing a product)	Head of fraud or business GM

Lifecycle

Diagram: Detect, Declare + assign IC, Triage: size, scope, severity, Contain: stop the bleeding, Eradicate: close the hole, Recover: claw back, restore, remediate customers, Post-mortem + actions, Improve controls, playbooks, launch criteria

First-hour checklist (SEV-1/2)

Declare. Open the incident channel and doc; name the IC and scribe; set the initial severity
Scope. Which money path, rail, product, segment and time window? What is exposure right now?
Signature. What do the bad transactions or accounts have in common? (Keep it simple for the first cut.)
Contain. Apply the smallest effective lever from the menu below. Prefer reversible actions.
Protect money-out first. If you can only do one thing, slow or stop the exit path: withdrawals, payouts, redemptions, transfers.
Preserve evidence. Snapshot logs, configs and affected-account lists before they rotate or get changed
Brief support. Holding macro; what to say; what not to do (e.g., don't manually release holds)
Notify. Exec sponsor (SEV-1), compliance/legal liaison, affected product owner
Set the update cadence and post the first status update

Build these levers before you need them, so that during an incident you're only choosing among them.

Lever	Scope options	Reversibility	Customer impact
Kill switch on a promo, offer or feature	Global, by segment, by offer ID	High	High for the affected feature
Payout / withdrawal holds	New destinations, new accounts, by rail, above an amount	High	Moderate; funds delayed
Lower velocity and exposure limits	By tenure, segment or rail (see Velocity and Exposure Limits)	High	Low to moderate
Forced step-up	On login, account change, or transaction (see Risk-Based Authentication and Step-Up)	High	Low to moderate
Emergency rules	Narrow attack signature; time-boxed (see Fraud Strategy Lifecycle)	High	Varies
Rate limiting / bot challenges	Endpoint-level (see Rate Limiting and Throttling, Bot Management and CAPTCHA)	High	Low for most users
Funds availability changes	Extend holds on new deposits (see Funds Availability Holds)	High	Moderate
Deny-list entries	Devices, instruments, payees, identifiers (see Negative Lists and Deny Lists)	Medium	Low if precise
Account restrictions	Freeze money movement on implicated accounts	Medium	High for those accounts
Product pause	Disable sign-up, funding method or payout method	High, but costly	Very high

Communications

Audience	When	Content	Owner
Incident channel	Continuous	Facts, decisions, actions	Scribe / IC
Stakeholder update	Per severity cadence	Status, exposure, containment, next steps, asks	IC / comms lead
Executives	SEV-1 at declaration, then per cadence	Business impact, risk decisions needed	Exec sponsor
Support	At declaration, and whenever guidance changes	Macros, verification changes, escalation path	Support liaison
Affected customers	After containment, coordinated with legal	What happened, what we're doing, what they should do	Comms lead + legal
Partners (networks, banks, retailers)	Per contract and network rules	Facts relevant to them	Compliance/legal liaison
Regulators / law enforcement	Per obligation	Via compliance/legal	Compliance/legal liaison

Status update template: Severity · start time · current state (investigating / contained / monitoring / resolved) · what we know · exposure estimate and confidence · actions taken · next actions and owners · asks · next update time.

Regulatory and contractual clocks to check

The compliance/legal liaison owns these. Fraud teams should know they exist:

SAR filing: for banks, generally within 30 calendar days of initial detection of facts that may warrant a SAR, extendable to 60 days if no suspect is identified. Urgent situations need immediate law-enforcement notification by phone. See BSA-AML and SAR Filing.
Reg E error resolution: consumer claims of unauthorized EFTs start investigation clocks: generally 10 business days, or up to 45 calendar days if provisional credit is given (90 days in specific cases, such as POS debit or new-account transfers). An ATO incident can generate a surge of claims. Staff for it. See Regulation E and Unauthorized Transfers.
Network and Nacha obligations: dispute handling, monitoring program thresholds, return rate thresholds. See Card Network Dispute Rules, Nacha Rules and ACH Risk.
Data breach notification: if the incident involves compromised customer data, state breach laws and sector rules may apply. Coordinate with security and legal.
Broker-dealer obligations: where relevant, such as trusted contact and senior investor holds. See Broker-Dealer Obligations (FINRA and SEC).
Partner contracts: BaaS sponsor banks, processors and retail partners often have contractual notification windows.

Recovery

Clawback and reversal: reverse rewards, cancel unsettled payouts, recall payments where rails allow (see Reward Vesting and Clawback)
Account remediation: restore ATO victims' accounts and funds; reset credentials; review linked changes
Good-customer cleanup: lift blanket holds and restrictions that caught legitimate customers; apologize; consider goodwill
Mule and ring follow-up: hand off to investigations (see Playbook - Fraud Ring Investigation Members, Playbook - Money Mule Detection Members)
Emergency rule backfill: run emergency rules through the normal lifecycle or let them expire

Artifacts and templates

Incident doc outline

Header: ID, severity, IC, start time, status
Summary (kept current)
Timeline (scribe)
Scope and exposure: money path, rail, segment, accounts, dollars at risk and lost
Attack signature (conceptual; detailed indicators in the restricted appendix)
Containment actions: what, when, who, reversibility, expiry
Customer impact, good and bad
Communications log
Regulatory/legal considerations (restricted)
Open questions and next steps

Post-mortem template (blameless)

Summary. What happened in 3–5 sentences
Impact. Gross loss, recoveries, net loss, customers affected, friction imposed, ops hours
Timeline. Key timestamps: first bad event, first signal, detection, declaration, containment, resolution
Detection analysis. When could we have known? Which signals were present but unalerted?
Root causes. Contributing factors across product design, controls, data, process and people. Use "how did the system allow this" framing, not "who made the mistake."
What went well
What went poorly
Action items. Each with owner, due date and type: prevent / detect / respond / launch criteria / training
Lessons for other money paths. Where else could this happen?

Readiness checklist

IC rotation staffed 24/7 with documented authority
Containment levers exist, are tested, and are documented with how to use them
Kill switches exist for every live promo and every money-out path
Real-time loss and exposure dashboards per money path
Alerting on sentinel metrics, routed to on-call
Support holding macros pre-drafted for common incident types
Contact list: engineering on-call per product, comms, legal, compliance, partner contacts
Tabletop exercise in the last 6 months (see below)
Post-mortem actions tracked to closure

Tabletop scenarios (pick one per quarter)

A promo misconfiguration goes viral on a Friday evening
Credential-stuffing success leads to payout-destination changes and instant withdrawals
The scoring service times out and the fallback is "approve"
An outsourced support agent is found processing fraudulent contact changes
A partner bank notifies you of an unusual ACH return spike on accounts you funded
A deepfake voice call to support results in account recovery and a large transfer

Metrics

Metric	Definition
Time to detect (TTD)	First bad event to first alert
Time to declare	First alert to incident declared
Time to contain (TTC)	Declaration to loss rate back to baseline
Loss during incident	Gross, recovered and net
Exposure avoided	Estimated loss had containment not been applied (state assumptions)
Good-customer impact	Customers held, declined or restricted who weren't bad
Post-mortem action closure	Share of actions closed by due date
Repeat incidents	Same root cause within 12 months

Pitfalls

Declaring late. Waiting for confirmed losses means waiting for labels that lag the attack.
The IC doing analysis. The IC coordinates. If they're writing SQL, nobody is making decisions.
Building levers mid-incident. Every lever that needs a code deploy costs hours.
Over-containment that lingers. Blanket holds that stay on for weeks after the incident can cost more than the attack did.
Forgetting support. Fraudsters often pivot to social engineering support when automated paths close (see Support Team Fraud Training).
No post-mortem for "small" incidents. SEV-3s are cheap lessons. Run a lightweight review.
Blame. Post-mortems that name individuals teach people to hide early signals.

Fraud Program Overview · Fraud Operating Model · Threat Intelligence and Horizon Scanning · Cross-Functional Partnerships
Playbooks: Playbook - Business Logic Exploit Response Members · Playbook - Credential Stuffing Response Members · Playbook - Novel Attack Detection Members · Playbook - Payout and Withdrawal Risk Members
Governance and records: Rule Governance and Change Management (emergency rule expiry) · Case Documentation Standards · Withdrawal and Payout Controls
Pre-authorized levers: Kill Switches and Circuit Breakers
Readiness: Fraud Tabletop Exercises · Workforce Management and Capacity Planning (surge levels)
Case studies: Case Study - Chase Infinite Money Glitch (2024) · Case Study - Pinduoduo Coupon Exploit (2019) · Case Study - DraftKings Credential Stuffing (2022)

Sources and further reading

eCFR, 31 CFR 1020.320 Reports by banks of suspicious transactions: SAR timing (30/60 days), immediate law-enforcement notification for urgent situations, 5-year retention
CFPB, Regulation E §1005.11 Procedures for resolving errors: investigation and provisional-credit timelines triggered by unauthorized-transfer claims
CFPB, Regulation E §1005.6 Liability of consumer for unauthorized transfers: consumer liability tiers relevant to ATO incident remediation
Nacha, Fraud Monitoring Phase 1: risk-based monitoring and handling of flagged entries for ACH participants
COSO/ACFE Fraud Risk Management Guide, 2nd ed., Executive Summary (2023): investigation and corrective action as a core fraud risk management principle