Adverse media search string: why one English string misses the story

An adverse media search string is the query an analyst types into a search engine or news database: the customer's name, combined with keywords for the crimes the bank screens for, such as fraud, bribery or money laundering. A good one names the crimes rather than their stages, splits exact phrases from partial matches, and is saved and versioned like any other control. The trouble is that a single string is also a policy decision in disguise. It fixes which crimes are looked for, in which language, under which form of the name, and a customer whose bad news appears in Portuguese under an initial is invisible to an English string built on the full legal name. Botminds' Adverse Media Screening replaces the single string with a search plan built from the customer's file: every form of the name, every language the customer is tied to, and the bank's risk terms for each category in each of them.

The examples come from a fictional sample bank as it runs through the solution, Corvane National Bank, and one EDD refresh for a director of a high-risk commercial client, Rafael Monteiro Duarte. The customer, his companies and the articles are invented; the guidance cited is real.

What is a good adverse media search string?

A good adverse media search string is one the bank could defend: built from a written list of risk terms, run under every form of the customer's name, in the languages that customer's news would appear in, with the same settings every time. There is no standard one. The Wolfsberg Group, a standards body formed by global banks, says "There is no universally defined search string or globally agreed approach to defining Internet search key words", and that "Search strings should be agreed internally and aligned to each FI's risk appetite" (Wolfsberg Group, Negative News Screening FAQs, 2022).

That second sentence is the important one. A string is not a clerical detail an analyst improvises; it is where the bank's risk appetite becomes a search. Which crimes, which words, which language, which name: change any one and the bank has changed what it can find, usually without anyone approving the change.

What keywords should a negative news search use?

Use words that name the crime, chosen per category and translated per language, and keep words that name a stage out of the base string. Wolfsberg is specific: "Use of generic words, which refer to stages of a crime rather than crime itself, will affect the volume of alerts generated", and its examples of such words are "'arrested', 'charges', 'investigation', 'alleged', 'probe', 'guilty'". It suggests "more precise terms when referring to type of the wrongdoing", such as bribe, terrorism, fraud or theft.

The reason is arithmetic. "Arrested" matches every arrest a namesake ever made; "bid rigging" matches only stories about a crime the bank screens for. The stage is still needed, but it belongs in the reading, where the analyst decides whether a story is an allegation or a conviction, not in the search, where it only multiplies results.

Translation is where most lists go wrong. Wolfsberg warns that "Where FIs conduct multi language screening it is important to ensure that key words are translated correctly", and the risk is not mistranslation so much as literal translation. The English "bid rigging" becomes, in the sample's Brazilian report, a story about a tender, licitação, that was steered, direcionamento. A list translated word for word from English would look for the wrong noun.

Does a Google search string work in other languages?

No. An English string finds English articles, and a story published in Portuguese, Spanish or Polish about the same customer may never contain an English word the string asks for. Search engines also make the result unstable: Wolfsberg notes that "screening results may differ with each search, even if conducted using the same phrase or key words, depending on timing", and that results "can vary greatly across different users" because the engines filter content "to match individual browsing preferences".

The language a search needs is a property of the customer, not of the bank. Wolfsberg says "The search string language may therefore depend on the jurisdiction where screening is conducted, customer location, or other relevant factors". For the sample customer those factors are on file: he is a Brazilian as well as a US citizen, he directs a subsidiary in Goiânia, and his company sent 41 wires to Brazil this year and 14 to a supplier in Monterrey. Portuguese and Spanish are not options for his search; they are where his news would be.

How do I search transliterated names?

List the forms before you search: the full legal name, initials, the name without a second family name, the order a registry uses, and the forms a transliteration or transcription produces, and run the risk terms against each. Wolfsberg distinguishes three processes: transliteration ("歌川豊春 <> Utagawa Toyoharu"), transcription ("Piotr Czajkowski <> Pyotr Tchaikovsky <> Piotr Chaykovskiy") and translation, the rendering of meaning.

The problem is old and well documented in list screening, which makes it a useful warning. FATF's guidance on politically exposed persons says "Inconsistent transliterations and spellings of names affect the ability of financial institutions and DNFBPs to match names in general" (FATF, PEP guidance, 2013). OFAC's compliance framework lists, among root causes of sanctions violations, screening that missed other spellings of sanctioned places and parties, with the Spanish, German and French forms of Havana, Cuba and Sudan as its examples (OFAC, A Framework for OFAC Compliance Commitments, 2019). In a UK case penalised in 2025, a designated person opened an account with a passport name a few letters away from the listed one, two edits in the forename, one in the surname and a dropped middle name, and the bank's screening never connected the two (OFSI, Bank of Scotland; how list screening plants such cases in its tests is in sanctions screening testing). A news search string has the same blind spot, with no list entry to fall back on.

Those are sanctions cases, where the list holds the spelling. In news there is no list: each journalist chooses a form, and naming customs with two family names make the choice wide. That is why the sample plan searches six forms, and why the two forms that found nothing stay in the plan: an empty result is evidence that the form was searched.

How many results is too many?

There is no number; results are too many when copies and namesakes crowd out the reading. The answer is rarely a narrower string. Adding a city or a date of birth to the query removes the namesakes, but it also removes every article that did not print them, and the article about the customer may be one of those.

Wolfsberg describes the trade-off as a choice between exact and partial matching: "certain phrases should then be screened on an exact match basis to minimise the volume of irrelevant results", while "other phrases may be searched on a partial match basis in order to maximise the opportunity to capture risk-relevant content." A string that is too long for the engine should be split, since "the length of a search string should be reasonably shorter than the search engine word allowance", with "supplemental search strings" for the rest.

The better approach is to search wide and filter after, with tests that leave evidence. The sample search returned 37 articles; 33 were copies and follow-ups that grouped into 4 stories, and identity tests on each story set aside two about other men. A wider search produced more reading for the agents, and less for the analyst.

Should I use the same string for every customer?

Use the same categories and terms for every customer in a risk segment, and a different plan for each: the name forms and languages come from the customer's own file. A US retail customer with no ties abroad may need one language and two forms; a director with a foreign citizenship, a subsidiary and cross-border payments needs more. Applying one string to both under-searches the second and documents the same blind spot for every customer like him.

The search plan in Adverse Media Screening: one customer, six names, three languages

A search plan is a string written for one customer, from that customer's file, and kept with the review. The sample plan below is what replaced the single string on the Duarte review.

The search plan: six names, three languages and the reason for each

In the solution, the Search agent builds that plan for each review from the client lifecycle system: names from the customer's file, languages from citizenship, addresses, subsidiaries and payment countries, plus English. It searches only the bank's approved sources and stays within the look-back the bank set. The plan sits on the review, so the question an examiner asks first, what exactly did you search, has its answer on one screen.

What a search string cannot do

A search string finds candidates; it cannot tell which are about the customer, which are copies, which are harmless, or how far a story has gone. Wolfsberg is blunt about the limit of searching the open internet: banks "have no visibility nor oversight of Internet-based, publicly available content, therefore it cannot be easily determined whether the results presented are the most accurate, relevant, appropriate, or complete." Publishers can remove or change content at any time, and in some countries data protection law lets people have unfavourable reports taken down.

Everything after the search is reading, and the string decides how much of it there is and in which languages. That is the real cost of a bad string: not the missed article alone, but a file that says the customer was searched when one form, in one language, was. What happens to the results next, deciding whether a hit is the customer, is the other half of the work, and the difference between a search tool that returns articles and one that returns a decided review is set out in adverse media API, search engine or agents. To see the search plan built for each review, start from Adverse Media Screening.

Questions people ask

What is an adverse media Google search string?

It is a query that pairs a customer's name, in quotes, with risk keywords joined by OR, typed into a general search engine. It is free and fast, but its results depend on the engine's ranking, the date and the user, so the settings, date and result count should be saved with the review.

Should a search string include the customer's city or date of birth?

Usually not. Many articles print neither, and adding them to the query removes those articles before anyone has read them. Search wide on the name forms and crime terms, then use the city, age and occupation in each story to rule namesakes in or out.

How long can an adverse media search string be?

As long as the engine allows, with room to spare: Wolfsberg asks that a string stay well inside the engine's word allowance, with supplemental strings when the terms do not fit. Splitting by category, with one string per crime group, also makes the results easier to read.

Do I need to search in the customer's native script?

Where local media publishes in a non-Latin script, a Latin-only search may miss it. Wolfsberg notes that "For many markets, minimum standards are to screen the customer names against the media source names in Latin character sets", but asks banks to consider whether their tools support native scripts and transliteration where the risk calls for it.

How often should search strings be reviewed?

At least when the policy is reviewed, and whenever a category, language or source changes. Wolfsberg asks for procedures that are "subject to a risk-based periodic review", and a term list is part of the procedure. Each change should carry a version, so a review can be read against the list it used.