Fraud Detection Requirements Template

This is the core tradeoff in fraud detection. Start by understanding your cost asymmetry: how much does a fraudulent transaction cost versus a false decline? For most payment products, a false decline costs less than a chargeback (lost revenue plus fees plus reputational damage). Set your initial thresholds to favor higher detection even if false positives are slightly elevated, then tune down as your model improves. Track the [net promoter score](/glossary/nps-net-promoter-score) impact of false declines to quantify customer friction.

Both. Rules handle known patterns with high confidence (velocity limits, blocklisted devices, impossible travel). ML models catch novel patterns that rules miss and adapt as fraud tactics change. The typical architecture is a pipeline: rules execute first for known patterns, then the ML model scores the remaining transactions. Rules provide explainability and immediate control. ML provides coverage against evolving threats. The [AI PM Handbook](/ai-guide) covers model evaluation patterns that apply directly to fraud detection.

Review rules monthly for effectiveness (precision, recall per rule) and quarterly for strategic alignment. Rules that fire frequently with low precision (many false positives) are candidates for tuning or retirement. Rules that never fire may be obsolete. After any significant fraud incident, review and update rules within 48 hours. Keep a changelog of rule modifications for audit purposes.

At minimum, you need labeled historical transaction data: transactions marked as fraudulent (confirmed chargebacks, manual reviews) and legitimate. Six months of data is a practical minimum; 12-18 months is better for capturing seasonal patterns. Feature engineering is where most of the value comes from. Transaction features (amount, time, merchant), user features (account age, history), device features (fingerprint, geolocation), and behavioral features (session patterns) all contribute. The ratio of fraud to legitimate transactions is typically very imbalanced (< 1% fraud), so you will need techniques like SMOTE or class weighting.

Calculate fraud losses prevented (detected fraud value minus false positive costs) minus system operating costs (infrastructure, model development, analyst salaries). Use the [AI ROI Calculator](/tools/ai-roi-calculator) to model the financial impact. Key inputs: current chargeback rate and volume, target detection rate improvement, analyst cost per reviewed alert, and false positive revenue impact. A well-tuned system typically delivers 5-10x ROI on operating costs through reduced chargebacks and lower manual review volume. ---