Disclaimer: This article is for education and for lawful, authorised professional research. Use these methods only where you have a legitimate purpose and a lawful basis, and follow the laws and platform terms that apply to you, including data protection law such as the UK GDPR and EU GDPR. See our Terms of Service.
TL;DR
- Most hits in adverse media screening are false positives because the screening matches names, and names are not unique. Fuzzy matching makes the problem worse, not better.
- The fix is disambiguation: compare identifiers you lawfully hold (age, company number, domain, email, username, occupation, place) against what the article actually says.
- Well-built search strings cut noise before it reaches an analyst. We share Boolean and news API examples you can adapt.
- Regulators expect you to discount matches for reasons, not by habit. A short written note per discounted hit is the difference between a defensible file and a finding.
- UserSearch helps confirm or rule out identifiers across Username, Email, Corporate and Domain Intelligence from one account, with the record kept in a Case.
Why Do Name-Only Adverse Media Hits Swamp AML Teams?
Adverse media screening is the search of public news and web sources for credible information that could change a customer's risk rating, and most of its hits are false positives because screening matches names. Ask any AML analyst what takes up their week and adverse media will be near the top. A customer called Jon Example is onboarded, the screening tool runs his name against news sources, and forty articles come back. One is about a Jon Example who was fined for dumping waste in 2014. One is about a footballer. Two are about a Jon Example who was harmed by an offence, not accused of one. The rest mention the name in a list of charity runners. The analyst reads them all, decides none is the customer, clicks "discount", and moves on.
Multiply that by a few hundred customers a week and two things happen. Analysts start discounting on instinct, because nearly everything is noise. And the rare true match, the one article that really is about your customer, gets discounted along with the rest.
This guide is about breaking that cycle. It covers why name matching produces so much noise, the search strings that reduce it at source, the identifiers that let you confirm or rule out a match, and how to write down a discount decision so it stands up when a regulator or auditor reads it.
What Is Adverse Media Screening For?
Adverse media screening (also called negative news screening) means searching public news and web sources for information that could change a customer's risk rating: allegations or findings of financial crime, bribery and corruption, sanctions issues, serious regulatory action, tax offences, organised crime links and similar. It sits inside customer due diligence rather than beside it.
The international baseline is the FATF Recommendations, which require a risk-based approach and customer due diligence (Recommendation 10) proportionate to risk. In the UK, the Money Laundering Regulations 2017 set out customer due diligence in regulation 28 and enhanced due diligence in regulation 33, which lists risk factors that include the customer's circumstances and reputation. Adverse media is one of the main ways firms learn about those factors.
Two points are easy to lose. First, adverse media is about credible information, not proof. A well-sourced report of a regulator's action matters even before any outcome. Second, it is about your customer. An article that is credible but about someone else is not adverse media for your file, however alarming it reads.
What the FCA Expects When Press Reports Pile Up
The FCA's Financial Crime Guide, section 3.2, sets out good and poor practice for customer due diligence. It lists press reports among the good sources of risk information, and it names as poor practice a firm that disregards allegations about a customer from reputable sources repeated over a sustained period. It also flags relationship managers overriding customer risk scores without sufficient evidence.
That is not theoretical. In July 2025 the FCA fined Barclays £42m across two cases. In one, a customer, Stunt & Co, received £46.8m from another firm, Fowler Oldfield. The FCA found that Barclays did not properly consider the risks even after receiving information from law enforcement about both firms. The information was not buried; it was the kind of thing adverse media screening exists to surface and escalate.
The practical lesson cuts both ways. Firms get criticised for ignoring credible reports, and they drown when every name match is treated as credible. The JMLSG guidance, the industry guidance UK regulated firms rely on (last updated in 2025 and now being revised for the 2026 amendment regulations), expects a risk-based approach to both. Our anti-money laundering page explains where UserSearch fits in that workflow.
Where Do the False Positives Come From?
Understanding the causes tells you which fixes work.
- Common names. Some names are shared by thousands of people in one country. Name-only screening cannot separate them.
- Transliteration and spelling. Names from Arabic, Cyrillic, Chinese and other scripts have many valid Latin spellings. Screening tools use fuzzy matching to catch them, which also catches everyone with a similar name.
- Role confusion. News articles name victims, witnesses, judges, lawyers, reporters and people quoted in passing. Keyword proximity does not tell you who did what.
- Company name overlap. "Example Logistics Ltd" in the UK and "Example Logistics LLC" in another country can be completely unrelated.
- Stale and syndicated stories. One 2012 wire story republished on 30 sites becomes 30 hits.
Fuzzy matching deserves a closer look, because it is where most tools add noise. The open-source jellyfish library (pip install jellyfish, no API key) shows the problem in a few lines:
import jellyfish
pairs = [("Mohammed Example", "Muhammad Example"),
("Example Logistics Ltd", "Example Logistic LLC"),
("Example Logistics Ltd", "Sample Logistics Ltd")]
for a, b in pairs:
print(a, "|", b, round(jellyfish.jaro_winkler_similarity(a.lower(), b.lower()), 2))This prints 0.88, 0.95 and 0.92. The first pair is the same name spelt two ways; the third pair is two different companies, and it scores higher. jaro_winkler_similarity rewards shared prefixes and characters, which is why it is good at catching spelling variants and bad at telling different entities apart. A screening threshold set at 0.85 will match all three. That is why the fix has to come from identifiers, not a better similarity score.
Building Search Strings That Cut Noise at Source
Before any identifier work, improve what you search for. Most noise can be removed by the query itself.
Start with a name set, not a name
List every form of the name you hold: full legal name, known aliases, former names, transliterations, and for companies previous names, trading names and the company number. Search them together:
("Jon Example" OR "Jonathan Example" OR "J. Example") ("Example Holdings" OR "Examplefield")Pairing the person with a company, town or profession they are known for is the single most effective noise filter. It will miss articles that name only the person, so run a broader pass as well for higher-risk customers.
Add risk terms with Boolean operators
"Example Holdings" (fraud OR bribery OR corruption OR "money laundering" OR sanctions OR penalty OR disqualified)Quotation marks force the exact phrase. OR must be in capitals for Google to treat it as an operator. The brackets group the risk terms so every one is paired with the name. Keep the list short enough to read; very long OR chains get truncated by some engines.
Remove the customer's own noise and set a date window
"Example Holdings" (sanctions OR penalty) -site:exampleholdings.example.com after:2020-01-01-site: removes the customer's own pages. after: and before: are documented on Google's refine web searches help page and limit results by date. Date filters rely on the date a page reports for itself, so treat them as rough.
Use a news API for volume
For repeatable screening across many names, a news API beats a search box. The free GDELT DOC 2.0 API searches worldwide online news over a rolling three-month window and supports proximity and language operators:
curl -s "https://api.gdeltproject.org/api/v2/doc/doc?query=%22Example%20Holdings%22%20(bribery%20OR%20sanctions)%20sourcelang:english&mode=artlist&maxrecords=75&format=json×pan=3m"mode=artlist returns a list of articles, maxrecords caps it (250 at most), timespan=3m covers the full window and sourcelang: restricts language. The near20: operator requires two words within 20 words of each other, which is useful for tying a name to a risk term. No API key is needed, but GDELT enforces a limit of roughly one request every five seconds and returns an error if you exceed it, so pause between names. The three-month window means it complements, rather than replaces, archive searches.
Disambiguating a Hit With Identifiers
Once a hit survives the query, test it against identifiers. The principle is simple: a true match must be consistent with everything you know, and a single hard contradiction is usually enough to discount.
| Identifier | Where you hold it | What to compare in the article |
|---|---|---|
| Company number | Onboarding documents, registry | Company named, jurisdiction, registered number if quoted |
| Domain | Website, email address | Website or email named in the article or linked source documents |
| Email address | Onboarding contact details | Addresses quoted in regulator notices or reports |
| Username or handle | Provided accounts, company social pages | Accounts quoted or embedded in the article |
| Occupation and employer | CDD questionnaire, registry appointments | Job or role given in the article |
| Place | Address, nationality | Town, country, tribunal or regulator jurisdiction |
For UK directors, the Companies House register shows partial birth details, which compliance teams use to rule a match in or out.
For companies, the company number and domain are decisive. If an article about "Example Logistics" links to a regulator notice naming a different registered number, the match is gone. If it names your customer's domain, the match is very likely real.
Weak identifiers (same town, similar occupation) can support a match but should not confirm one on their own. We use a simple rule: discount on one hard contradiction; confirm only on two independent hard matches; escalate everything in between.
Documenting a Discounted Match
A discount decision is only as good as its note. "Not our customer" tells a reviewer nothing. A good note names the identifiers compared and the result, so another analyst would reach the same conclusion. We use this structure:
HIT-REF: AM-2026-0913-04
CUSTOMER: Jon Example (CUST-55120), Leeds, software developer
SOURCE: Regional news site, published 2016-05-12
ARTICLE SAYS: "Jon Example of Bristol", director of company 07654321,
named in a regulator's notice on waste permits
COMPARISON: Company 07654321: customer holds no appointment there
on Companies House (hard contradiction)
Place Bristol vs Leeds (soft contradiction)
DECISION: Discounted, different individual
ANALYST: r.patel DATE: 2026-09-24 REVIEWED: team lead (sample)Record the article itself too. Pages change and disappear; a capture with a hash and timestamp means the reviewer sees what you saw.
Two Adverse Media Cases Worked Through
A company match that turns out to be real
Context. A payments firm reviews Example Logistics Ltd, a UK freight forwarder. Screening returns an overseas news story about "Example Logistics" in connection with a customs and sanctions enquiry.
Actions. The article names a different legal form (LLC) and country, and the analyst's first instinct is to discount. But the article links to the overseas regulator's notice, which lists a website domain. It is the customer's domain. Companies House shows the UK company's director was appointed a month after the overseas notice was published, and the customer's onboarding form left the "group companies" question blank. A search of the domain in the Wayback Machine shows the site once listed both entities as one group.
Outcome. Two independent hard matches (domain and group relationship) confirm the link. The analyst escalates to the MLRO with the notice, the archive capture and the registry evidence. The customer's risk rating is raised to high and enhanced due diligence begins. A name-only discount would have missed it; the identifier check caught it in under an hour.
A common name with a noisy history
Context. A wealth manager onboards Jon Example, a software developer from Leeds, with a moderate risk rating. Screening returns 27 articles.
Actions. The analyst first reruns the search pairing the name with Leeds, his employer and his profession, which removes 19 obvious non-matches (sport, charity events, obituaries). Of the remaining eight, five name a different employer or company and are discounted with notes. Two name a Jon Example as a witness, not a party; the analyst records the role and discounts. The last article, about a director named in a regulator's notice, names the company. The analyst checks Companies House: the customer holds no appointment at that company, which is registered in another region.
Outcome. All 27 hits discounted, each with a one-line reason. Total time about 25 minutes, most of it saved by the refined search. The file shows a reviewer exactly why the customer's rating did not change.
Confirming Identifiers Faster in UserSearch
The manual method depends on moving quickly between registries, archives, search engines and platform searches for every hit. That is where time goes, and where notes get lost.
UserSearch 2.0 gives one account access to 100+ third-party data sources across 18 Search types. For adverse media disambiguation the most useful are:
- Corporate Intelligence to confirm company numbers, officers and dates of appointment behind a company match.
- Domain Intelligence for domain ownership, history and favicon data, to test whether a domain named in an article belongs to your customer.
- Email Intelligence and Username Intelligence to check whether an email address or handle quoted in a report connects to the same person or company you hold on file.
- Bulk search to run up to five inputs through one Module at once, such as the name variants in your name set.
- OneScan to run one identifier across several selected sources, merged with source attribution, with the Credit cost shown before you run it.
- Cases in Forensic Mode to keep each hit's searches and bookmarks together, and SargeBot to draft a PDF report from findings you have verified.
If username checks are new to your team, our username OSINT guide explains how to tell a real connection from a coincidence. Every result is a lead to corroborate; coverage and freshness depend on the source.
Advanced Techniques for High-Volume Screening
Collapse syndicated stories before review
Group hits by headline and first paragraph before an analyst sees them. One wire story on 30 sites is one hit to review, and the note can list the duplicates.
Screen in the customer's languages
For customers with ties to other countries, run the name set in the relevant script and language. A transliterated English search will miss most local coverage. GDELT's sourcelang: and sourcecountry: operators help for recent news.
Weight sources, not just hits
A regulator's notice, a reputable national newspaper and an unattributed blog post are not equal. Grade each source's reliability separately from how well it matches your customer, and record both. The FCA's poor-practice example is about reputable sources repeated over time, not a single unsourced post.
Revisit on trigger events
Rescreening every customer daily creates noise. Rescreen at defined points: periodic review dates by risk rating, a change of ownership or directors, a large or unusual transaction, or a new jurisdiction. Record the trigger in the file.
Screening Responsibly Under UK Law
Adverse media screening processes personal data, and much of it concerns allegations and offences, which UK GDPR Article 10 treats separately. Regulated firms usually rely on a legal obligation for CDD and on a condition in Schedule 1 to the Data Protection Act 2018, such as regulatory requirements relating to unlawful acts and dishonesty, for the offence data. Keep an appropriate policy document, keep only articles relevant to your decision, and set a retention period in line with your record-keeping obligations.
Accuracy matters as much as coverage. Do not raise a customer's risk rating on an unconfirmed name match, and do not keep an article about someone else in a customer's file. If a hit is confirmed and you have a suspicion, follow your internal reporting process to the MLRO, and do not tell the customer about any suspicion or report; tipping-off rules apply. Use only openly available sources and respect each platform's terms.
Frequently Asked Questions About Adverse Media Screening
What is adverse media screening?
Adverse media screening, also called negative news screening, means searching public news and web sources for credible information that could change a customer's risk rating, such as allegations or findings of financial crime, bribery, sanctions issues, serious regulatory action or tax offences. Adverse media screening sits inside customer due diligence rather than beside it.
Why does adverse media screening produce so many false positives?
Adverse media screening produces false positives because it matches names, and names are not unique. Common names, transliteration and spelling variants, people named in articles as witnesses or lawyers, overlapping company names and syndicated stories all create noise. Fuzzy matching makes the problem worse, because it catches spelling variants and also everyone with a similar name.
How do you rule out an adverse media match?
Compare identifiers you lawfully hold, such as company number, domain, email, username, occupation and place, against what the article actually says. A single hard contradiction, such as a regulator notice that names a different company number, is usually enough to discount. Confirm only on two independent hard matches and escalate everything in between.
How should a discounted adverse media hit be documented?
A discounted adverse media hit needs a short written note that names the identifiers compared and the result, so another analyst would reach the same conclusion. A good note records the hit reference, the customer, the source and publication date, what the article says, the comparison, the decision, the analyst and the reviewer, plus a capture of the article.
What does the FCA expect from adverse media screening?
The FCA's Financial Crime Guide lists press reports among good sources of risk information and names as poor practice a firm that disregards allegations about a customer from reputable sources repeated over a sustained period. Firms are criticised for ignoring credible reports, so adverse media matches should be discounted for recorded reasons, not by habit.
What search strings reduce noise in adverse media screening?
Start with a name set covering legal names, aliases, former names and transliterations, and pair the person with a company, town or profession. Add risk terms grouped in brackets with OR in capitals, remove the customer's own site with -site:, and set a date window with after:. For volume, the free GDELT DOC 2.0 API searches recent online news.
From Name Matches to Defensible Decisions
Adverse media screening works when the noise is removed before an analyst sees it, and when every remaining hit is judged against identifiers rather than instinct. Better search strings, a clear rule for discounting and confirming, and a short written note per hit turn a draining queue into a reliable control that stands up to a regulator's review.
UserSearch shortens the slowest part, confirming identifiers, by putting Corporate, Domain, Email and Username Intelligence behind one account with 100+ sources, OneScan with source attribution, and Cases that keep each decision's evidence together.
Stop guessing. Start researching with UserSearch. Test your next adverse media hit against real identifiers at UserSearch.