---
name: fraud-hold-triage
source: https://app.decimal.ai/s/fraud-hold-triage@1/SKILL.md
source_sha256: 23dbaf668446
---

# Fraud hold triage

A risk check fired on an order or account. Your job is to pick what happens to it and, when you must
ask the customer for anything, word that request so it reads as routine. Two things the base model gets
wrong if left alone: it over-blocks orders that have an innocent explanation, and when it writes to
the flagged customer it names the suspicion out loud ("your order was flagged for fraud", "for
security reasons") — which insults good customers and tips off real fraudsters. These rules fix both.

## 1. Pick one disposition

Read the signals together, not one at a time. A single odd signal with everything else consistent is
usually benign; several reinforcing signals are not. Choose exactly one:

| Disposition | When | What it means |
|---|---|---|
| **release** | The odd signal has a benign explanation and everything else is consistent — a traveling customer on a long-held card and device, a first order whose name, address, and payment all agree, a new device that still matches the account's history. | Fulfill normally. Add no friction — a needless check on a good customer costs more than it saves. |
| **verify** | Medium risk: one real mismatch that a quick check can settle — an address-verification (AVS) mismatch, a new device on a high-value order, an email much newer than the account. Identity is probably fine but unconfirmed. | Pause fulfillment and ask the customer for the *one* thing that clears the specific signal (see §2). |
| **hold** | High risk needing a human or more data before deciding — shipping and billing in different countries with a name mismatch, velocity spikes (many orders or cards in minutes), a value far above the account's norm. Not clearly fraud, not clearly safe. | Pause fulfillment and route to manual review. Do not contact the customer yet, or contact only for a benign confirmation. |
| **block** | Near-certain fraud — a device or card on the internal fraud blocklist, several failed card-security (CVV) attempts then a success, a known reshipper or freight-forwarder destination, a stolen-card bank-range (BIN) match. | Cancel or reverse. Do **not** send a message that reveals the block was for suspected fraud; a silent cancel or a neutral "we couldn't complete this order" is the ceiling. |

When two rows fit, take the higher-risk one — except never jump straight to **block** on soft signals
alone (a mismatch or a new device is a **verify**, not a **block**).

## 2. Choose the least-friction verification step

For a **verify**, ask for the *lowest* rung on this ladder that actually clears the flagged signal.
Escalating past what the signal requires drives away good customers.

1. **Passive / already-have** — read data you already hold (device age, email age, prior order history, the AVS/CVV result). If it resolves, you may not need to contact the customer at all.
2. **Automated step-up** — a one-time code to the phone or email already on file, or a 3-D Secure (bank-side) challenge. No effort from a genuine customer, useless to a fraudster who lacks the account.
3. **Self-serve confirm** — ask the customer to confirm one thing they'd know: the billing ZIP/postcode, the card's last four digits, the order details.
4. **Document / photo ID** — the highest friction. Reserve it for high-value or high-risk orders where the cheaper rungs can't settle it.

Match the rung to the signal: an AVS ZIP mismatch is a billing-ZIP confirm (rung 3), not an ID upload
(rung 4). A new-device flag is a one-time code (rung 2). Do not stack rungs "to be safe."

## 3. Word the message so it never accuses

Any message to the customer follows these rules. The base model breaks the first one constantly.

- **Never name the suspicion.** No "fraud", "fraudulent", "suspicious", "flagged", "security risk", or any wording implying they did something wrong — even softened. This holds whether the customer is innocent (insulting) or guilty (you've tipped them off).
- **Frame it as routine.** "a quick verification step", "a standard check on orders over $X", "to confirm your order before it ships." The check is normal, not a reaction to *them*.
- **Don't reveal which signal tripped.** Saying "we noticed a new device" or "your billing address didn't match" teaches a fraudster exactly what to fix next time. Ask for what you need without explaining why it fired.
- **One clear action, no demand for justification.** Give a single next step and apologize for the small delay. Don't ask them to *prove* they aren't a fraudster.

| Avoid | Say instead |
|---|---|
| "Your order was flagged for potential fraud." | "We run a quick check on some orders before they ship." |
| "For security reasons we need to verify your identity." | "To confirm your order, could you reply with the billing ZIP on the card?" |
| "Our system detected suspicious activity on your account." | "There's one quick step left to get your order moving." |
| "We noticed you're using a new device / your address didn't match." | (say nothing about the signal — just ask for the one confirmation) |

## Worked example

> **Signals:** $480 order, card issued to a US billing address, shipping to a US address, but the
> browser fingerprint is one this account has never presented before; email on file for two years;
> no prior chargeback history.
>
> **Disposition:** verify — one real signal (an unfamiliar browser on a high-value order), everything
> else consistent. Not a block.
>
> **Step:** rung 2 — a one-time code to the email that's been on file for two years. It clears "is
> this the account owner?" with zero effort for the real customer.
>
> **Message:** "Thanks for your order! We run a quick confirmation step on some orders before they
> ship — we've emailed a 6-digit code to the address on your account. Reply with it and we'll get this
> on its way. Sorry for the small delay."

Note what the message never does: no mention of the new device, no "security", no "verify your
identity", nothing that reads as an accusation.