AI-Powered Fraud Detection: How Machine Learning Flags Anomalies

8/6/2026

Before evaluating any of this, understand the statistical situation you are in. It determines everything else.

Fraud is rare. In a population of transactions, the fraudulent proportion is very small. And that single fact creates a problem that no amount of model accuracy solves:

When the underlying rate is very low, most of what a model flags will be legitimate — even when the model is highly accurate.

The intuition people bring is wrong here. A model that correctly identifies almost all fraud and rarely misfires still produces an alert queue in which the honest transactions outnumber the fraudulent ones, because there are so overwhelmingly more honest transactions to misfire on.

This is not a criticism of the technology. It is the structural condition, and it means the practical question is never "is the model accurate." It is "can we work the queue it produces."

Supervised Versus Unsupervised, and Why It Matters

The distinction that determines what you can actually deploy.

Supervised learning requires labeled examples — transactions known to be fraudulent and known to be legitimate — from which the model learns to distinguish them. It is the more powerful approach where the labels exist.

Unsupervised anomaly detection requires no labels. It learns what normal looks like and flags departures from it.

Now the practical consequence: almost no organization has enough labeled fraud to train a supervised model well. Fraud is rare, most of it is never detected, and the cases that were detected are few. A large bank or card network has enough. A mid-market company does not, and an accounting firm's client does not.

So in practice, what most organizations can deploy is unsupervised anomaly detection — which finds unusual, not wrong.

That distinction is the one to hold onto. An unusual transaction may be fraud, an error, a legitimate exception, a new business arrangement, a system change, or a seasonal pattern the model has not seen. The model has told you something is different. It has not told you anything is wrong.

The Label Problem Is Worse Than It Looks

Even where labeled data exists, there is a subtler issue that is rarely discussed.

Your labeled frauds are the frauds you caught. Which means the model learns the characteristics of detected fraud — and detected fraud is a biased sample of all fraud, biased precisely toward whatever your existing controls and habits are good at finding.

Two consequences:

The model tends to reproduce your existing detection capability rather than extend it. It gets very good at finding the kind of thing you were already finding.

Novel schemes, and schemes your controls are blind to, are underrepresented in training and therefore under-detected.

Related: the adversary adapts. A person who learns which patterns trigger review changes their behaviour, which means model performance degrades over time in a way that ordinary drift monitoring may not catch — because the change is deliberate and targeted.

What It Genuinely Does Well

Being specific, because there is real capability here and the skepticism above should not obscure it.

Entity resolution. Matching records that refer to the same person or business across spelling variants, abbreviations, transposed digits, formatting differences, and partial addresses. This is where the technology beats a human decisively, and it is directly useful — the vendor-master-to-employee-master comparison in our post on embezzlement detection is far more effective with fuzzy matching than with exact matching, because a perpetrator does not use their own address verbatim.

Continuous monitoring at volume. Scoring every transaction as it occurs, across populations no human review could cover. The value is coverage, not judgment.

Network and relationship detection. Finding connections between entities — shared addresses, phone numbers, bank accounts, directors, or IP addresses — that indicate related parties nobody disclosed. Genuinely hard to do manually, and directly relevant to the related-party search in our post on related party transactions.

Unstructured text. Reviewing email, chat, and document collections for language patterns worth a human look — useful in investigations where the volume is otherwise unreadable.

Document anomaly detection. Identifying altered or fabricated invoices and statements from formatting, metadata, and internal inconsistency.

Segmentation and peer comparison. Establishing what normal looks like for this cost centre, employee, or vendor rather than for the population — which materially improves on a single population-wide threshold.

Structured coverage sits in the AI courses for accountants and CPAs catalog, the AI for Accountants Certificate Program, and the AI Applications for Accountants program.

What It Does Badly

Off-book schemes. The decisive limitation. A model can only analyze data that exists, and per our post on embezzlement techniques, skimming — money taken before it is ever recorded — leaves no trace in the data. No model finds what was never entered. Those schemes are found by comparing records to something outside them.

Small populations. Statistical methods need volume. A company with modest transaction counts gets nothing useful from anomaly detection that a set of well-designed rules would not give it more cheaply and more explainably.

Novel schemes, per the label problem.

Establishing that anything happened. Which brings us to the central point.

A Score Is Not Evidence

The framing that keeps a firm out of trouble.

Machine learning changes where you look. It does not establish that anything occurred. The evidence still comes from the forensic work — the documents, the reconciliations, the vendor verification, the chain of custody, the interviews conducted properly — described in our post on investigating embezzlement.

Two operational rules follow:

Never confront or accuse on the basis of a score. Apart from the obvious unfairness, an accusation you cannot explain is an employment law problem, and "the system flagged you" is not an allegation anyone can answer.

Require explainability. An investigator needs to know why an item was flagged in order to investigate it — which features drove the score, and what the comparison population was. A model that produces a number with no reason attached generates work nobody can perform. Where a firm must choose, a slightly less accurate model that explains itself is more useful than an opaque one that scores better.

Tuning Is the Whole Job

Deployment is not the milestone; the queue is.

Measure the alert volume against the review capacity you actually have. A system generating more alerts than the team can clear is a system that will be ignored — and, worse, one that creates a documented record of unexamined alerts.

Measure the confirmed-case rate, and track it over time.

Feed dispositions back. Every investigated alert — confirmed or cleared — is a label, and capturing dispositions systematically is how a deployment improves. Most organizations do not do this, which is why their models never get better.

Tune the threshold deliberately and record why. This is a business decision about the tradeoff between missed cases and wasted review time, and it should be made by someone accountable rather than left at a vendor default.

Review the features periodically, since business changes make yesterday's normal today's anomaly.

The same exception-disposition discipline applies here as in our post on audit analytics: detection is cheap and disposition is the constraint.

Governance, Privacy, and the Employee Question

Three items that belong in the decision, not in the aftermath.

Employee monitoring has legal limits. Analyzing employee communications, behaviour, and personal patterns engages privacy law, employment law, notice requirements, and — in some jurisdictions — consultation obligations. These vary substantially, and a monitoring programme designed without that analysis is a legal exposure regardless of what it finds.

Fair treatment. A model trained on historical investigations can reproduce whatever bias existed in who was previously investigated. A system that disproportionately flags a group needs examining, both because it is wrong and because it is indefensible if challenged.

Independence. Designing or implementing a client's fraud monitoring is a non-attest service requiring evaluation for an attest client, per our post on independence and non-attest services. A client who asks the audit team to build what the audit team recommended needs that analysis first.

And the data-handling question from our post on technology policy: a monitoring deployment concentrates the client's most sensitive data in one place.

Reading a Vendor's Claims

Questions that separate capability from marketing:

Supervised or unsupervised? If supervised, trained on whose labeled data, and is it representative of our transactions?

What alert volume should we expect at our transaction count, and what does the review workload look like?

Can it explain a score in terms an investigator can act on?

How does it handle our exceptions — the legitimate unusual things we do routinely?

What does implementation require from us — which data, in what form, at what frequency?

Who has established that this works on populations like ours, and can we run it against a period where we know what happened?

That last one is the strongest test available: run it retrospectively against a period containing a known case. A system that cannot find something you already found is not going to find something you have not.

And the Uncomfortable Comparison

Worth ending on, because it calibrates the investment.

Across the evidence on how occupational fraud is actually discovered, tips consistently rank as the leading detection method — from employees, vendors, and customers. Not analytics, not audit, not models.

Which suggests an unglamorous prioritization for a client with a limited budget: a functioning, well-publicized, genuinely anonymous reporting channel, with a policy of no retaliation, may detect more fraud than a monitoring deployment — and it costs a fraction of it.

Paired with the two structural controls from our post on embezzlement prevention — mandatory time away with duties actually performed by someone else, and someone other than the preparer opening the bank statement — that is where the first dollar should go.

Machine learning is the right investment at volumes where human coverage is impossible. It is rarely the right first investment, and a CPA advising a client should say so.

Where These Deployments Fail

• Ignoring the base rate, and expecting most flags to be fraud
• Expecting supervised performance without enough labeled cases to train it
• Not recognizing that unsupervised detection finds unusual, not wrong
• Training on caught fraud, so the model reproduces existing detection capability
• No allowance for adversary adaptation, which degrades performance deliberately
• Alert volume exceeding review capacity, producing a record of unexamined alerts
• Dispositions never fed back, so the model never improves
• Thresholds left at vendor defaults, with no accountable decision
• An unexplainable score that an investigator cannot act on
• Confronting an employee on the basis of a score
• Treating a score as evidence rather than as direction for forensic work
• Deploying against off-book schemes, which leave no data to analyze
• Applying statistical methods to small populations where rules would work better
• Employee monitoring designed without the privacy and employment analysis
• Bias in historical investigations reproduced by the model
• Independence unevaluated when building an attest client's monitoring
• Buying a model before installing a hotline, which detects more for less

The summary for a CPA advising on this: the base rate means most alerts will be legitimate no matter how good the model is, so ask what the queue looks like and who will work it before asking about accuracy. Insist on explainability, test the system retrospectively against a case you already know about, and remember that a score directs attention rather than proving anything — the evidence still comes from the forensic work.

Frequently Asked Questions

Why do most fraud alerts turn out to be legitimate?

Because fraud is rare. When the underlying rate is very low, even a highly accurate model produces a queue in which honest transactions outnumber fraudulent ones — there are so overwhelmingly more honest transactions to misfire on. The practical question is therefore never whether the model is accurate but whether the queue it produces can be worked.

Can most organizations use supervised machine learning for fraud?

Usually not. Supervised learning needs labeled examples of known fraud and known legitimate activity, and almost no organization has enough — fraud is rare, most is never detected, and detected cases are few. What most can deploy is unsupervised anomaly detection, which identifies unusual activity rather than wrong activity.

What is the problem with training on past fraud cases?

The labels are the frauds you caught, which is a sample biased toward whatever your existing controls are already good at finding. So the model tends to reproduce your current detection capability rather than extend it, and novel schemes or schemes your controls are blind to remain under-detected. The adversary also adapts deliberately once patterns are known.

What does machine learning do genuinely well here?

Entity resolution — matching records across spelling variants, transposed digits, and partial addresses, which makes a vendor-master-to-employee-master comparison far more effective than exact matching. Also continuous scoring at volumes no human review can cover, relationship detection across shared addresses and accounts, unstructured text review, document anomaly detection, and peer comparison within a segment rather than across the whole population.

Can a model detect skimming?

No. Skimming takes money before it is ever recorded, so it leaves no trace in the data, and a model can only analyze what exists. Off-book schemes are found by comparing records to something outside them — shipping records, inventory, register tapes, deposit composition, customer complaints, and margin trends.

What should a client with a limited budget buy first?

A functioning, well-publicized, genuinely anonymous reporting channel with a no-retaliation policy — because tips consistently rank as the leading way occupational fraud is actually discovered, ahead of analytics and audit, and it costs a fraction of a monitoring deployment. Pair it with mandatory time away where duties are actually performed by someone else, and with someone other than the preparer opening the bank statement.