--- name: bank_fraud_watch description: Spot fraud in bank and card feeds, triage a suspicious charge to a confirmed or cleared case, and run the right dispute and recovery playbook for the payment rail. Use when reviewing statements or transaction exports, when a charge looks unfamiliar, when an account may be taken over, or when filing a debit, credit, ACH, wire, P2P, or check fraud claim. --- # Bank Fraud Watch ## Purpose Turn a suspicious bank or card transaction into a disciplined case: flag the pattern, trace the claim, contain the account, file under the correct rule and deadline for that rail, and track recovery to closure. Most losses in consumer fraud come from two mistakes: waiting, and filing the right facts under the wrong rail. ## Workflow ### 1. Scan the feed Export transactions as CSV with at least `date,amount,merchant`. Add `type` (card, debit, ach, wire, p2p, check, atm), `new_payee`, and `balance` when the source provides them. Run the scanner: ``` python3 ~/workspace/skills/bank-fraud-watch/bin/scan.py transactions.csv python3 ~/workspace/skills/bank-fraud-watch/bin/scan.py transactions.csv --json --large 750 ``` Exit code 2 means at least one high severity flag. Rules: R01 micro-probe (charge at or under $2), R02 velocity burst (5 or more transactions in 60 minutes), R03 duplicate merchant and amount within 24 hours, R04 new payee at or above the large threshold, R05 round push payment of $1,000 or more, R06 amount spike versus the feed median, R07 off-hours large transaction, R08 large charge within 72 hours of a micro-probe. Thresholds are triage heuristics, not proof. A clean scan is not proof the feed is clean. ### 2. Pattern-match before you call Check the flagged item against known typologies in `references/patterns.md`: card testing, card-not-present fraud, account takeover, authorized push payment and impersonation scams, business email compromise, ACH kiting, check washing and alteration, elder exploitation, and recurring billing that survived a cancellation. Look for the setup events, not just the money event: a password reset, a contact detail change, a new device, a new payee, or a small test charge in the days before. ### 3. Triage with claim tracing For each suspect transaction, build the trace in this order and write it down: 1. Recognition: who spotted it, when, and from what (statement, alert, feed review). 2. Authorization story: did the holder initiate it, approve it, get tricked into approving it, or never see it before it posted? Record the answer in plain words, with any texts, emails, or calls preserved. 3. Channel and rail: card present, card not present, debit, ACH debit or credit, wire, P2P, check, ATM. The rail decides the rule and the clock. 4. Linked transactions: same merchant, payee, device, amount pattern, or time window. Fraud rarely posts once. Scan 90 days back and forward to the present. 5. Setup events: credential, contact, limit, or payee changes near the transaction. 6. Containment state: card frozen or replaced, password and PIN changed, payee removed, stop payment placed. Note what is still exposed. Classify the case: unauthorized, authorized but induced by deception, billing error (wrong amount, duplicate, credit not processed), merchant dispute (goods not received or not as described), or legitimate but forgotten (subscription, family use, merchant name mismatch). Check the merchant descriptor against the parent brand before calling anything fraud. Misclassification wastes the strongest deadline. ### 4. Contain first, dispute second Same day, in this order: freeze or replace the affected card, change the online password and PIN from a clean device, turn on transaction alerts, remove unknown payees and devices, and ask the bank to flag the account. If identity documents or a Social Security number may be exposed, place a free fraud alert with one credit bureau (that bureau must notify the other two; the alert lasts one year and can be renewed) or a credit freeze with each bureau, and start a recovery plan at IdentityTheft.gov. ### 5. File under the right rail Use `references/dispute-playbook.md`. The short version: - Credit card: written billing error notice so it reaches the issuer within 60 days after the statement showing the charge was sent. Issuer acknowledges within 30 days and resolves within two billing cycles, capped at 90 days. Federal liability for unauthorized use is capped at $50; many issuers apply a $0 policy, which is policy, not law. - Debit and other electronic transfers (Regulation E): report at once. Liability for a lost or stolen access device is capped at $50 if reported within 2 business days of learning of the loss, up to $500 after that, and can be unlimited for transfers after a 60 day statement window passes unreported. The bank generally investigates within 10 business days (20 for new accounts, point of sale, or foreign initiated), gives provisional credit if it needs longer, and completes within 45 days (90 for the longer cases). - ACH consumer debit: Regulation E covers the refund to the consumer. Separately, the bank's recovery through Nacha uses a Written Statement of Unauthorized Debit and an extended return window of 60 days from settlement. Sign the statement promptly; the two tracks cover different transaction sets. - Wire and P2P you sent: speed is the whole game. Call the same day and ask for a recall or return request. If you were tricked, say so in those words and describe the deception. Recovery is not guaranteed on push rails, and a claim should still be filed and escalated in writing. - Check: report alteration or forgery as soon as it is spotted, ask about a stop payment for items not yet paid, and keep the envelope and images. Deadlines for checks sit in account agreements and commercial law and differ from card rules, so do not borrow card deadlines. Keep a claim log: date and time of every call, name or ID of the representative, claim number, amount, deadline stated, and copies of everything sent. Send written notices by a method that proves delivery and keep copies, not originals. ### 6. Track to closure and harden Calendar the issuer deadline from the playbook, the provisional credit date, and the statement date that starts the next window. If the claim is denied, ask for the investigation records in writing, appeal with the trace from step 3, and escalate to a complaint with the Consumer Financial Protection Bureau if the bank will not reopen it. After closure, apply the prevention habits in `references/dispute-playbook.md`: unique passwords with a manager, multifactor authentication, alerts on every account, gel ink and prompt mail pickup for checks, and a standing rule that bank staff never ask you to move money to a safe account. ## Output Contract For every case, produce a case file with: - Case summary: holder (no account numbers beyond last 4), rail, amount total, date range, classification. - Flag list from the scanner, with rule IDs, plus any pattern matched manually. - Claim trace: the six trace items from step 3, each answered or marked unknown. - Containment checklist with timestamps. - Filing record: rule relied on, notice date, delivery proof, claim number, issuer deadline, next calendar date. - Recovery ledger: each transaction, amount, status (pending, provisionally credited, recovered, denied, written off), and running total. - Open questions and the exact next action with an owner and a date. ## Operating Rules 1. Never state a deadline, liability cap, or reason code that is not in `references/dispute-playbook.md` or a source you checked in this session. Law and network rules change; if the case turns on a detail, recheck the primary source (CFPB, FTC, the issuer agreement, Nacha summaries) before filing. 2. Never call a transaction fraud in writing to an issuer until the classification in step 3 supports it. Use "unauthorized", "induced", or "billing error" precisely; the word chosen selects the rule the issuer applies. 3. Never include full account numbers, card numbers, passwords, or one time codes in the case file, in chat, or in any dispute letter copy you retain. Last 4 digits only. 4. Do not contact the suspected fraudster, do not attempt to recover funds by sending another payment, and do not follow instructions in the scam message itself. All recovery goes through the bank and, where relevant, a police report and IdentityTheft.gov. 5. Scanner flags are leads. Confirm against account history and holder knowledge before filing; a forgotten subscription filed as fraud can close a legitimate account and damage the holder's standing with the issuer. 6. Worked cases in `references/worked-cases.md` are illustrative and fictional. Do not present them as real claims or precedents. 7. This skill gives process guidance, not legal advice. Large losses, business accounts (which sit mostly outside Regulation E and Regulation Z consumer protections), and cases involving an employee or family member need a lawyer or the bank's fraud unit driving, not this workflow alone.