Adverse media — exactly how it works, and what it does not do.

Adverse-media screening looks for negative news about your subject: financial crime, regulatory action, cyber offences, organised crime. This page documents the whole pipeline — where the articles come from, how a subject is bound to an article, what evidence you get back, what the Unavailable status means, and the limits we have measured and not hidden.

1 · Where the data comes from

We use GDELT — the Global Database of Events, Language and Tone — a free, open news monitoring project that indexes worldwide news coverage. We use two of its surfaces:

GKG is what makes the feature work at all. DOC matches an article's full text but only hands back the headline — and real adverse coverage very often does not name the subject in the headline. A genuine hit like “Goldman Sachs settles shareholder lawsuit over 1MDB scandal” names no person at all. Reading GDELT's extracted person entities recovers exactly those articles.

2 · The prefetch model — a screen never calls the network

Adverse media is not fetched live during your request. A background sweep populates a cache; the screening request reads that cache and nothing else. The screening-time provider has no HTTP client at all — it is structurally incapable of making a network call.

1. The sweep runs in the background

   For monitored, previously-screened and newly-enqueued subjects, the sweep queries GDELT DOC for candidate articles, then downloads the GKG slice each article was indexed in and joins them by URL to recover the extracted person entities.

2. Evidence is scored and stored

   Each article is bound to the subject and scored (see below). What survives is stored as evidence — headline, publisher, date, category, matched person.

3. Your screen reads the cache

   POST /v1/screenings/check performs one indexed read. No third-party call sits in your latency budget, and a news-source outage or rate limit cannot slow down or break a screen.

4. An unknown subject is enqueued

   A subject nobody has ever screened has no prefetched evidence. That screen returns Unavailable instantly and enqueues the name. The sweep polls every 15 minutes, so evidence is normally available within minutes — and the next screen is real.

This is a deliberate inversion. The previous design made a synchronous call to GDELT inside every screen; GDELT rate-limits a shared cluster egress IP, so we were paying seconds of latency to obtain nothing. Taking the call off the hot path is what makes the feature both fast and honest.

3 · Unavailable is not a pass — read this before you integrate

The status is persisted with the screening and rendered in the PDF report and the regulator pack, so an auditor can see, months later, whether a given screen actually checked the news.

4 · How a subject is bound to an article

Naive name matching on news text is how an adverse-media feature earns an analyst's contempt and gets switched off. Two controls stand between a name and a hit.

The reason the second control exists is worth stating plainly: a better entity signal tells you an article is about a person of that name. It never tells you which one. Name ambiguity sets the bar; evidence has to clear it.

The rarity gate is also a fairness control, not only a precision lever. Common names concentrate in particular ethnic and national groups, so a matcher that floods on common names effectively discriminates by surname.

5 · What you get back with a hit

An adverse-media match is not a bare hyperlink. Every hit carries the evidence an analyst needs to triage it without clicking out, and an auditor needs to resolve it after the link has rotted.

We never store article bodies. Adverse media on a natural person is criminal-conviction and offence data, so retention is kept to the metadata above. GDELT hands us every person it extracted from an article — typically several — and we store only the one that binds your data subject. The other names belong to people who never asked to be screened.

Exculpatory headlines are down-ranked, never suppressed

An article saying “Smith cleared of money laundering” puts the subject and a crime word in the same headline — which naive scoring reads as maximum adverse, for an article that exonerates him. Such a match is now down-ranked and flagged with the outcome term. It is not hidden: auto-suppressing it would trade a visible false positive for an invisible false negative, and an acquittal is still information an analyst wants to see.

6 · Categories

A hit is categorised from the financial-crime term that matched, so a tenant can set a different decision per category. The categories are:

The mapping is a keyword table, on purpose. It is auditable, and it can be shown to a regulator and contested by a data subject. A black-box classifier can be neither.

7 · Why we do not use sentiment analysis

The obvious idea is to score how negative an article is and flag the negative ones. We measured it, and it does not work — so tone is captured for display and is barred from every decision path (a build-time architecture test fails if tone ever reaches the scoring engine).

Adversity is established by what the article is about — it matched a financial-crime term in its full text and the subject is named in it — not by how cross the journalist sounds. “The headline contains 'acquitted'” survives a regulator. “Tone: −1.8” does not.

8 · What it actually catches — measured

Against our adverse-media golden benchmark, replayed through the real filter, binder and emitter, at the shipped relevance threshold (0.7):

9 · The limits — what this does not do

An honest limit is worth more to you than an inflated claim.

10 · Using it from the API

Adverse media runs by default. Send "adverseMedia": false to opt out of it for a screen (the status then comes back as Skipped).

# Screen with adverse media (the default)
curl -X POST https://aml-screening.dloizides.com/v1/screenings/check \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "fullName": "Jho Low", "adverseMedia": true }'

The response carries adverseMediaStatus alongside the matched entities. Check it before you treat an empty media result as clean:

{
  "decision": "Review",
  "adverseMediaStatus": "Ok",
  "matchedEntities": [
    {
      "sourceList": "ADVERSE_MEDIA",
      "rejectionTag": "adverse_media",
      "adverseMediaCategory": "FinancialCrime",
      "headline": "...",
      "publisher": "...",
      "publishedAt": "...",
      "matchedPerson": "..."
    }
  ]
}

An adverse-media hit tags the screening adverse_media and drives a Review decision by default. Per-category decisions are configurable per tenant. Bringing your own adverse-media endpoint is also supported — see Data providers.

Attribution

Adverse-media results are derived from The GDELT Project (https://www.gdeltproject.org). Headlines, publishers and links are the property of their respective publishers. Screening assists your compliance programme; it is not legal advice, and an adverse-media hit is an indication to review, not a finding of wrongdoing.