Why Traditional Sampling Is Inadequate for Fraud Detection
Standard statistical sampling in audit work is designed to provide conclusions about the population from which the sample is drawn. It works well for testing whether a defined control operated effectively across a large number of transactions. It works poorly for detecting fraud, for two reasons.
First, fraud is typically concentrated in a small number of transactions — and a sample drawn from a large population has a low probability of selecting any of the fraudulent transactions unless the population is very small. A fraud that affects 0.5% of transactions has approximately a 5% chance of appearing in a sample of ten items. The auditor examines the other 95% of the sample perfectly and concludes the controls are effective — while the fraud continues undetected.
Second, sophisticated fraudsters understand sampling. Employees with knowledge of audit procedures deliberately design fraudulent transactions to avoid the characteristics that would make them more likely to be selected in a sample — keeping amounts below review thresholds, avoiding the highest-risk periods that receive more scrutiny, using authorisation paths that are consistent with legitimate transactions.
Key Analytical Techniques for Fraud Detection
Population completeness verification: Before any analytical testing, verify that the dataset is complete. Gaps in transaction sequences, unusual timing patterns in data extracts, or population counts that do not match system records may themselves be evidence of suppressed transactions or manipulated records.
Duplicate analysis: Identify transactions with identical or near-identical characteristics — same amount, same vendor, same period, similar descriptions. Payment systems with strong controls should have very few legitimate duplicates. The presence of duplicates, particularly in high-value payment streams, warrants investigation.
Threshold analysis: Identify transactions that cluster just below authorisation thresholds. If the approval threshold for expenses is $500, a population of expense claims that shows an unusually high density of claims at $490-$499 compared to $501-$510 suggests deliberate circumvention of the approval limit. This pattern is nearly impossible to detect through sampling but obvious in full-population analysis.
Vendor analysis: Cross-reference vendor master data against employee data for shared addresses, phone numbers, bank account details, or names. Analyse vendor payment concentration — are any vendors receiving a disproportionate share of total payments? Identify vendors with no physical address, no verified business history, or with similar bank account details to other vendors.
Relationship network analysis: Map the approval chains for transactions — who approves whose expenses? Who authorises which vendors? Network analysis can identify approval loops that should not exist, approval concentrations in single individuals, and patterns of mutual approval between colluding parties.
Time-series anomaly detection: Analyse transaction patterns over time for unusual spikes in volume or value, activity during non-business hours or periods when supervisors are absent, and seasonal patterns that deviate significantly from prior years without business explanation.
The goal of data analytics in fraud detection is not to prove fraud — it is to identify anomalies that warrant investigation. Every anomaly has an explanation, and most explanations are legitimate. The analytical procedure narrows the field; investigation determines the cause.
Building an Analytics-Based Fraud Detection Programme
Effective deployment of data analytics for fraud detection requires several foundations. Data access arrangements must be established with IT and system owners — audit analytics depends on reliable, complete data extracts, and these arrangements often require significant coordination. Analytical tools must match the team's capability — sophisticated scripted analyses in Python or SQL are more powerful but require more skill than Excel-based procedures. And the programme must include a structured process for investigating flagged anomalies — the analytical output is only as valuable as the investigation process that follows it. Without a clear workflow from anomaly detection to investigation to resolution, a fraud analytics programme produces a large volume of flags and limited follow-through.