An adverse media API is a data service a bank's systems call with a customer's name, and which returns the news articles, or the curated risk records built from them, that match. It is the plumbing of most automated negative news screening: a way to get licensed, searchable content into the bank's own screening or case tools without an analyst typing queries. What an API returns is still material to be read. It may come with a match score or a risk category, but it does not decide whether a story is about the customer, whether copies are one event, what an article in Portuguese actually says, or what the customer file should cite. A search engine leaves the same work, with less structure and no record. Botminds' Adverse Media Screening is a third category: agents that sit on top of a licensed news service, do the grouping, identity tests, translation and classification, and hand a sorted review to an analyst who decides.
The comparison below uses one fictional review from a sample bank in the solution: an EDD refresh for a director of a high-risk commercial client, whose search returned 37 articles in three languages. The bank, customer and articles are invented; the guidance cited is real.
Three ways to screen one customer, task by task
| Task on the review | Search engine | Adverse media API or feed | Agents on a licensed feed |
|---|---|---|---|
| Find articles | Pages ranked by the engine; results vary by date and user | Articles or records from the provider’s licensed sources | The licensed sources, searched with a plan built per customer |
| Search every name form and language | Only the strings the analyst types | The names the bank sends; languages per the provider’s coverage | Name forms and languages from the customer’s own data, with the reason for each |
| Group copies into one story | No: each copy is a result | Varies by provider; each article may come back separately | Yes, under the earliest original; no article dropped |
| Rule out namesakes | The analyst | A match score; the analyst decides | Identity tests dated to each article, and an agent that tries to prove each match wrong |
| Translate, keeping the original | The analyst, with a separate tool | Varies by provider | Sentence by sentence, aligned to the original |
| Classify crime and stage | The analyst | Varies; some records carry a category | Proposed, with confidence, for the analyst to confirm |
| Cite the sentence for the file | The analyst copies it | The analyst | Drafted from the confirmed story, each sentence cited |
| Decide and sign | The analyst | The analyst | The analyst confirms; a different person accepts |
| Show what was searched | Only if the analyst saves it | The bank’s logs of its calls | The plan, sources, results and every decision on the review |
What is an adverse media API?
An adverse media API (or negative news API) is an interface that takes a name and returns matching content from a provider's news collection: full articles, links and snippets, or structured records summarising a reported event. It is how most banks and screening products get licensed news into automated batch screening, onboarding checks and ongoing monitoring.
The Wolfsberg Group, a standards body formed by global banks, draws the distinction that matters for buyers: between structured data, "tailored article data that may be narrowed to focus solely on risk relevant information, for example, through the selection of specific offence types/media sources", and unstructured data, "unfiltered raw data that when utilised in the NNS process will typically return much broader outcomes" (Wolfsberg Group, Negative News Screening FAQs, 2022). An API can deliver either. Structured records are faster to review and narrower by design; raw articles are complete and leave all the reading to someone.
Is a news data feed enough?
A feed is enough to find stories; it is not enough to decide them. Wolfsberg describes three ways a bank can run negative news screening: external, where a vendor provides the technology and dataset and "can include alert adjudication components outsourced to the vendor/supplier"; shared, where "only certain solution components are provided by an external vendor/supplier" and adjudication may be internal or external; and internal, designed and run in-house. A bank that buys an API on its own has chosen the shared model, and has kept the adjudication, which is where most of the time goes.
That can be the right choice. A bank with a small, mostly domestic population and trained analysts may need nothing more than good content and a disciplined method. The question is whether the analysts' hours fit the volume, the languages and the monitoring the bank's risk assessment calls for; what manual review costs in hours by bank size works through that arithmetic.
API vs search engine vs AI agents
The three differ in what arrives on the analyst's screen. A search engine delivers pages to read; an API delivers articles or records to read, with better coverage control and a log of what was asked; agents deliver a review already sorted into stories, with namesakes set aside and their tests kept, and a proposal to confirm or reject. On the sample review the difference is measurable.
One review, three levels: what an analyst would otherwise read
37
articles found in three languages under six forms of the name
4
stories once 33 copies and follow-ups were grouped
1
relevant story, after two namesakes and one harmless story were set aside
The search engine also loses on record-keeping. Wolfsberg warns that engines and publishers "have the right to purge, alter or archive the content at any time", so a page seen today may be gone at the next exam. A licensed feed keeps an archive, and Wolfsberg lists "Archive: accessibility of media articles which are archived or no longer available in open sources" among the criteria for judging one.
What does an adverse media API not do?
An API does not group the copies, test identity against the customer's dated identifiers, translate with the original kept, place a story's stage, write the finding or decide. Some providers do parts of that in their data, which is why the questions below matter, but the shape of the product is a search over content.
What an API call returns, and what the review still needs
Returned by an API: Each matching article or record, often including syndicated copies of the same report.
Needed for a decided review: One story per event, with every copy listed under the earliest original.
Returned by an API: A name match, perhaps with a score.
Needed for a decided review: Age, occupation, company, role and city compared with the customer file, as of each article’s date.
Returned by an API: The article as published, or a translated summary.
Needed for a decided review: The original sentence beside its translation, so the file can cite what the source said.
Returned by an API: Possibly a risk category.
Needed for a decided review: The category, the stage from allegation to conviction, and the denial or lack of charges.
Returned by an API: None.
Needed for a decided review: A reason code from the analyst, acceptance by a different person, a rating effect.
The middle step, identity, is where the gap is widest. An API's match score says how closely a name in an article resembles the name the bank sent. It cannot say that the footballer of 27 in a Porto story is not a 53-year-old engineer in Houston unless it holds the engineer's date of birth, which the bank may not want to send. That comparison belongs where the customer data is, inside the bank.
Who reads the results?
The bank's analysts read them, unless the bank has outsourced adjudication as well, and even then the bank answers for the result. The US banking agencies' third-party guidance says a bank "is responsible for conducting its activities in compliance with applicable laws and regulations, including those activities involving third parties. The use of third parties does not abrogate these responsibilities" (Interagency Guidance on Third-Party Relationships, 2023).
What reaches the analyst when agents read first
In the solution, nothing the agents conclude reaches the customer file without two people. The analyst confirms the relevant story with a reason code; a different person, the EDD reviewer, accepts it; the compliance manager approves any rating change. The agents' steps, with their confidence, are on the review for the analyst to check.
How do adverse media APIs handle languages?
Through their source coverage and, sometimes, translation. A provider's coverage decides which countries' and languages' press the bank can search at all, and its translation, if any, decides what an analyst reads. Wolfsberg lists both among evaluation criteria: "Coverage: robustness of the data-base content and scope of monitored media sources", with "sufficient media coverage in markets where the FI operates or where the customer base is located", and "Translation: capability to provide news/events translated into the language of the FI's operation."
A Portuguese report, read in English, cited in Portuguese
Coverage is necessary and not sufficient. A feed that holds Brazilian regional press still has to be searched in Portuguese, under the name forms Brazilian outlets use, for the customers whose footprint points there. Research prototypes show what happens otherwise: one academic agent for adverse media screening searched only English-language sources and the top ten web results per name, limits its authors acknowledged (arXiv 2602.23373).
How to evaluate an adverse media API
Evaluate it on the bank's own customers and past reviews, against Wolfsberg's criteria and the contract terms the third-party guidance expects. The checklist below combines the two.
Questions to put to any adverse media API or news data provider
- Coverage
Which countries, languages and outlet types, and how deep the archive goes, for the places your customers are tied to.
- Duplicates
Whether syndicated copies come back as one event or many; Wolfsberg asks about “levels of alert duplication if the same adverse data is found in multiple data sources”.
- Matching
How names are matched across forms and scripts, and what the score means.
- Traceability
Whether you can record “all internal screening events, configurations and other logic applied to generate a match”.
- Source reliability
How the provider judges outlets, and whether you can exclude sources you do not accept.
- Data sharing
What customer data leaves the bank with each call, and where it is processed and kept.
- Regulatory access
A contract term that the service is “subject to regulatory examination and oversight, including appropriate retention of, and access to, all relevant documentation and other materials.”
- A test on your own reviews
Run a sample of closed reviews and compare what comes back with what your analysts found.
The test on your own reviews is the one vendors find hardest to fake. It shows coverage gaps in your customers' countries, duplicate rates on real stories, and how often a score would have sent an analyst after a namesake. It also gives the bank the documented rationale the agencies and Wolfsberg both expect for any technology in the process.
Where Adverse Media Screening sits on top of a feed
Adverse Media Screening is not a news provider; it works with one. It connects to a licensed adverse media service, with news, wires and regulator releases in 31 languages, and to court and enforcement notices, and searches them with a plan built from the bank's client lifecycle system. The agents then do what the API leaves undone: group the copies, test identity, translate sentence by sentence, propose a category and stage, and draft a cited paragraph from the stories a person confirms.
That is the honest boundary for buyers. If the bank's problem is content, which countries and languages it can search at all, it needs a better feed, and the solution does not replace one. If the problem is the hours between the feed and the decision, and the record of how each decision was reached, that is what the agents and the two signatures are for. A bank can have both problems, and a test on its own past reviews shows which is larger. What to bring to set it up and how the agents are kept honest are covered in their own guides; to see a review sorted end to end, start from Adverse Media Screening.
Questions people ask
What is a negative news API?
The same thing as an adverse media API: a service that takes a person's or company's name and returns news articles or risk records that match it. Banks use them to automate onboarding checks, periodic refreshes and ongoing monitoring. The results still need to be matched to the customer and judged.
Do adverse media APIs return false positives?
Yes, because they match names, and names are shared. A common name returns stories about many people, and syndicated copies of one story can return as many hits. Better matching narrows the results, but ruling out a namesake needs the customer's own identifiers, which the bank holds.
Can an adverse media API do ongoing monitoring?
A feed can be queried on a schedule for new matches, which is the raw material of monitoring. Useful monitoring also knows which stories are already on file, so a repeated article joins its story instead of raising a new alert, and only a new story or a moved stage reaches a person.
Is scraping the web a substitute for a licensed news feed?
It is a weaker one for screening. Open web content can be changed or removed at any time, coverage is whatever the engine indexes, and results vary by date and user. A licensed feed gives a defined source list and an archive the bank can return to when an examiner asks what a review saw.
What should an adverse media API contract include?
Coverage and service levels, the bank's right to audit, data protection terms for what the bank sends, and access for regulators. The 2023 interagency guidance says it is important for contracts to make a third party's work "subject to regulatory examination and oversight", and to specify each party's obligations to comply with applicable law.