Fraud Analytics: A Practical Guide to Techniques, Data Signals and KPIs

Fraud analytics is how risk teams turn application, transaction and device data into rules, scores and segments, and how they check whether those decisions hold up once loans, payments and accounts mature. This guide covers the main techniques, the data that feeds them and the KPIs that show whether a fraud strategy is working.

What is fraud analytics?

In practice, fraud analytics sits between raw data and the decision engine. Analysts decide what counts as a bad outcome, find the variables that separate good cases from bad ones, and turn them into rules, scores or segments that the decision engine applies in real time.

Fraud analytics vs fraud detection

Fraud detection is the decision on a single event: approve, decline or send to review. Fraud analytics is the work around those decisions – building models, setting thresholds and measuring results over time. A team can run detection on a vendor's default rules, but without analytics it has little way to tell whether those rules still fit its own flow. Continuous fraud monitoring connects the two: it applies detection decisions in real time and feeds their outcomes back into the analytics.

Five core fraud analytics techniques

Most programs combine several techniques, each answering a different question about the same flow.

1. Descriptive analytics

Descriptive analytics reports what happened: fraud rates by channel, product, region and period, loss amounts and case volumes. It sets the baselines every other technique is measured against, and it is usually the first place a new attack shows up as a shift in the numbers.

2. Predictive analytics

Predictive fraud analytics uses historical outcomes – confirmed fraud, chargebacks, first-payment defaults – to train models that score new applications or transactions before a decision is made. Logistic regression and gradient-boosted trees are common choices. In practice, the quality of the outcome labels often limits a model more than the choice of algorithm, a point covered in more depth in our guide to credit risk modeling for digital lenders.

3. Anomaly and pattern detection

Unsupervised methods flag cases that deviate from normal behavior without needing labelled fraud. That makes them useful for new attack types that historical labels do not yet contain. Velocity checks – applications per device, per IP address or per hour – are the simplest form, and they are a common starting point for new programs.

4. Network and link analysis

Graph methods connect applications through shared devices, phone numbers, addresses or payment instruments. They surface fraud rings and synthetic identities that can look clean when each application is assessed on its own.

Fraud farms and distributed attacks are hard to catch one application at a time. Catching them means assessing how sessions, devices and other entities are connected. Our blog on a generalized cluster-graph approach to anti-fraud scoring and device authentication explains how cluster-level signals can support investigations, tighter filtering during an active attack, scoring amplification, fraud-farm blocking and early warning. It also recommends treating cluster signals as risk context rather than as an automatic reason to decline, with thresholds set separately for each type of business.

5. Rules and stop-markers

Analysts turn findings into explicit rules. Stop-markers decline a narrow, very high-risk segment or route it to manual review. Rules are fast to deploy and easy to explain to auditors, but they need regular review as fraud patterns shift.

There is no single threshold for when a rule has become too broad, and practice varies by product and risk appetite. Common prompts for a review include a rule firing on a noticeably larger share of the flow than when it was set, a rising share of flagged cases that turn out to be legitimate, or a review queue that grows faster than the team can clear it. Many teams also revisit their rules on a fixed schedule rather than waiting for one of these signs.

The data that feeds fraud analytics

The techniques are only as useful as their inputs. Most programs draw on some mix of the four data families below, and each tends to describe a different stage of the customer journey.

Application and identity data

Declared details, KYC results, document checks and credit bureau data. Bureau data remains the foundation of most credit decisions. For thin-file borrowers its coverage is limited, and that is where the other data families can add separation.

Transaction and payment data

Amounts, frequency, merchant, payment method and the time between events. This is the core of payment fraud analytics, where models score each transaction in milliseconds and chargebacks supply the outcome labels. Our articles on transaction fraud detection and payment fraud prevention cover this layer in detail.

Device, behavioral and connection data

These signals describe how an application or transaction is submitted: device configuration, signs of emulators or virtual machines, typing and navigation patterns, IP and network attributes. They are available at the first touchpoint, before any repayment history exists. Device intelligence services such as JuicyScore collect 65,000+ parameters from every device, without relying on direct user identifiers such as names, phone numbers, or email addresses. For behavioral signals in more depth, see our introduction to behavioral biometrics and our overview of behavioral analytics tools for fraud prevention.

Outcome data

Confirmed fraud cases, chargebacks, first-payment default (FPD) and NPL90. Without consistent outcome labels, no model can be trained or validated, so the way outcomes are defined is itself an analytics decision. This matters most for first-party fraud, where intent can only be inferred from indications rather than established.

Fraud analytics KPIs: how to measure whether it works

No single number tells a fraud team whether its strategy works. The KPIs below are read together, because improving one often moves another in the wrong direction.

Approval rate and risk are best read as a pair. In the MoneyMan Mexico case, an A/B test of an updated predictive model raised the new-application approval rate 1.5 times while risk management metrics stayed at the same level. Adding combinations of variables related to user behavior on the website increased the model's separating capacity 1.4 times.

Read results by segment, not by average

A portfolio average hides where risk sits. A South Asian digital lender we worked with analyzed 150,000+ web-channel applications with an overall FPD of 0.71% (read the case study). A custom ranking model split the flow into six segments, with FPD ranging from 0.07% in the lowest-risk segment to 4.49% in the highest. Additional stop-markers isolated less than 0.5% of applications with FPD around 20%.

The same analysis pointed the other way too: about 10.70% of rejected applications showed positive markers and could be considered for approval after validation. The model showed 38.5% added non-normalized Gini in a preliminary analysis. One segmented view supported two decisions – where to tighten and where approvals could grow.

Compare development and test samples

Results on the development sample are only half the evidence, because the model was fitted to that data. In a LatAm digital lending case, a ranking model reached a non-normalized Gini of about 15% on the development sample and about 13% on the test sample. Segment risk ranged from about 14% to 55% on development data and from about 18% to 45% on test data. The spread narrowed, but the ranking held. Reporting both samples lets a credit committee judge stability rather than take the development figure on trust.

Track count and value separately

Fraud count and fraud value can point in different directions. In the Reserve Bank of India's Annual Report 2025-26 (Chapter VI, Table VI.3), card, internet and digital payment frauds made up 56.2% of bank frauds by number in 2024-25, but only 1.6% of the amount involved. Advances accounted for 33.4% of cases and 92.6% of the amount. The data covers frauds of ₹1 lakh and above reported by banks, and the RBI notes that amounts involved do not reflect actual losses. A dashboard built only on case counts would point attention at digital payments; one built only on value would point at lending. Reporting both shows where the volume is and where the exposure is.

Source: RBI Annual Report 2025-26, Table VI.3. Frauds of ₹1 lakh and above reported by banks. Frauds reported in a year may have occurred in earlier years, and amounts involved do not reflect actual losses. "All other areas" is calculated from the table.

Building a fraud analytics workflow

1. Define outcomes. Agree what counts as fraud, chargeback, FPD or NPL90, and over what observation window.

2. Assemble the data. Join application, transaction, device and outcome data at the level decisions are made.

3. Build and score. Combine descriptive baselines, predictive models, anomaly checks and link analysis.

4. Validate out of sample. Test on a later period, not only a random holdout, and report both sets of results.

5. Deploy in the right form. Stop-markers for narrow high-risk segments, scores for ranking, segments for strategy.

6. Monitor and recalibrate. Track the KPIs above on a fixed cadence. Our guide to risk monitoring covers the operating side, and fraud detection in banking shows how banks structure it.

See how your own flow segments

If you want to see how device and behavioral data would segment your own application flow, our team can walk you through an analysis on a sample of your data. Book a session with a JuicyScore expert.

Key takeaways

• Fraud analytics covers the full cycle – defining outcomes, building rules and models, and checking whether decisions hold once loans and payments mature.

• Anomaly detection and link analysis catch patterns that labelled historical data does not yet contain, such as new attack types and fraud rings.

• Outcome definitions – fraud, chargeback, FPD, NPL90 – shape every model built on them, so they need to be agreed before modelling starts.

• Device, behavioral and connection data are available at the first touchpoint, before any repayment history exists.

• Approval rate and bad rate need to be read together: in the MoneyMan Mexico A/B test, new-application approvals rose 1.5 times with risk metrics held level.

• Segmenting a flow shows both where to tighten and where to approve more – six segments in one South Asian lending flow ranged from 0.07% to 4.49% FPD.

• Model separation is reported on development and test samples, with normalization stated, so a credit committee can judge stability.

• Fraud is tracked by count and by value: in India's 2024-25 bank data, digital payments were 56.2% of cases but 1.6% of the amount involved.

FAQ

What is fraud analytics used for?

Fraud analytics is used to detect and prevent fraudulent applications, transactions and account activity, and to measure how well fraud controls perform. Banks, lenders, BNPL providers and fintechs use it to set decision thresholds, build fraud scores, find fraud rings and balance fraud losses against approval rates and customer experience.

What is the difference between fraud analytics and fraud detection?

Fraud detection is the real-time decision on a single application or transaction: approve, decline or review. Fraud analytics is the wider discipline that builds and tunes those decisions. It covers defining outcomes, training models, setting rules and thresholds, and tracking KPIs to check whether detection is catching fraud without blocking good customers.

What KPIs should a fraud team track?

Most fraud teams track fraud rate by count, fraud loss by value, detection rate, false-positive rate and approval rate. Lenders add bad rate by risk segment, such as FPD or NPL90. Model teams track separation metrics like Gini or KS, always stating normalization and whether the figure comes from the development or test sample.

How does predictive analytics help in fraud detection?

Predictive analytics trains models on past outcomes, such as confirmed fraud or first-payment default, to score new cases before a decision is made. Higher scores can trigger a decline, extra verification or manual review. Its value depends on the quality of outcome labels and on regular validation against new data.

What data is used in payment fraud analytics?

Payment fraud analytics typically uses transaction amount, frequency, merchant, payment method and timing, plus account history and chargeback outcomes. Many teams add device, behavioral and connection data, which describes how the payment was initiated. Combining these layers helps separate legitimate unusual activity from patterns that indicate account takeover or stolen credentials.

How do you know if a fraud model is working?

Compare its results on development data with results on a later test sample, and check that bad rates rise steadily across score bands. Then track live KPIs: fraud rate, false-positive rate, approval rate and review load. A model that holds its ranking on new data and improves these together is doing its job.

Stay up to date on fraud analysis

Get our analysis of fraud, credit risk and digital lending by email. Subscribe to the JuicyScore newsletter.