To start adverse media screening software, a bank brings two things: its decisions and its data. The decisions are the policy: which customers are screened and when, which crime categories and risk terms, which languages, which sources and how far back, how confident a match must be before anyone sees it, who confirms, who accepts and who approves a rating change. The data is what turns that policy into a search for one customer: names in every form, dates of birth, occupations and roles, citizenships and addresses, subsidiaries, beneficial owners and the countries the customer pays. Without both, adverse media screening software either runs its vendor's defaults or searches one English name and calls it done. Botminds' Adverse Media Screening treats every one of those decisions as a versioned setting the compliance manager owns, and builds each customer's search plan from the bank's own client data.
The examples come from a fictional sample bank as it runs through the solution, Corvane National Bank; its settings are the solution's defaults, and its customers are invented. The rules and guidance cited are real.
What to bring to adverse media screening software, and who owns it
- The screening population and occasions
Which customers, owners and directors, at onboarding, refresh, trigger and monitoring. Owner: BSA officer.
- Customer data feeds
Names and their forms, dates of birth or incorporation, occupations, roles, addresses, citizenships, subsidiaries, beneficial owners. Owner: KYC operations.
- Payment geography
The countries a customer sends to and receives from, from the bank’s own data. Owner: BSA/AML monitoring.
- Crime categories, stages and risk terms in each language
With exclusions and a version number. Owner: compliance manager.
- Approved sources and look-back
Licensed news, court and enforcement notices, and how many years back. Owner: compliance manager.
- Decision rights and clocks
Who confirms, who accepts, who approves a rating change or an exit; how many days each review may take. Owner: BSA officer.
- Thresholds and second looks
The confidence a match needs before it is proposed, and the share of empty reviews a second analyst reads. Owner: compliance manager.
- Past reviews
Open stories already on file, and a sample of closed reviews to test against. Owner: KYC quality assurance.
What do I need to start adverse media screening software?
You need the eight items above, and the most important is the one that sounds least technical: a written policy precise enough to configure. Every setting in adverse media screening software answers a policy question, and a question nobody answered gets the vendor's answer. US rules leave those answers to the bank; the FFIEC manual asks each bank to decide, on the basis of risk, when negative media searches are appropriate (FFIEC BSA/AML Examination Manual).
The Wolfsberg Group, a standards body formed by global banks, adds the governance expectation for any technology used on negative news: "it is important that FIs document all alert management solutions being used, the rationale for implementation and ensure that appropriate controls are in place to review periodically the performance of deployed applications" (Wolfsberg Group, Negative News Screening FAQs, 2022; standards guidance, not a rule). That rationale is written once, at the start, from the decisions in the checklist.
Which customer fields matter?
The fields that matter are the ones that either widen the search or test a match: every form of the name, a date of birth or incorporation, occupation and roles, addresses and citizenships, subsidiaries, beneficial owners, and the countries the customer pays. Wolfsberg lists the factors that shape screening as "the products a customer uses", "the segment to which the customer belongs" and "the geographies where the customer is based or to which they have a nexus", along with the customer's risk rating.
From the customer file to the search plan: what each field is used for
Legal name, aliases, former names, registry entries
Used forEvery form of the name searched
On the sample reviewSix forms, from “Rafael Monteiro Duarte” to “R. Duarte” and the registry order
Date of birth, or date of incorporation
Used forAge worked out on each article’s date
On the sample reviewBorn June 11, 1973: 52 on Sept 18, 2025
Occupation, employer, roles and directorships
Used forIdentity tests on every story
On the sample reviewMechanical engineer; director of the company and its Brazilian subsidiary
Citizenships, addresses, subsidiaries
Used forLanguages searched, with the reason
On the sample reviewUS and Brazilian citizen; subsidiary in Goiânia: Portuguese
Payment countries from the bank’s own data
Used forFurther languages and places to test
On the sample review41 wires to Brazil, 14 to a supplier in Monterrey: Spanish
Beneficial owners and directors of entity customers
Used forThe people screened for a company
On the sample reviewThe review of a high-risk client ran on its 30% owner and director
Two fields are often missing and cost the most when they are. Date of birth is held for individual customers but often not for the directors and owners of a business customer, and without it every namesake becomes an unsure review. Payment geography sits in the bank's payment data, not the KYC file, and it is what tells the software that a Houston engineer needs Portuguese and Spanish searches. Bringing both into the customer data before go-live is worth more than any tuning afterwards.
How do we set approved sources?
Set them as a list the compliance manager owns, with the reason each source is on it, the look-back for each, and the rule that the software searches nothing else. A licensed news service with wires and regulator releases, plus court and enforcement notices, is the usual core; the sample bank searches five approved sources over ten years, with five and seven as its other look-back settings.
Where a vendor supplies the content, the bank keeps the responsibility: the US banking agencies' third-party guidance, quoted below, is explicit that outsourcing an activity does not outsource the obligation. For a news source, that means knowing what it covers, in which languages and countries, how far back its archive goes, and how it judges reliability.
Which languages should we cover?
Cover English plus the languages of each customer's footprint, chosen per customer from the data, not a fixed list for everyone. The solution's default is exactly that, "from the customer's footprint, plus English", and its other setting is a fixed English and Spanish. A fixed list is simpler to explain and wrong for every customer whose news is in a third language.
Script matters as well as language. Wolfsberg asks banks to consider "The screening system capability to support non-Latin character sets" and "Whether the media sources and customer datasets used by the FI contain the names and Negative News in the native script of that country." A bank with customers from markets that publish in Arabic, Chinese, Cyrillic or Japanese script should ask whether its customer data holds native-script names at all; if not, the software can only transliterate, and which forms of a name get searched becomes the weak point.
What is our risk-category policy?
It is the list of crimes the bank screens for, the terms that find each in each language, the stages at which it wants to know, what it excludes, and how each category and stage moves a customer's rating. Write it as a versioned list. The sample bank's list has eleven categories; its search plan shows six of them, from corruption and bribery to regulatory action, with terms in English, Portuguese and Spanish "kept by the compliance manager".
The rating link is the part banks most often leave implicit. In the sample bank, corruption carries a weight of 23, multiplied by 0.7 for a story at the investigation stage, so a confirmed story added 16 points and moved a director's company from Elevated 62 to High 78, where High begins at 75. The audit trail records the category list version used, v7. Whatever the numbers, the approver should be able to see the arithmetic, and the model owner should be able to change it with a version and a reason.
The search plan the software built from one customer's data
Who signs, and how fast?
Decide who confirms a story, who accepts it into the customer file, who approves a rating change and who approves an exit, and how many days each kind of review may take. These are decision rights, and the FFIEC expects procedures to say who may change a customer's risk profile. Software can enforce them, which is the main reason to configure them rather than write them in a manual.
The settings a bank decides before go-live, with the solution's defaults
| Setting | Default | Options |
|---|---|---|
| Who accepts a story into the customer file | Any EDD reviewer, never the person who confirmed it | Any EDD reviewer · EDD reviewers and the compliance manager |
| Who approves a risk rating change | The compliance manager | The compliance manager · the BSA officer |
| Confidence a match needs before it is proposed | 0.85 | 0.70 to 0.95, in steps of 0.05 |
| Second look on reviews confirmed in bulk | 5% of “nothing relevant” reviews | 5% to 20%, in steps of 5 |
| Review clock, onboarding | 2 business days | 1 · 2 · 3 business days |
| Review clock, EDD refresh | 5 business days | 5 · 10 business days |
| Languages searched | From the customer’s footprint, plus English | Or English and Spanish only |
| Look back | 10 years | 5 · 7 · 10 years |
| Keep reviews and their evidence | 5 years | 5 · 7 · 10 years |
The confidence setting deserves a test before anyone picks a number. Too low and analysts see namesakes the agents should have set aside; too high and real but thinly identified stories wait as unsure reviews. Run a sample of past reviews at two or three settings and compare the queues before choosing.
How do we load existing EDD files?
Load the stories already on file, the decisions made on them and the current ratings, so the software starts from what the bank already knows rather than rediscovering it. A story that was reviewed and accepted last year should not come back as a fresh alert; it should be watched for a new stage. In the solution, ongoing monitoring adds a new article about a story on file to that story, and only a new story or a moved stage reaches a person.
Bring a sample of closed reviews too, for the test that matters most: running the software on reviews your analysts have already decided, and comparing. That is where the configuration is proven, and where a bank finds out whether its term lists, languages and confidence setting reproduce its own judgement. Botminds offers the same test before anything else: a run of the solution on a sample of the bank's own past reviews.
Testing the setup on your own past reviews
A configuration is proven when it reproduces the bank's own decisions on reviews already closed, and explains every difference. Pick a sample that includes the hard cases: reviews where a story was confirmed, reviews where a namesake was set aside, and reviews that found nothing. Run them through the software with the settings you intend to use, then compare five things.
First, did it find every story your analysts kept, and if not, which name form, language or source was missing? Second, what did it propose that your analysts did not keep, and on reading, was the software or the original review right? Third, did it set aside the namesakes your analysts set aside, with tests a reviewer accepts? Fourth, how many reviews landed as unsure at your confidence setting, and would a different setting move them? Fifth, how many minutes did an analyst need per review to reach the same decision? Each answer points at a setting: a missed story at the term list or the languages, too many unsure reviews at the threshold, slow reviews at the data that identity tests depend on.
Keep the comparison. It is the rationale Wolfsberg asks banks to document for any technology in the process, and the first thing internal audit will ask for when the software has run for a year.
Retention and the examiner export
Decide how long reviews and their evidence are kept, and what an examiner can be given in one step. Under the Bank Secrecy Act's general rule, "All records that are required to be retained by this chapter shall be retained for a period of five years" (31 CFR 1010.430(d)); the solution's default matches it, with seven and ten years as options, and nothing on the trail can be edited.
The audit trail: every search, proposal and decision, with an export for examiners
What to ask the vendor before day one
Ask the questions that test whether the software will run your policy or its own. The third-party guidance frames the stakes:
“A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house.”
Board of Governors, FDIC and OCC, Interagency Guidance on Third-Party Relationships: Risk Management, June 2023
Four questions follow from it. Can every setting in the table above be changed by our compliance manager, with a version and a reason, without a vendor release? Does the software search only our approved sources, and show which it searched on each review? Does it build languages and name forms from our customer data, and show why? And can it be run on our own closed reviews before go-live, with the results compared line by line? How a data API, a search engine and an agent-based product differ is the companion question, and what to ask about the AI itself has its own list. To see the settings on a working review, start from Adverse Media Screening.
Questions people ask
What is an adverse media screening tool?
It is software that searches news and other public sources for a bank's customers and presents the results for review. Tools range from data services that return matching articles to products that also group copies, test identity, translate and record the decision. The difference shows in what an analyst still has to do after the search.
Who should own the term lists and source lists?
A named compliance owner, usually the financial crimes compliance manager, with changes versioned and approved. In the sample bank, the compliance manager keeps the risk terms and every setting change is on the audit trail. Analysts should not be able to change what is searched for one review without a record.
Do we need dates of birth for every owner and director?
Not by rule, but identity testing is far weaker without them. A namesake can usually be ruled out on age alone; without a date of birth, the software and the analyst fall back on occupation, employer and city, which change over time. Collecting dates of birth for the owners and directors of higher-risk business customers pays back quickly.
Can relationship managers see adverse media results?
Usually they see only the status of a review, because what a review found can come close to information about a suspicious activity report. In the solution, a relationship manager sees only a neutral line saying a compliance review is under way and nothing is needed from them (the wording, and why, is in adverse media analyst). Whether a suspicious activity report exists never appears, consistent with 31 CFR 1020.320(e).
How long does it take to set up adverse media screening software?
The software is rarely the long part. The time goes into decisions: the category and term lists in each language, the source list, decision rights and clocks, and the customer data feeds, especially payment geography and the dates of birth of business owners. A bank that arrives with those settled can test on its own past reviews almost at once.