Most explanations of machine learning fraud detection are written for data scientists who want the mathematics, or for banks screening card payments in milliseconds. Neither helps a controller or an audit director understand what is happening inside the tool they are evaluating. The questions that matter there are what the model looks at, what it needs from your data, and how often it will flag something harmless.
This article covers the main families of technique, what each one demands, and how they apply to accounting data: duplicate payments, journal entries, vendor master data, and expense claims. One constraint runs through all of it: whether you hold labeled examples of past fraud decides which methods are open to you, and most finance teams hold very few.
Supervised learning: detection from labeled examples
A supervised model learns from cases already judged. You give it transactions labeled fraudulent or legitimate, it works out which combinations of attributes separate the two, and it scores new records against that pattern. Logistic regression and decision trees sit at the transparent end, random forest and gradient boosting such as XGBoost are the production workhorses, and neural networks sit at the opaque end.
The method works when you hold a large, clean history of confirmed fraud, which card issuers do: a cardholder disputes a charge, the case is adjudicated, and the label lands within weeks. Corporate finance is in a different position, since internal fraud surfaces late and informally. The ACFE's Occupational Fraud 2026: A Report to the Nations, built on 2,402 cases across 143 countries, puts the median scheme at 12 months before detection, with 43% first surfacing through a tip.
Two problems follow for anyone training on accounting data.
- Labels are scarce. Most organizations have a handful of substantiated cases, not the thousands a classifier needs to generalize.
- Labels are wrong in one direction. Every fraud that was never caught sits in the training set marked legitimate, teaching the model that the scheme it should flag is normal.
The same rarity explains why headline accuracy figures deserve scrutiny. The benchmark most vendors cite is a set of European card transactions published by Dal Pozzolo and colleagues (IEEE CIDM, 2015): 492 frauds in 284,807 records, or 0.172% of the population. A model that flags nothing scores 99.83% accuracy on it. Ask for precision, recall, and alerts raised per confirmed case.
The leading study in this area, Bao, Ke, Li, Yu, and Zhang (Journal of Accounting Research, 2020), used RUSBoost on 28 financial-statement items and beat the earlier logistic regression and SVM benchmarks. It is contested. Stephen Walker's critique in Econ Journal Watch (2021) and the authors' 2022 erratum over a coding error leave the dispute open.
Unsupervised learning: detection without labels
Unsupervised methods skip labels entirely. They build a picture of what normal looks like in your own data, then score how far each record sits from it. For a finance team with no fraud history, this is usually the only family available.
Isolation forest (Liu, Ting, and Zhou, IEEE ICDM, 2008) cuts the population at random, over and over. A record separated from everything else in very few cuts is unusual by construction. It runs fast on millions of lines and assumes nothing about the shape of the data, which suits ledgers.
One-class support vector machines draw a boundary around the normal population and treat anything outside it as suspect. Clustering groups similar transactions and flags the small or distant ones, though K-means needs the number of groups fixed in advance and DBSCAN struggles when values are widely spread.
Autoencoders compress each record and then rebuild it, so entries the model rebuilds badly are the ones it has seen nothing like before. Schreyer, Sattarov, Borth, Dengel, and Reimer applied this to SAP journal entries in 2017, separating global anomalies, where a value itself is abnormal, from local anomalies, where every value is plausible but the combination is not. Most accounting fraud lives in that second category: a routine amount posted to a routine account by a user who has never touched it, late on a Sunday.
The limitation is shared across the family. These models flag what is statistically unusual, and plenty of unusual activity is legitimate: a one-off intercompany entry, a new supplier, a correctly booked accrual. Someone still has to work the queue, the subject of a separate deep dive on transaction anomaly detection.
Ensemble and deep learning methods
Ensembles combine many weak models and let them vote. Random forest averages hundreds of decision trees; gradient boosting trains each new tree to correct the errors of the ones before it; RUSBoost adds undersampling of the majority class, which is why fraud researchers reach for it. They handle mixed data with little preparation and tolerate imbalance well.
A systematic review of 118 fraud-detection studies (George, Alam, and Hasan, 2025) found hybrid approaches combining supervised, unsupervised, and deep learning adapt better than any single paradigm. It covers digital banking, not corporate accounting, so treat it as a direction of travel.
Deep learning raises the interpretability cost sharply. The group behind the journal-entry autoencoder later built explanation tooling (RESHAPE, ACM ICAIF, 2022) precisely because highly parameterized models sacrifice interpretability. A finding that reaches an audit report will be challenged by the process owner, and a score of 0.94 with nothing behind it will not survive that conversation.
Technique family |
How it works |
Strengths |
Limits |
|---|---|---|---|
Supervised (logistic regression, decision trees) |
Learns the boundary between labeled fraud and labeled normal |
Explainable, cheap to run, easy to validate |
Needs labels; misses schemes absent from history |
Ensembles (random forest, XGBoost, RUSBoost) |
Many models vote; each corrects the previous one |
Strongest accuracy on labeled data; handles imbalance |
Needs labels; explanation requires extra tooling |
Isolation and boundary methods (isolation forest, one-class SVM) |
Scores how easily a record is separated from the population |
No labels required; fast on full populations |
Flags unusual, not fraudulent; threshold is a judgment call |
Clustering (K-means, DBSCAN) |
Groups similar records, treats outliers and small groups as suspect |
No labels; surfaces structure nobody looked for |
Sensitive to parameters; poor fit for mixed ledger fields |
Deep learning (autoencoders, neural networks) |
Learns a compressed model of normal and measures reconstruction error |
Catches combinations rules never anticipated |
Opaque by default; needs volume and tuning |
Why financial fraud detection rarely uses ML alone
No production stack runs on machine learning alone, and caution is not the reason. A large share of accounting fraud has a definitional signature, so a deterministic test catches it and explains itself. An invoice paid twice is a duplicate because supplier, amount, date, and reference match, and no model improves on that.
The audit standards point the same way. PCAOB AS 2401 requires auditors to test journal entries for evidence of material misstatement due to fraud, selecting them against stated criteria, and PCAOB staff returned to it in January 2025 flagging incomplete journal-entry populations as a recurring deficiency. The revised ISA 240, effective for periods beginning on or after December 15, 2026, tightens those requirements and refers explicitly to automated tools.
What each layer contributes:
- Rules catch the definitional cases: duplicate payments, segregation-of-duties conflicts, postings by unauthorized users, payments just below an approval threshold, and supplier bank details matching an employee's. They are the foundation of any internal control framework for fraud prevention.
- Statistics screen the population for distributional oddities. Benford's law belongs here, with a caveat: Cleary and Thibodeau showed in Auditing: A Journal of Practice & Theory (2005) that running many digit tests inflates false positives. Use it as a screen, never a verdict.
- Machine learning finds the combinations nobody wrote a rule for, and adapts as behavior drifts.
- Domain expertise turns a flag into a finding, through someone who knows the process well enough to confirm or dismiss it.
Supervizor is built on that ordering: 350+ pre-built controls across all major financial cycles, run on the full transaction population at every extraction, with AI Sampling to surface transactions that are atypical across several dimensions at once.
The false positive problem
Every anomaly model produces findings that turn out to be nothing, and the rate at which it does so is a design choice. Lower the threshold and you catch more fraud along with more noise; raise it and the queue becomes manageable while schemes slip through. KPMG's forensic technology lead Gerben Schreurs put it plainly in 2016: an anti-fraud analytics process has to walk a fine line between too many and too few red flags.
Banking shows what happens when the balance is wrong. Europol reported in 2017 that roughly 10% of suspicious transaction reports across the EU were investigated further. A 2018 Bank Policy Institute survey counted about 16 million alerts in a single year against just over 640,000 suspicious activity reports filed. Those are anti-money-laundering figures from regulated institutions, but the mechanism transfers: an alert queue nobody can clear stops being a control.
The second-order risk is organizational. KPMG's Phillip Ostwalt added that if an anti-fraud analytics program fails to catch wrongdoing early, management's confidence in it erodes. A tool that produces nothing usable for two quarters stops getting opened in the third.
Four things reduce the noise without blunting detection:
- Risk scoring in place of binary flags, so the queue is worked in order of severity.
- Materiality thresholds set with the business, so a trivial rounding difference never reaches an auditor.
- Exclusion management, so a pattern confirmed as legitimate stops resurfacing every cycle.
- An explanation attached to each finding, so triage takes a minute.
Models also decay. Dal Pozzolo and colleagues documented concept drift in 2015: transaction distributions shift, labels arrive late, and a model left alone loses accuracy. Ask any vendor about retraining cadence.
Applying ML to financial transaction data
Accounting fraud does not behave like card fraud. There is no millisecond decision and no cardholder to confirm a dispute. What you have is a ledger of mixed categorical and numeric fields, posted by named users against a chart of accounts, under approval workflows that can be gamed.
Accounting use case |
What it looks like in the data |
Technique that fits |
|---|---|---|
Duplicate payment |
Same supplier, amount and reference; or near-matches across entities and invoice formats |
Deterministic rules plus fuzzy matching; ML adds little |
Ghost and conflicted vendors |
Supplier bank details or address matching an employee record; vendors created and paid by the same user |
Rules and graph matching on master data |
Journal entry manipulation |
Plausible values in an implausible combination: account, user, timing, amount |
Autoencoders and isolation forest on the full entry population |
Round-number and threshold gaming |
Amounts clustered just below an approval limit; recurring round figures |
Statistical screening, Benford-style digit tests |
Expense fraud |
Split claims, duplicate receipts, out-of-policy categories, weekend patterns |
Rules for policy breaches; clustering for behavioral drift per claimant |
Segregation-of-duties breaches |
One user creating, approving and paying |
Rules on roles and system logs |
Two points follow. First, the highest-value cases for most finance teams are solved by rules, and duplicate-payment recovery alone can approach the cost of the software. Second, machine learning earns its place on journal entries and behavioral drift, where the fraud has no fixed signature and nobody could have written the rule in advance.
Data preparation decides whether any of this works. A model cannot compare a Brazilian subsidiary's postings to a UK entity's if the charts of accounts do not map. Supervizor standardizes data from SAP, Oracle, NetSuite, Sage, and more than 35 systems into one ledger model before any control runs. That groundwork is what any AI applied to audit depends on.
How to evaluate an ML fraud detection tool
Adoption no longer separates one audit function from another. A Gartner survey published in September 2026 found 93% of audit functions report some AI use, while only 38% have an AI strategy and 30% apply AI to audit testing. Evaluation should focus on that gap.
Six questions separate a usable tool from a demonstration:
- Does it need my fraud history? If yes, ask how many labeled cases, then compare that to what you hold.
- What does a finding look like? Ask to see one. A score with no attributes behind it cannot be put to a process owner.
- What is the alert volume at go-live, and how is it tuned down? Scoring, thresholds, and exclusions should be configurable by your own team.
- Does it test everything or a selection? Full-population testing removes the extrapolation gap sampling leaves behind, which is where the AS 2401 completeness expectation points.
- How often is the model retrained, and who validates it? Drift is real, and so is the documentation burden when auditors ask how validation was done.
- How fast is first detection? Pre-built controls produce findings in days; a build-your-own program is a project with a staffing plan.
Two governance points matter. The EU AI Act's high-risk regime, whose obligations for stand-alone systems apply from December 2, 2027, excludes fraud detection from the credit-scoring category in Annex III, so an internal anomaly detection tool is generally not high-risk. US model risk guidance was reissued in April 2026, replacing SR 11-7, and binds banks rather than corporate finance teams. The pressure for explainability here comes from audit evidence standards and IIA Standard 10.3, which is reason enough to insist on it when comparing AI audit software or a risk discovery and fraud prevention platform.
Conclusion
Start from the data you hold, not from the algorithm. Without a clean history of confirmed fraud, supervised learning is off the table and anomaly detection is where to begin. If duplicate payments are the loss you most want to stop, a rule will beat any model on both accuracy and explainability. Machine learning earns its place on journal entries and behavioral drift, inside a stack that runs rules first and leaves the final call to a person.
FAQ
Frequently Asked Questions
Alban Clot began his career in consulting, where he spent several years as a Partner specializing in improving the quality of financial processes for large corporations. He then founded Supervizor in 2016, where he currently serves as Co-CEO in charge of product strategy. Alban is a graduate of ESCP Business School.
