70 ways customers commit return fraud and what we look for

Every fraud-prevention SaaS makes the same pitch on its homepage: "AI-powered detection of return fraud." The pitch tells you nothing about what the system is looking at. AI does not look at things; the people who built the AI looked at specific things and decided which of those things to weight. The signals are the contract. The math on top of the signals is calibration.

This post is the open version of our signal catalog. We run more than 70 individual signal evaluators in production. Listing all 70 in one post would be a wall of text and a bad reading experience. Instead, the 70 signals organize cleanly into nine clusters. Below is one paragraph per cluster (what the cluster captures and what kind of fraud pattern it sees) and two or three concrete signal examples per cluster. Anyone who wants the full registry can request it.

How the score is built

Before the catalog, the math. Every signal that fires on an order contributes to the score using the calibrated formula:

contribution = maxPoints × severity × merchantWeight × reliability

maxPoints is the spec-owned maximum, severity is in [0, 1] (how strongly the signal fired), merchantWeight is in [0, 2] (currently 1.0 for every shop), reliability is in [0.25, 1.5] (how predictive this signal has been on this merchant's outcomes). Contributions sum, cap rules apply, score normalizes to 0-100. Confidence is computed independently from score.

Now the catalog.

Cluster 1: velocity

Velocity signals look at how fast a customer is doing something. Returns within X days of order, orders within Y minutes of account creation, refunds within Z hours of delivery. The signature pattern is "the action is too fast to be normal customer behavior." Velocity captures both impulse fraud (a fraudster trying to extract value before the merchant catches on) and serial fraud (a customer running a high-frequency return cycle).

Three signals from this cluster:

• Refund within 60 minutes of delivery is the canonical "wardrobing or carrier-fraud" pattern. The customer received the package, photographed it, returned it, refunded.
• Account-to-order velocity fires when a customer creates an account and places an order within 5 minutes, which is a normal first-time-shopper pattern but becomes anomalous when stacked with other signals.
• Returns-per-month rate above merchant baseline uses the per-merchant baseline (spec 158) to detect customers whose return frequency is above the 95th percentile for their cohort within this specific merchant.

Cluster 2: identity and network

Identity signals look at the relationships between a customer and the rest of the customer base on this merchant (and across merchants in the network). The signature pattern is "this customer's identifying attributes overlap with another customer's in a way that is hard to explain by chance." Spec 105 introduced the original 13 signals in this cluster; spec 197 extended several of them to operate across merchants.

Three signals from this cluster:

• Cross-shop chargeback hash fires when the customer's hashed email or phone has been flagged for chargeback at another merchant in the network in the last 90 days. Hard evidence; cap-immune.
• Multi-account address fires when 3+ customer accounts ship to the same address fingerprint within a 90-day window. Soft evidence; corroboration-required.
• Customer-name fragment match fires when the customer's typed name (case-folded, punctuation-stripped) shares a 5+ character prefix with another customer at a different address.

Cluster 3: value-aware

Value signals scale their evidence by the dollar magnitude of the order, the refund, or the customer's lifetime spend. The signature pattern is "the same action means more on a $400 order than on a $40 order." Most fraud-prevention tools collapse this dimension; we keep it explicit because the merchant's tolerance for false positives is dollar-asymmetric.

Three signals from this cluster:

• High-value order on new account fires when the order's value is above the merchant's 95th percentile and the account is under 7 days old.
• Refund amount above order subtotal fires when the refund somehow exceeds the original subtotal (rare; usually a manual-refund mistake but occasionally a fraud pattern with shipping inflation).
• Customer LTV-to-refund ratio fires when the customer's cumulative refunds exceed 80% of their cumulative spend.

Cluster 4: payment-method

Payment signals look at the payment instrument itself, retry sequences, and unusual processor signals. The signature pattern is "the payment side of the transaction looks anomalous in a way that the order-side does not."

Three signals from this cluster:

• Failed payment attempts before success fires when the customer's card declined twice and succeeded on a third attempt with a different card.
• Non-canonical payment processor fires when the merchant uses Shopify Payments by default and this order came in via a fallback processor.
• BNPL refund pattern (spec 126) fires when the customer's refund amount on a Buy Now Pay Later order is below the BNPL provider's minimum-installment threshold, suggesting an attempt to extract goods while leaving the BNPL cycle running.

Cluster 5: return-reason

Return-reason signals look at the merchant-typed or customer-typed reason on the return record. The signature pattern is "the reason is structurally unusual or incompatible with the rest of the order data." Spec 132 added the gift-return cluster; spec 134 added the viral-product-returns cluster; spec 56 added INR (item-not-received) detection.

Three signals from this cluster:

• INR with delivery confirmation (item-not-received but the carrier reports delivered) is the classic carrier-fraud signal.
• Gift-recipient return without recipient handoff fires on returns where the order was marked gift but the return was initiated by the buyer's account rather than the recipient's.
• Viral-product return surge fires when a single product SKU sees a return spike that is anomalous against the merchant's per-SKU return-rate baseline.

Cluster 6: refund-method

Refund-method signals look at how the refund was actually paid (original payment method, store credit, gift card, manual). The signature pattern is "the refund pathway is unusual for this combination of order and customer."

Three signals from this cluster:

• Refund-method switch fires when a customer's refund pathway switches from store credit to original payment method on a subsequent return.
• Staff-issued goodwill refund fires when the refund was issued manually by a merchant-side staff member outside any return record. Useful for detecting refund-leakage rather than customer fraud, but the same pattern can indicate social-engineering attacks against customer support.
• Refund-to-different-card fires when the refund is being issued to a payment instrument different from the original.

Cluster 7: holiday surge and seasonality

Holiday signals are time-aware overlays on the rest of the catalog. The signature pattern is "the same action would be normal at any other time of year and is anomalous in the current window." Most retailers see fraud spike in the post-holiday window (gift returns, multi-buyer fraud); the engine adjusts thresholds during those windows.

Two signals from this cluster:

• Post-holiday return spike fires on returns landing in the 14 days after a major holiday on items purchased in the 14 days before the holiday.
• Seasonal-category mismatch fires on returns of clearly-seasonal items (winter coats, swimwear) outside their natural season.

Cluster 8: coordinated rings (spec 135)

Ring signals are the cross-customer cluster outputs from the fraud-ring detection batch. They consume the FraudRingAlert table populated by the nightly clustering job (covered in Post 6 of this series). The signature pattern is "this customer is part of a multi-account cluster that has been detected on this merchant."

Two signals from this cluster:

• Open ring-membership fires when the customer is in a FraudRingAlert cluster with status open.
• Confirmed-ring-membership fires when the customer is in a cluster where another member has been confirmed-as-fraud by the merchant. Hard evidence; cascades automatically (spec 119 R-002 with the 10-member threshold for queued vs inline cascade).

Cluster 9: friendly-fraud (spec 189)

Friendly-fraud signals look for the pattern where a real customer with a real account disputes a charge with their bank rather than asking the merchant for a refund. The signature pattern is "the chargeback came from a customer who would have qualified for a refund through normal channels." Friendly fraud is the largest category of fraud chargebacks in DTC, and it is the hardest to detect because the customer's identity and address are not anomalous.

One signal from this cluster:

• Pre-chargeback contact silence fires when the customer placed an order, did not contact customer support, and the chargeback notice arrives directly from the processor. The signal is a soft prior on friendly-fraud risk; it never produces HIGH zones on its own.

Cap rules

A score that is dominated by a single signal cluster is at high risk of being a false positive. The risk engine has two cap rules to defend against single-cluster runaways:

Single-soft-group: if every signal that fired came from one non-hard-evidence group, the score is capped at the merchant's MEDIUM ceiling. A customer who triggers four velocity signals but no identity, value, or payment signals gets the cap.

High-gate insufficient-corroboration: if the raw score crosses into HIGH territory but no hard-evidence signal fired AND fewer than two soft-evidence clusters are represented, the score is downgraded to MEDIUM. The hard-evidence override exempts cases where chargeback data, ring-confirmation, or another labeled-outcome signal independently lands the score in HIGH.

Both cap rules are deliberately mechanical, predictable, and auditable in production via the per-order "explain why this score" panel.

Engineer detail. Each signal evaluator declares its maxPoints and evidenceGroup in the registry at app/lib/risk/signals/. The maxPoints is spec-owned (not merchant-tunable); spec 166 retired the merchant-weight override channel because the per-merchant tuning UI produced incoherent overrides on the small number of merchants who used it.

Severity is signal-native (the evaluator emits a severity value in details) or adapter-derived (the engine computes severity = points / maxPoints if the evaluator does not declare it). Native severity is preferred because it lets the evaluator make a more nuanced judgment than the linear ratio.

The two-pass engine handles signals like guestCheckoutReturner that need to know what other signals fired. First pass evaluates non-postPass signals; second pass invokes postPass hooks. The hooks are first-class, generic, and not signal-name-special-cased; any signal can declare postPass: true and the second pass picks it up.

Reliability learning lives in app/lib/risk/learning/ and consumes SignalEffectStat aggregates. The aggregator counts (signal-fired, customer-flagged) and (signal-fired, no-flag) tallies per merchant per signal. Reliability resolves with a Bayesian prior that pulls toward 1.0 when the merchant has too few outcomes for a stable estimate. Hard-evidence signals (chargebacks, confirmed rings) are exempt from learning and stay at reliability 1.0 forever.

What we deliberately did not build

A "trust score" composite signal that collapses everything to a single number; a "model confidence" feedback loop that lets the model adjust its own score; a "customer reputation" meta-signal that follows a customer across orders. Each one gets proposed, each one gets pushed back. The catalog stays at the level where individual signals are auditable.

Take-away

Open signal catalogs are unusual in fraud-prevention SaaS. The reason most companies do not publish them is that the catalog is the most directly comparable surface area. Ours is open. If a merchant has seen a pattern that does not fit one of the nine clusters above, the response form captures inbound feedback. We have shipped new signals because of merchant requests.

RefundSentry is an intelligence layer for Shopify return fraud. See pricing for plans during the private beta.