Fraud Signal Baseline Audit (Onboarding)

Fraud Signal Baseline Audit (Onboarding)

1. 01

   Pull 90 days of chargeback, refund, and account-takeover records from the client's payment processor before touching any scoring vendor

   Stripe, Adyen, and Shopify Payments all export dispute reason codes. Sort by reason code so the client sees which loss type dominates: stolen card, friendly fraud, or credential stuffing.

2. 02

   Segment the loss data by traffic source and device class

   Paid social, affiliate, and organic traffic carry different fraud profiles. A 0.4% dispute rate on affiliate traffic can be ten times the organic rate and still hide inside a blended 0.6% average.

3. 03

   Map every identity field the client already collects against the signals a scoring platform can return

   Email, phone, IP, device hash, and shipping address each map to a different signal family. Gaps here determine whether a device intelligence tool like Fingerprint or an IP and email API such as IPQS adds coverage or duplicates what the client already has.

4. 04

   Document the client's current manual review capacity in hours per week and cost per review

   Agencies routinely find three staff spending 12 hours weekly on order review. That number becomes the baseline the fraud layer has to beat, not just the chargeback figure.

5. 05

   Agree on a numeric success threshold with the client in writing before any integration work starts

   Targets like a 30% reduction in dispute rate within 90 days, or manual review volume cut to under 5% of orders, keep the engagement measurable and prevent scope drift into general security consulting.

6. 06

   Identify which client systems will receive a risk score and which will only receive a pass or block decision

   Checkout, account signup, and password reset each tolerate different false-positive rates. A block on signup costs a lead; a block on checkout costs revenue, so the thresholds cannot be identical.

7. 07

   Record the client's regulatory and data-residency constraints in the same document

   Fintech clients under PSD2 or state privacy statutes may restrict where device and IP data can be stored. Catching this at onboarding avoids rebuilding the integration after legal review.