It doesn’t matter how good that system was overall. It doesn’t matter that it caught real problems before. The moment a wrong accusation lands on a real person, the tool is finished in that pharmacy. Not paused. Not “let’s fix it and try again.” Finished. And that’s understandable. Nobody wants to keep using a system that made them wrongly accuse someone they trust.
That’s why, when you’re building any kind of fraud detection system or anomaly detection system that watches for theft or unusual activity, the most important question isn’t “how accurate is it overall?” It’s this: how many wrong alerts, even just one, is this business willing to live with before it stops trusting the system completely?

Why This Isn’t Really a Tech Problem

It’s tempting to treat “how often is it wrong?” as something you can just adjust, like a dial you turn until the numbers look good on paper. But the real limit here isn’t technical. It’s human.
A wrong prediction from most tools just means a bad suggestion. A wrong theft alert costs someone their reputation, at the very least, and possibly their job, in a situation where the person being accused has no power to push back. That’s a completely different level of risk. It means the acceptable number of mistakes isn’t simply about what is technically possible. It’s about what a relationship between an owner and their staff can actually survive.
And usually, that number is very close to zero. Not because zero mistakes are realistic, but because being wrong about a person, in front of others, is something people simply won’t tolerate more than once or twice. You’re not really designing against a test score. You’re designing against how a real person feels the moment they’re wrongly blamed.
That changes what the system should do with an alert.

What This Means in Practice

Once you take that seriously, it changes how the whole thing should work, not just the numbers behind it.
A flag doesn’t have to mean an accusation. It can just mean, “This is worth a quiet look,” sent privately to the owner, with enough detail that they can check it out before anyone confronts anyone. The system’s job becomes helping the owner pay attention to the right place, not delivering a verdict. That one shift, from “you’re being accused” to “this might be worth checking,” does far more for whether people actually trust and use the tool than any amount of extra accuracy.
For example, an anomaly detection system in a pharmacy might flag unusual stock adjustments, repeated cancellations, unexpected discounts or a sudden change in transaction patterns. Those patterns may be worth investigating. But unusual does not automatically mean fraudulent. The system has identified a pattern. It has not established intent.
It also means trust should be built slowly. Early on, alerts can be framed gently, as patterns worth a second look rather than conclusions. As the owner sees the system being right a few times, quietly, they’ll naturally start trusting it more. That gradual trust matters more than getting everything perfect on day one.
And it means this question should be asked before any building even starts. If nobody can tell you how many wrong alerts a pharmacy can handle before they simply turn the whole thing off, you don’t yet know what you’re allowed to build.

The Real Lesson

Any system that watches for unusual activity, in any business where people’s jobs and relationships are on the line, hides this same question underneath everything else. What looks like a technical decision is really a decision about how much trust you’re allowed to risk, and how carefully that trust needs to be protected once it’s there.
The goal of a fraud detection system isn’t simply to catch more problems. It is to help people notice the right problems without turning uncertainty into accusation.
That means accuracy matters, but so do false positives, alert thresholds, context and human oversight. Most importantly, it means remembering that an anomaly is not proof of wrongdoing. A flag is not a verdict.
So before you build the model, choose the alert threshold or automate the response, ask the question that matters most: How many times can we be wrong before people stop trusting us?
Get that answer before anything else. Everything after that is the easy part.