Purpose
Turn unstructured fraud case notes, transaction summaries, and investigation logs into a ranked set of concrete fraud signals — each mapped to a specific alert-logic change and decisioning-criteria update — so risk operations can move from anecdote to deployable detection quickly. Solves the gap between what investigators observe and what the rules engine actually enforces.
When to Use
Invoke this skill when the user asks to:
- Extract patterns from a batch of recent fraud cases or chargeback investigations
- Diagnose a spike in a specific fraud type (ATO, first-party, synthetic identity, promo abuse, card testing)
- Translate investigator narrative notes into detection rules or alert logic
- Review transaction data summaries for shared attributes across confirmed-fraud cases
- Prepare a fraud trend brief or emerging-threat summary for a risk review
- Identify which existing rules are missing a newly observed fraud behavior
Inputs Required
Before starting, collect:
- Source material: Case notes, transaction data summaries, investigation logs, or chargeback records (paste or describe)
- Fraud context: What triggered this review — a spike, a scheduled review, a specific loss event
- Case outcomes: Which cases are confirmed fraud vs. suspected vs. false positive (if labeled)
- Current detection setup: Existing rules, alert types, or decisioning model in place (high level is fine)
- Product/channel affected: Onboarding, payments, withdrawals, card, transfers, etc.
- Risk tolerance: Priority between minimizing losses vs. minimizing false-positive friction
If case outcomes are unlabeled, treat all cases as suspected and flag confidence accordingly. If the current detection setup is unknown, generate rule suggestions as net-new logic.
Instructions
Step 1: Normalize and Cluster the Source Material
Read all provided material and extract discrete observations. For each case or record, capture:
- Fraud type (ATO, synthetic identity, first-party/friendly fraud, card testing, promo/bonus abuse, mule activity, account farming)
- Entry surface (onboarding, login, payment, withdrawal, profile change)
- Observed attributes (device, IP/geo, velocity, amount patterns, timing, funding source, behavioral tells)
- Outcome label if provided
Cluster observations by shared attributes — group cases that plausibly stem from the same actor, tactic, or vulnerability. Note cluster size (number of cases supporting each grouping).
Step 2: Extract Signals from Each Cluster
For every meaningful cluster, define a signal — a specific, observable, machine-detectable condition. Each signal must include:
- Signal name: Short descriptive label
- Definition: The precise observable condition (e.g., "3+ distinct cards attempted on one account within 10 minutes, all sub-$2 authorizations")
- Supporting evidence: How many cases exhibit it and the shared attributes
- Fraud type: Which category it maps to
- Confidence: High / Medium / Low, based on case count, outcome labels, and specificity
- False-positive risk: What legitimate behavior could also trigger this
Prioritize signals that are specific and observable over broad behavioral hunches. A signal a rules engine cannot evaluate is not a signal.
Step 3: Rank Signals by Operational Priority
Score each signal on two axes and rank:
- Loss exposure: Estimated frequency × average case value (use provided data; estimate conservatively if absent)
- Deployability: Can it be turned into a rule now, or does it need new data/tooling?
Rank highest-exposure, most-deployable signals first. Flag any signal that is high-exposure but not yet deployable as a data gap requiring instrumentation.
Step 4: Map Each Signal to a Detection Response
For each ranked signal, specify:
- Alert logic change: The concrete rule condition to add or modify, in near-pseudocode (e.g., "IF card_attempts >= 3 AND window <= 600s AND avg_auth < $2 THEN flag=card_testing, action=step_up")
- Decisioning criteria update: How this affects the decision — hard decline, step-up auth, manual review queue, velocity limit, hold
- Threshold rationale: Why this cutoff — tied to the observed case data, not arbitrary
- Recommended action tier: Block / Challenge / Review / Monitor — calibrated to the stated risk tolerance
- Tuning note: What to watch after deployment (expected false-positive impact, review-queue volume)
Step 5: Summarize the Emerging Threat Picture
Write a short synthesis: which fraud type is trending, which surface is most exposed, whether the pattern suggests a single organized actor or diffuse opportunistic activity, and the single highest-priority action. Be direct about what the data does and does not support.
Output Format
- Structure: Threat summary up top → ranked signal table → per-signal detection response blocks → data gaps → recommended next action
- Length: 800–1,200 words
- Format: Structured document — signal ranking as a table; detection responses as labeled blocks with pseudocode
- Sections: Emerging Threat Summary → Extracted Signals (ranked table with confidence + exposure) → Detection Responses (per signal: alert logic + decisioning update + action tier + tuning note) → Data Gaps → Priority Action
- Tone: Fraud operations specialist — precise, evidence-bound, no speculation presented as fact; explicitly separates confirmed patterns from hypotheses
Quality Checklist
Before delivering output, verify:
- [ ] Every signal cites a case count or specific supporting attributes — no unsupported assertions
- [ ] Each signal has a confidence rating tied to evidence strength, not sentiment
- [ ] Every signal maps to a concrete alert-logic change written as an evaluable condition (pseudocode present)
- [ ] Each detection response names a decisioning tier (Block / Challenge / Review / Monitor) calibrated to stated risk tolerance
- [ ] Signals are ranked by loss exposure × deployability — not listed arbitrarily
- [ ] False-positive risk is named for every signal that triggers customer-facing friction
- [ ] Any high-exposure but non-deployable pattern is flagged as a data gap, not buried as a rule
Notes
- The most common failure mode is over-fitting a rule to a handful of cases — flag any signal supported by fewer than 3 cases as Low confidence and recommend Monitor rather than Block.
- Card testing and ATO signals are usually deployable immediately; synthetic-identity and first-party fraud signals often need new upstream data and belong in the data-gap section.
- When risk tolerance favors low friction, default new signals to Challenge or Review tiers before recommending hard Block — a false decline on a legitimate customer is a real cost.
- Threshold values should always trace back to the observed data (e.g., "cases clustered at 3–5 attempts, so set at 3") rather than round numbers chosen for convenience.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills