If you ask any member of the compliance team what takes up their time during the week, the answer will be essentially the same: they have to deal with alerts that turn out to be false. Hence, at a certain stage someone puts forward the simple solution. The rules for matching should be made more strict, the thresholds raised, and the system made more selective.
It never really works; when you make the rules more strict the number of alerts decreases a bit, perhaps by ten or fifteen per cent, but the amount of noise among them doesn’t change at all. The same 95% consisting of nothing now applies to a slightly smaller group of alerts, and your team is still overwhelmed, merely in a slightly less deep pool. In fact, among the alerts that you have stopped sending there was one that was important, and you won’t know which one it was until it has become a problem.
The false-positive burden is huge; in the industry the proportion of screening alerts that are false positives ranges from 85 to 95 per cent, which means that the vast majority of the work carried out by your analysts results in no actual risk findings. There is a real cost involved since a single institution can spend tens of millions of dollars each year dealing with alerts that would never have been anything at all and can as a result exhaust the team responsible for doing so.
The aspect that alters the way you should consider it is this: the reason you’re drowning isn’t because you’re looking at too many things; it is because most of your alerts are context-blind name matches, and the idea of curing that by reducing the sensitivity is quite the opposite. False positives aren’t a matter of volume; they’re a matter of context. After you see it in that way, the solution ceases to be “look at less” and becomes “look smarter.”
Why you have so many false positives
False positives are not due to bad luck by chance; rather, they result from a small number of specific and predictable reasons, most of which stem from the way traditional screening matches names.
A system which checks a name against a list and nothing more will pick up every individual who has the same surname as someone who has been sanctioned. It will include the other forty people named Mohamed Ali. It will pick up different spellings of the same name, since one name can be written in a dozen ways. It acts on insufficient data, flagging people based only on a partial name with no date of birth or country available to exclude anyone. It also reflags items that you have already cleared last month, since the system has no memory of the review you carried out recently. This behaviour is not a fault; it is a system carrying out the only function it is capable of, which is to match strings, without having any of the kind of context that a human would use to dismiss the match in a matter of seconds.
That is exactly the reason. The system is right in displaying them because it cannot distinguish between a genuine match and a coincidence, so it gives all such matches to you and leaves it to you to sort them out. When you consider the number of sanctions lists, PEP databases, and adverse-media feeds each carrying out their own matching, the duplication increases accordingly, so that the same innocent customer can appear in three places at the same time.
The real cost of alert fatigue
The obvious expense of all this noise is time and money—specifically, the time spent by analysts, the number of staff members that have had to be hired just to keep up with the volume of the queue, and the onboarding process which comes to a standstill while a genuine customer waits behind hundreds of false hits. This is the aspect that everyone takes into account, and it is always regarded as the number-one operational problem in compliance, the factor that gradually causes staff turnover on teams which have taken years to build.
The impact that noise has on detection is never shown on a dashboard. The analyst who deals with the two-hundredth false positive during the day is a different person from the one who handled the first. Clearing alerts becomes a reflex since in ninety-nine out of every hundred cases clearing is the correct action. The problem is with the hundredth instance, the genuine one, which ends up being dismissed in the same worn-out manner as all the others. Alert fatigue doesn’t merely slow down the team; it gradually teaches them to overlook things, which is precisely the opposite of the purpose for which the alerts were intended.
The tuning trap
This leads us once again to the simple solution and the reason why it doesn’t work. If a large number of alerts accumulate, the usual response is to make the rules stricter so that fewer things set them off. The problem is that you’re only adjusting one control, with false positives on one side and missed matches on the other. If you turn it down far enough to actually reduce the noise significantly, you also begin to suppress genuine hits as well, since the system can’t become more precise, it can only become less sensitive.
Increasing the thresholds doesn’t get rid of noise; instead, it exchanges noise for blind spots. You may feel a bit less overwhelmed, but at the same time you become quietly less safe, and that is one of the worst possible combinations in a regulated system. We set out the more thorough version of this argument in The Coverage Fallacy: so long as the only thing your system does is match, coverage and noise are governed by the same lever.
The only fair conclusion is that it’s impossible to get rid of a false-positive problem which has been caused by tuning; what is needed is for the system to behave in a different way.
False positives are a context problem
If you observe a person dealing with a false positive, you’ll notice how they deal with it. They don’t waste a lot of time about it; instead, they look at the alert and consider possibilities such as the wrong date of birth or the wrong country, or perhaps it’s a company and we’re dealing with an individual, or maybe we cleared that exact name last week, or perhaps the article is actually positive. Within a few seconds, by using the context, they realise it’s nothing.
All of those judgments were based on the context that the matching system had and had ignored. If the system is given the same context—including secondary identifiers such as date of birth and address, jurisdiction, entity relationships, and a memory of what has already been examined—then the noise disappears, since the system is then able to do what the analyst does: eliminate possibilities.
Now this point should put the major concern among the attendees to rest. Implementing this approach doesn’t involve taking on greater risk. A 2025 Federal Reserve working paper compared context-aware matching with traditional fuzzy matching when carrying out a sanctions-screening task and discovered that it reduced false positives by approximately 92% while increasing the number of detections by about 11%. It achieves both less noise and more genuine matches at the same time. The compromise that people assume—that having fewer false positives must mean more misses—is in fact a shortcoming of crude matching, not a rule of nature. This changes the entire nature of the project. You’re not aiming to reduce the number of cases you have to look at. What you’re trying to do is give the machine enough judgment so that it can handle the straightforward cases and thus ensure that people only ever have to deal with the difficult ones.
How to actually cut the noise
What then is the solution if tuning isn’t the answer? In practice, reducing false positives involves providing the system with context and memory. The key actions are:
- Identify someone by using their secondary identifiers and match on the date of birth, address, jurisdiction, and full name as opposed to a nickname, not just the name string, in such a way that having the same surname is no longer sufficient to constitute a match.
- Instead, use the relevant context rather than matching a single name against a list. Take account of the relationships between entities and of the surrounding facts so that the system can distinguish a plausible match from one that is merely coincidental.
- Remove the obviously non-risk cases; positive news, clearly irrelevant entries, and incorrect entity matches should be automatically discarded, not sent for human review.
- Think back to what you have already looked at. The continuous monitoring should identify genuinely new developments, not trigger warnings for events which were previously cleared in the last cycle. It is a significant source of noise to have to go through the entire book from scratch every month.
- Arrange them according to materiality. Assign alert scores based on both risk and severity so that your team focuses on the cases which really do require a decision, rather than having to follow the arbitrary order of the queue.
- Make sure that each clearance is linked to its source and is logged. If an alert is automatically cleared then the reason for this and the evidence supporting it should be recorded, since this will make your records more auditable rather than less.
This has nothing to do with looking at fewer things; each of these cases involves the system taking over a greater amount of the judgment that a human would previously have carried out by hand. The overall effect is not incremental; when you stack these measures one on top of another the queue which once held thousands now holds only a few, even though the detection net remains the same in size.
Cutting noise is not cutting corners
With regard to a compliance audience, the natural concern is the examination—will a regulator take a lower alert volume as proof that you aren’t looking closely enough? In fact, the opposite is the case if the situation is managed properly.
For years regulators have been advocating effectiveness rather than simply increasing the volume of activity. A risk-based approach, as intended by the FATF standards, means focusing efforts on the areas that present the greatest risk rather than producing the largest number of alerts. The FCA has on several occasions criticised transaction-monitoring systems which generate a large number of alerts but catch very few. Enforcement agencies such as OFAC fine companies for ineffective screening and for failing to identify what they ought to have caught, not for having a clean queue of alerts. A programme which reduces noise while improving the rate of detection and which records all clearances together with the evidence is more defensible than one in which real risk is hidden beneath hundreds of thousands of false alarms. What an examiner would prefer to see is a smaller number of better alerts, each with a clear explanation. The audit trail is in fact the key point: a clearance that includes a documented reason and a reference to the evidence is a defensible decision, while a silently suppressed alert is just a gap that someone will eventually have to account for.
Know your number
Since you can’t manage what you don’t measure, it’s important to assign numerical values to the situation both before and after the change. Keep a record of your true-positive rate, that is, the proportion of alerts that turn out to be genuine; your alert-to-investigation ratio; and the average amount of time your team takes on each alert. If more than 90% of the alerts are being cleared as false and each one is taking several minutes to deal with, then this figure is the one you should be focusing on, and the fact that it decreases is how you can show that the programme has improved rather than simply becoming less active. The aim has never been to achieve zero alerts, something which could be done by turning the system off. It’s a queue in which most of the items that arrive actually do need a human to look at them. A healthy queue is not empty; it should be small and mostly correct, and when it is small and mostly correct, your most capable people stop dealing with the noise and begin to carry out the work for which you employed them.
Look smarter, not less
Teams which manage to avoid the false-positive trap don’t achieve this by looking at fewer alerts; instead, they provide the system with the necessary context so that it can eliminate the noise on its own, allowing humans to focus on the small number of genuine cases. The entire aim of removing the noise is to change the team’s role from one that deals with alerts to one that investigates risks.
That is the way in which Beady is designed. It eliminates about 95% of the noise before it gets to your team—such as matches involving the wrong person, stale re-alerts, positive news, and duplicates—by means of entity resolution and context, rather than relying on crude thresholds. The result is a concise list of signals that really deserve to be examined, and each one is linked back to its original source so that your team can verify them and an auditor can see precisely why a signal was raised or cleared. All the adverse media, sanctions, and legal records are brought together in one place, thus reducing the noise while retaining the evidence.
If you want to find out how much of your present alert volume consists of noise, go ahead and book a demo so that we can run the analysis on your own screening.
