How to Build a Fraud Detection System (Playbook)

Fraud detection is an adversarial problem: every control changes attacker behavior, and yesterday's model decays as patterns shift. A production fraud detection system is therefore a loop rather than a model: rules for known patterns, models for novel ones, analysts who decide hard cases and generate labels, and retraining that keeps pace. This playbook covers the build, following FISTA's AI enablement practice. Context is in ai fraud detection and, for adjacent controls, ai anti-money laundering.

What does the system do?

Stage	Function	Latency
Ingest	Transactions, sessions, devices, accounts, external signals	Streaming
Enrich	Entity history, velocity, device and network features	Milliseconds
Rules	Known patterns, lists, thresholds, regulatory rules	Milliseconds
Model scoring	Calibrated risk score from features	Milliseconds
Decision	Approve, challenge, review, block by policy	Milliseconds
Analyst review	Investigate flagged cases with explanations	Minutes to hours
Feedback	Outcomes to labels; retraining; rule updates	Continuous

Step 1: Define fraud types, decisions, and costs

With fraud operations and product, define the fraud types in scope, the decision actions available, the cost of each error type (fraud loss, chargeback, customer friction, analyst time), regulatory constraints, and latency budgets. These define the operating thresholds and the evaluation metrics. See how to write acceptance criteria for ai.

Step 2: Assemble data and labels

Bring together transaction history, account and entity data, device and session signals, and outcome labels from chargebacks, analyst decisions, and customer reports. Understand label delay and noise; define maturity windows. Build entity resolution across accounts, devices, and payment instruments. Data practice is in how to prepare data for ai and ai training data checklist.

Step 3: Engineer features

Build features that capture behavior over time and across entities: velocity counts over windows, deviation from entity baselines, device and location consistency, network features linking entities, and merchant or counterparty risk. Compute them in a feature store that serves both training and real-time scoring consistently. See how to build a feature store.

Step 4: Design rules and models together

Rules encode known patterns, lists, regulatory requirements, and rapid responses to emerging attacks; they are versioned, tested, and measured. Models, typically gradient-boosted trees or neural approaches, learn subtle patterns and produce calibrated scores. Combine them in a decision layer with policy thresholds per segment. Address class imbalance in training and evaluate models on mature cohorts. Model practice is in how to build a predictive model and how to build an anomaly detection system.

Step 5: Build real-time scoring

Serve features and models within the latency budget, with fallbacks (rules-only or cached scores) when components fail, idempotent decision logging, and shadow scoring for candidate models. Architecture patterns are in batch vs real-time inference and what is model deployment.

Step 6: Design analyst review

Analysts receive prioritized cases with the score, the rules and features that drove it in plain language, entity history, and linked cases, and they record decisions in structured form. Language models can assist by summarizing case context and drafting notes, with analysts confirming. Their decisions become labels. Queue design is in how to build a human review queue.

Step 7: Close the feedback loop

Pipe analyst decisions and chargeback outcomes into the label store; retrain on a schedule and on drift triggers; validate candidate models in shadow against the champion; and update rules as new patterns are confirmed. Track model and rule contribution over time. Drift concepts are in what is model drift and how to monitor ai in production.

Step 8: Evaluate with cost-weighted metrics

Report fraud loss prevented, false-positive rate and its cost, precision and recall at operating thresholds by segment, alert volume per analyst, time to detect new patterns, and fairness of outcomes across customer groups where regulation requires. Evaluate on mature, time-split cohorts to avoid leakage. Method is in the AI evaluation and testing whitepaper.

What governance does the system need?

• Model risk management: inventory, validation, monitoring, documentation; see ai model risk management.
• Explainability for adverse actions where required; see ai explainability requirements.
• Fairness testing on customer outcomes.
• Access control and audit on decisions and analyst actions.
• Change control on rules, models, and thresholds.

Regulated institutions should align with the AI controls for financial services whitepaper. This playbook is general guidance, not legal or regulatory advice.

What does it cost to run?

Cost drivers are streaming infrastructure, feature computation, model serving at volume, analyst capacity, and retraining. Value is fraud loss prevented net of false-positive cost. Drivers are in fraud detection system cost.

What are the common mistakes?

• Treating fraud detection as a one-time model build.
• Training on immature labels and overestimating performance.
• Features computed differently in training and serving.
• No rules layer, so known attacks wait for retraining.
• Analysts without explanations, so decisions are slow and labels noisy.
• Optimizing accuracy on an imbalanced problem.

Worked example: card-not-present transaction fraud

A payments team combines rules for known patterns such as velocity spikes and mismatched geographies with a gradient-boosted model trained on mature chargeback labels and analyst decisions. Features from a shared store include transaction velocity across windows, device and account history, merchant risk, and network links between accounts. Scoring runs within the authorization latency budget with a rules-only fallback. Decisions are approve, step-up challenge, or review by segment thresholds set from cost analysis. Analysts see the top drivers in plain language and record structured outcomes that feed the label store. Candidate models run in shadow against the champion before promotion, and cost-weighted reporting shows fraud loss prevented against the customer friction of false positives by segment.

How FISTA Solutions builds fraud detection systems

FISTA Solutions builds fraud detection systems to this playbook: cost-defined specifications, label-aware data pipelines, feature stores serving training and real time consistently, layered rules and calibrated models, low-latency scoring with fallbacks, explainable analyst review, closed feedback loops, and cost-weighted evaluation under model risk governance. The AI enablement practice delivers the platform, AI agents assist analysts and automate case handling, and forward deployed engineers embed with your fraud operations team. The record behind the work is 150+ projects with 99.9% uptime.

To scope a fraud detection system, message FISTA on WhatsApp, or read ai in payments for the sector context.