Adverse-media false positives: why they happen and how to cut them

Every compliance team has a number it does not like to say out loud: the share of adverse-media alerts that turn out to be about someone else, something old or nothing at all. The proportion depends on the source mix, customer population and matching rules. False positives are not only an efficiency problem. They train analysts to clear alerts quickly, which is exactly the habit that lets a true positive through. This post looks at where adverse-media false positives come from and what a screening engine can do about each cause without hiding real hits.

What is an adverse-media false positive?

An adverse-media false positive is a result that appears relevant to the screening subject but does not support the suspected adverse finding. It may concern a namesake, duplicate an event, describe the person as a victim, or omit later context. Confirming identity and reading the source are separate review steps.

Key takeaways

• Most false positives come from a handful of causes: common names, transliteration, syndicated copies of one story, stale or withdrawn allegations and keyword matches with no real link to the subject.
• Blunt fixes, such as raising a match threshold or filtering by keyword, cut true positives as fast as false ones.
• The durable fix is to keep the wrong-entity decision on the record, score the finding on the evidence with more than one model, and re-screen only on change.

Cause one: the name is common

Search a common name and the news returns a crowd. A “Mohammed Ali” or a “John Smith” produces thousands of articles about many different people, and a name-only match cannot tell them apart. The engine that scores each article as a hit because the name appears has done the search and skipped the work.

What helps is entity resolution before scoring: using date of birth, nationality, location, employer, role and the other identifiers you already hold to decide whether the person in the article is plausibly the person in front of you. AdverseMe drops wrong-entity candidates before the judges see a finding and, importantly, keeps the decision. The Engine Trace lists every candidate returned and every one dropped as a wrong-entity match, so “we looked and it was a different person” is a documented conclusion an auditor can check, not a silent discard.

Cause two: transliteration

Arabic, Persian, Cyrillic and Chinese names have many valid Latin spellings. A search for one spelling misses the others; a search loose enough to catch all of them also catches unrelated names that happen to share a phonetic shape. Both errors show up as false positives or, worse, false negatives that nobody sees.

The answer is transliteration-aware matching that treats variant spellings of the same name as one name, paired with scoring that looks at the evidence rather than the string. AdverseMe applies Arabic transliteration handling across its sources, including the five GCC and MENA national lists it parses daily, and then scores the result on what the article says about the person, not on how closely the spelling matched.

Cause three: one story, fifty copies

A single allegation gets syndicated, rewritten, quoted and aggregated. A naive engine reports fifty findings. The analyst clears fifty alerts about one event and, by the fortieth, is clearing on autopilot.

Deduplication has to happen at the level of the event, not the URL. A finding should represent the allegation, with the copies attached as supporting sources, so that the analyst reads it once and the report shows it once. The count of sources that carried a story is useful context; fifty separate alerts are not.

Cause four: the allegation is old, withdrawn or resolved

An article from years ago about charges that were later dropped is still an article. A screening engine that reports it at full weight every time the customer is reviewed manufactures a recurring false positive, and the analyst’s note from last year does not stop it appearing again.

Two things help. The first is scoring that weighs recency, outcome and the seriousness of the allegation rather than treating every mention as equal. AdverseMe scores each finding with four independent judges from four model families at temperature zero, with the median taken and dissent counted. A judge that reads “charges dropped” in the article and scores it low is visible next to a judge that weighted the original allegation, and the analyst sees both rationales.

The second is not re-screening what has not changed. AdverseMe’s monitoring compares sanctions-list versions and supports scheduled re-screening. Delta checks apply to changed list entries; a full re-screen can also revisit news and historical findings.

Cause five: the keyword is there, the link is not

A company named in an article as a victim of fraud, a lawyer quoted about a case, a person mentioned in the same paragraph as an arrest. Keyword-driven engines report all of these as adverse. They contain the right words and the wrong relationship.

This is the cause that most needs a model that reads. Whether the subject is the accused, the victim, a witness or a bystander is a question of meaning, and it is the question the AdverseMe judges are asked. Their rationales say which role the subject plays in the article, and a finding where the subject is not the wrongdoer scores accordingly. Because every rationale is on the record, an analyst who disagrees can say so on the evidence.

Why the blunt fixes fail

The temptation is to turn a dial. Raise the match threshold and the crowd of namesakes thins, along with the true positive whose name was misspelled in the source. Filter out a list of “noise” keywords and the victim-of-fraud articles disappear, along with the article that used the same word about your customer as the accused. Suppress anything older than five years and the historical conviction goes with the stale allegation.

Each of these lowers the alert count and each of them lowers recall in ways that nobody measures until an auditor does. The programme looks cleaner and is weaker.

A better standard

The standard worth holding an engine to is not “fewer alerts” but “every alert explained and every non-alert accounted for”. In practice that means:

• Entity resolution before scoring, with the dropped candidates kept on the record.
• One finding per event, with copies attached as sources rather than counted as separate hits.
• Scores that come from reading the article, produced by more than one model, with the reasoning visible and the disagreement reported.
• Deterministic scoring, so that the same evidence gives the same answer when a reviewer re-runs it.
• Re-screening driven by change, so resolved findings do not resurface without cause.

AdverseMe keeps the trace, the council’s reasoning and the delta re-screening on the record across its 110+ integrated sources on the coverage page. The council’s votes and reasoning are available in the app. The PDF report presents findings, source evidence, coverage, exclusions and limitations.

Measuring your own rate

If you do not know your false positive rate, sample fifty recent alerts and classify each by the five causes above. Group the results by cause to see which problems account for the most review work in your own process. Then run the same names through an engine that keeps its wrong-entity decisions on the record and compare what you can defend, not just what you can count.

Plans start on the pricing page. To run your own sample through the council and read the trace, get started.

Sources and review approach

The Wolfsberg Group Negative News Screening FAQs discuss source quality, risk categories and the design of negative-news screening. AdverseMe’s implementation is described in our methodology. The examples in this article explain review patterns; they are not measured error rates.