Transparency

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.

The short version. The source is GDELT, an open global news-monitoring project. Evidence is prefetched by a background sweep, so a screening request never calls the news source over the network. A hit comes back with a headline, a publisher, a date, a category and the person entity that matched. If we have no prefetched evidence for a subject, we say Unavailable — we did not check — instead of returning a clean pass.

This is continuous monitoring, not point-in-time screening. Everything else on this page follows from one property: evidence is gathered before your screen, never during it. That makes the control fast, outage-proof and honest — and it makes it useless on a name we have not met yet. Screen someone today and you will very likely get Unavailable; put the same subject under monitoring and the coverage accrues behind them. Judge the feature against the job it actually does: ongoing monitoring of a known book of subjects. If your workflow is onboard a stranger and decide in this request, adverse media will return Unavailable essentially every time, and you should not price it into that decision.

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 three of its surfaces:

Surface	What it gives us	How we use it
GDELT DOC 2.0 `api.gdeltproject.org`	Article metadata only — URL, headline, publisher domain, index date, language. It full-text-searches the archive but never returns the article body.	Retrieval (back-history). Finds candidate articles for a subject name combined with financial-crime terms.
GDELT GKG 2.0 `data.gdeltproject.org`	The entities GDELT itself extracted from each article — including the person entities named in it — plus themes and a document tone score.	Evidence. Tells us whether GDELT's own extractor identified your subject as a person named in that article.
GDELT bulk 15-minute slices `data.gdeltproject.org`	Every GKG record GDELT published in a 15-minute window — roughly 3 MB per slice, downloaded whole.	Forward coverage. Tails the live news firehose and matches each slice against the subjects we already know, so new coverage lands without asking the rate-limited search API for anything.

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.

Why GDELT — the licence, not just the price. GDELT — the Global Database of Events, Language and Tone — is a public, near-real-time index of world news. We chose it substantially for its licence. Most news and risk-data sources forbid reselling results derived from them, which disqualifies them outright for a product we license to other companies: adverse-media-expansion.md §2.2 rejected OpenSanctions' bulk data on exactly that ground (CC BY-NC 4.0, no exemption for commercial users). GDELT's terms are the opposite, and they are worth quoting rather than paraphrasing — see below. The obligation that comes back with that freedom is attribution, which is why a GDELT citation travels with the evidence into the API response, the PDF report and the regulator pack rather than sitting in a footnote. One boundary we hold ourselves to: the licence covers GDELT's own metadata and extracted entities, not the underlying article text. So we store URL, publisher, date, the bound person entity, theme and tone — and never article prose.

Using GDELT

“The GDELT Project is an open platform for research and analysis of global society and thus all datasets released by the GDELT Project are available for unlimited and unrestricted use for any academic, commercial, or governmental use of any kind without fee.”

Redistributing GDELT

“You may redistribute, rehost, republish, and mirror any of the GDELT datasets in any form. However, any use or redistribution of the data must include a citation to the GDELT Project and a link to this website (https://www.gdeltproject.org/).”

Quoted verbatim from gdeltproject.org/about.html, fetched 2026-07-20 and recorded in our own feasibility study rather than paraphrased from memory.

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.

Background sweep

Two independent background workers populate an evidence cache. The prefetch sweep asks GDELT DOC for back-history on subjects we know about; the slice tailer downloads every 15-minute GKG slice and scans it against the subjects already in the book. Neither runs inside your request.
Bind the article to a person

An article is only attributed to your subject if GDELT's own extractor named a person whose tokens match the subject as an ordered, adjacent span within a single extracted person entity. Never a bag of tokens pooled across the article.
Score and store

What survives the relevance filter is stored as evidence: headline, publisher, date, category, matched person entity, and GDELT's tone (captured for display, never for a decision).
Your screen reads the cache

POST /v1/screenings/check performs one indexed read against the evidence cache. The screening-time provider is constructed without an HTTP client at all — it is structurally incapable of making a network call.

The first screen of any new person returns nothing. Plan for it. A screen performs one indexed read of the prefetched store (GdeltAdverseMediaProvider.cs:112). A name the system has never seen is not fetched during the screen — it is enqueued for a later background sweep, and the screen returns Unavailable immediately. That is precisely the onboarding moment, which is the worst possible time for a control to be silent, so we would rather you designed around it than discovered it: an applicant's very first adverse-media screen is expected to be Unavailable, and it is not a clean pass.

How fast an enqueued name actually gets fetched. The back-history sweep is paced at one subject per minute (DelaySecondsBetweenSubjects = 60, AdverseMediaPrefetchOptions.cs:52) and capped at 500 subjects per run (MaxSubjectsPerRun). That is a ceiling of roughly 1,440 subjects a day, and in practice fewer: when GDELT refuses our shared egress IP the sweep goes deliberately quiet, backing off from 300 s up to a 1,800 s cap. Names you actively screened are queued ahead of routine refreshes, but the arithmetic is the arithmetic — a large book takes days to enrol, not minutes. The 15-minute slice tailer is not rate-limited at all, but it is forward-only: it catches news published after a subject enters the book, never their back-history.

Once a name IS fetched, we look years back — not just recent news. A common and reasonable assumption about a news-derived control is that it only sees recent coverage. Not here. GDELT's DOC API defaults to a rolling ~90-day window, which made the system blind to any subject whose adverse coverage was older than three months — a fatal property for AML, where the signal is inherently historical (a 2019 conviction with no recent press scored zero). The fetcher therefore looks back LookbackYears (default 8), floored at the 2017 archive boundary (GdeltDocFetcher.cs:92-99). So the trade is specific: coverage is the weak point, depth is not. Getting a subject fetched is hard; once fetched, their deep history comes with them.

A live look-up path exists, and it is switched off — deliberately. AdverseMedia:LiveFallbackEnabled (AdverseMediaOptions.cs:55) makes a cache miss go to GDELT during the screen. It defaults to false and our hosted deployment leaves it false. The reason is not that it does not work: it is that GDELT's free tier persistently rate-limits our shared cluster egress IP, so turning it on buys seconds of added latency on every screen and still returns nothing. Lowering the timeout is not a fix — a short timeout still puts a round-trip on the hot path and still returns nothing while throttled. A tenant with their own GDELT endpoint or key sidesteps the shared-IP limit entirely, which is what the per-tenant BYO provider (AM-2, already shipped) is for; a self-hosted deployment with its own egress is exactly the case this switch was kept for.

Why the evidence is prefetched instead of searched during your screen. GDELT's DOC search API asks for no more than one request every five seconds, and the throttle attaches to the originating IP address — not to a customer, an account or a key. All of our hosted traffic leaves one address, so every screen from every client draws on that single allowance. The original design did search live, once per screen; under any real volume it returned HTTP 429 and then stayed refused — the wall is sticky and stochastic, it carries no Retry-After header to respect, and probing it re-arms it (measured: ~20–25% success even at >20 s spacing). The failure mode is the part that matters. A refused search does not look like an error: GDELT signals a throttle with a plain-text notice under HTTP 200, and the original code parsed that as JSON, failed, and swallowed the failure into “no adverse media found” (GdeltResponseReader.cs:26-30). So a throttled screen completed, reported nothing, and was indistinguishable from a genuinely clean subject. That is the worst thing a compliance control can do. An analyst can act on “we have not checked this yet”; they cannot act on a “nothing found” that secretly means “we were blocked”. Two changes close it: the reader now recognises the notice and raises instead of returning an empty list (GdeltDocFetcher.cs:51-73; the fetcher's null-vs-empty contract is load-bearing and documented at GdeltDocFetcher.cs:10-15), and the evidence gathering moved off the screen entirely — which is what makes an honest Unavailable possible at all, instead of a false clean. The enrolment delay described above is the price of that, and it is the trade we chose deliberately: slower to cover a name, but never a silent false clean.

How the unmetered route actually works. Alongside the search API, GDELT publishes a complete batch every 15 minutes of everything it indexed in that window — each article plus the entities its own extractor pulled out of it: people, organisations, locations, themes and a tone score. It is plain HTTP off a static file server (data.gdeltproject.org, GkgOptions.cs:20), no key, no rate limit — measured across 19 slice fetches during the AM-P2 spike and again across six back-to-back slices during the own-corpus feasibility study, without a single 429 (GkgSliceClient.cs:22-31). That is 96 batches a day, each a measured mean of ~2.4 MB compressed carrying ~587 articles, ~77% of which name at least one person. We take every batch, check each article against the names already in the monitoring book, keep what binds, and discard the rest — nothing from a slice is stored as a corpus (GkgSliceClient.cs:28-31, GkgRecord.cs:33-38). State the consequence plainly: we are not short of data. We receive all of it and filter down to names we already track. And state the limit just as plainly: the batches are forward-only. Today's batch holds today's news. It would never have carried a 2019 conviction that has had no press since — which is the dominant AML case, and precisely what the DOC back-history look-back exists for (AdverseMediaSliceTailService.cs:49-51). So the free bulk route improves coverage from the day it starts and cannot retroactively fill history. Deep historical backfill is a separate, paid GDELT product (BigQuery) and is deliberately out of scope.

So the metering is on the search service, not on the data. One distinction explains both the design and the options. Same project, same licence, two delivery routes. Asking GDELT to search its archive for a name is a query against a shared, rate-limited service. Downloading the batch it has already published is a static file, and nobody is metering it. That is why the architecture looks the way it does: back-history has to come through the metered door one subject at a time, forward coverage comes through the unmetered door in bulk — and it is why the two workers exist with such different characters. It is also what the knobs turn on. A tenant with their own egress or their own GDELT endpoint has their own allowance at the metered door, which is exactly why the live look-up switch was kept rather than deleted.

What one 15-minute batch actually looks like. Readers are repeatedly told we ingest GDELT's bulk files; here is one. The whole addressing scheme is that the filename is the timestamp. 20260720124500.gkg.csv.zip is the window beginning 2026-07-20 12:45 UTC — change the digits and you have another slice, which is exactly what GkgSliceClient.cs:72 does when it builds {BaseUrl}/{sliceStamp}.gkg.csv.zip against http://data.gdeltproject.org/gdeltv2. There is no index to crawl and nothing to authenticate against: a tiny pointer file, lastupdate.txt, always names the three newest files with their sizes and MD5s. GDELT publishes three files per window — .export. (events), .mentions. and .gkg. — and we take only .gkg., the one carrying extracted entities. It is a static file server, not an API (GkgSliceClient.cs:20): no key, no quota, and no query — you cannot ask it for a name, only for a time window.

Measured on 2026-07-20, the slice above was 4.7 MB zipped, 15 MB of CSV, 1,074 articles — tab-separated, one article per row. Slices vary in size; this one runs roughly double the ~2.4 MB / ~587-article mean quoted earlier, which is the normal spread of a news day rather than a discrepancy.

A single real row from that slice, trimmed to the fields we actually read:

URL       https://www.intelligencer.ca/news/controversial-conference-presentation-sparks-protest…
SOURCE    intelligencer.ca
THEMES    PROTEST;TAX_FNCACT;EDUCATION;SOC_POINTSOFINTEREST_UNIVERSITY;EPU_POLICY…
PERSONS   person-a; person-b; person-c; person-d; person-e; person-f   (6 extracted — REDACTED)
ORGS      hebrew university;instagram;goodes hall at queen university…
TONE      -3.2590051457976,2.57289879931389,5.83190394511149,…   (7 values; the first is overall tone)

The PERSONS field is redacted and is the only altered field. The real row names six identifiable living people who have done nothing wrong; publishing them in our own documentation would sit badly beside the Article 10 position further down this page. The URL, source, themes, organisations and tone values are verbatim. Trailing … marks a field trimmed for width, never edited.

The extraction is already done before we see the row. This is the property the whole design rests on. GDELT has already read the article, pulled out the people and organisations, classified the themes against its own controlled vocabulary and scored the tone. We are not running NLP over article prose — we could not, since we never hold the prose. We parse a row that arrives carrying structured entities, and our job is the far narrower one of deciding whether one of those extracted person entities is your subject. That is why matching against the whole firehose is tractable at all, and why an own-index option is tractable too: the expensive part was done upstream, for free, and republishing it is permitted.

And note what this row is not: a hit. Its tone is −3.26 — distinctly negative. A naive design would surface it. It carries no offence theme, so we do not, and that is the correct outcome: it is a campus protest story, not adverse media. Negative tone alone is never a hit. It takes an offence theme and a bound name match — which is the same argument made in the sentiment section below, here in a row you can look at.

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

“We did not check” and “we checked and found nothing” are different answers. Every screening response carries an adverseMediaStatus. An empty media result with status Unavailable means the check did not happen. Your integration MUST NOT treat it as a clean pass. A control that silently reports “no adverse media” when it never looked is 100% false negatives while still looking like coverage — that is the single worst failure mode this feature can have, so we surface it explicitly instead of hiding it.

`adverseMediaStatus`	Meaning	Is an empty result a clean pass?
`Skipped`	You opted out for this screen (`"adverseMedia": false`), or the feature is disabled.	No — we did not look.
`Ok`	Evidence was read successfully.	Yes — an empty result is trustworthy.
`Stale`	Evidence was served from an older cached lookup. It may be out of date.	Qualified — treat with the age in mind.
`Unavailable`	No evidence exists yet for this subject. The subject has been enqueued for the next sweep.	No. Adverse media was not checked.

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.

Ordered, adjacent name binding

A name must appear as an ordered, adjacent span — not a bag of tokens. A token-set match would let “Adam Smith and John Maynard Keynes” resolve to the subject “John Smith”. It cannot, here.

The rarity gate

A common name can never clear the bar on the name alone. For a high-collision surname, an extracted person entity is not accepted as identification, and we fall back to stronger headline evidence. The surname list is generated from our own corpus of 490,072 names — every surname shared by 25 or more distinct individuals.

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.

Field	What it is
`headline`	The article headline.
`publisher`	The publishing outlet's domain, for source credibility.
`publishedAt`	When the article was published/indexed. A 2009 allegation and a 2026 conviction are not the same signal.
`externalId`	The article URL.
`adverseMediaCategory`	The FATF-style category (see below).
`matchedPerson`	The person entity that bound the subject to the article. This is the “why” behind a hit whose headline names nobody. Null when the subject was identified from the headline alone.
`exculpatoryOutcome`	An outcome term in the headline suggesting the subject was cleared rather than accused (“acquitted”, “charges dropped”). See below.
`articleTone`	GDELT's own published tone score. Display-only. See §7.

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:

Category	Classified from
Financial crime	money laundering, fraud, corruption, bribery, embezzlement, Ponzi, scam
Cybercrime	cyber, hacking, ransomware, data breach
Regulatory	regulator, sanction, fine, censure, enforcement
High risk	terror, trafficking, organised crime, smuggling, racketeering
Unknown	matched adverse coverage that fits none of the above rules

Classification runs over two inputs: the headline keywords, and — where the headline carries no crime word at all — the GDELT GKG themes attached to the article, run through the same table. Themes are language-independent; the keyword list is English.

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).

Negative ≠ relevant

An article can be scathing about a politician's dress sense — very negative, zero AML relevance. On a live sample of 1,440 articles, the most negative items were a prison riot, a depression story and a celebrity death. Zero predicate offences.

Relevant ≠ negative

A money-laundering indictment is often reported in clinical, neutral prose. A tone gate at −5 was measured to discard 44% of genuinely AML-relevant articles — an embezzlement suspension scores only −3.21.

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):

38.9% recall

14 of 36 benchmark positives — subjects with known, dated adverse media — are caught. Reading the PERSON entities GDELT already extracted, instead of the headline alone, lifted this from 16.7% (6 of 36), with no change to the threshold.

100.0% precision on common names

15 of 15 clean common-name subjects (the false-positive stress set) produce no hit. This is the number that decides whether an analyst keeps the feature switched on — and it is unchanged by the recall work above: the recall was bought with better evidence, not a lower bar.

Read these numbers with their caveats. The benchmark is 36 positives and 15 common-name negatives. That is a small corpus: the percentages are indicative, not a measurement anyone should tune a compliance control on. Recall is measured only over positives GDELT actually returned articles for — a subject with an empty source response is a coverage gap, not a filter miss. At the same threshold the rare-name negatives came out at 1 of 2 clean — n = 2, far too small to express as a percentage, and a real false positive we are not waving away. Corpus generated 2026-07-14T21:35:39Z. These figures are regenerated by the test suite and injected here by a generator — they are never hand-written.

Coverage of a real applicant population is the honest weak point, and it is small. The numbers above measure the matcher's quality on evidence we already hold. They are not the coverage you get on an arbitrary name. Measured against a 2,042-name applicant corpus on 2026-07-15: 2,038 of 2,042 real applicants (99.8%) returned Unavailable — we had never fetched evidence for them. Adverse media actually ran for 4 of them, roughly 1 in 500. The 15-minute slice tailer (shipped after that measurement) exists precisely to fix this, and it is enabled in our hosted deployment. But its effect on coverage is unmeasured, and we will not quote a projection as though it were a result. A benchmark run confirmed the mechanism works — the evidence store went from 0 to 1,530 lookups, the tailer's subject book from 0 to 1,317, at about 2 hits per slice — but that is proof of function, not of coverage. A cold one-shot batch cannot measure the improvement, because the batch that measures coverage is the same batch that enrols the subjects: every name is being met for the first time as it is counted. A real figure has to accrue over days of live tailing, and none is recorded. Treat the coverage figure as 0.2% measured (2026-07-15), improvement unmeasured.

Two different numbers, and conflating them would flatter us badly. 38.9% is filter quality on evidence we already hold — of the benchmark subjects for whom GDELT did return articles, how many the matcher correctly catches. 0.2% is whether we hold any evidence at all for an arbitrary real applicant. The first says the matcher works; the second says it rarely gets the chance. A vendor quoting only the first number would be describing a different product from the one you would actually run.

9 · The limits — what this does not do

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

Limit	Detail
Coverage of arbitrary names is low	The measured figure is above and it is the single most important number on this page. A name nobody has screened before will very likely return `Unavailable` on its first screen. That is the honest failure mode, but it is a coverage gap, not a feature.
Matching is exact, not fuzzy	Sanctions and PEP matching is fuzzy, phonetic and nickname-aware. Adverse-media binding is not. It compares normalized tokens with ordinal equality, so a transliteration, a diminutive or a misspelling in the news will not bind. This is a deliberate precision choice — fuzzy matching against an open news corpus floods — but it means we miss real coverage.
A common surname cannot self-identify	On a high-collision surname — measured from our own 490,072-name corpus as a surname shared by 25 or more distinct individuals — a name match alone is never accepted as identification, and provenance is suppressed so no report claims a resolution it did not earn. This is a fairness control as much as a precision one: a matcher that floods on common names discriminates by surname.
Source-coverage gaps we cannot tune away	Some subjects are missed because the source never names them. Our own benchmark still misses Roger Ng, a convicted 1MDB banker: GDELT returns on-topic articles, but its extractor names Jho Low and Tim Leissner and never him. No threshold change fixes that.
English retrieval terms	The negative-keyword retrieval terms and the headline keyword classifier are English. GKG themes are language-independent and partly compensate, but non-English coverage is under-represented.
No article bodies, no story clustering	We hold headlines and metadata, never article prose — it is unlicensed and we will not pretend otherwise. We also do not yet collapse one story syndicated across many outlets into a single event, so a widely-carried story can appear as several hits.
Discovery, not adjudication	We can tell you an article is about a person with your subject's name. We do not confirm it is your subject. A commercial vendor sells human-curated, entity-resolved dossiers. This is not that, and we will not imply it is.

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://wl.proovid.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": "..."
    }
  ]
}

A hit produces Review, never an automatic Fail. An adverse-media hit is tagged adverse_media and resolves to Review — a human dispositions it. The automatic-Fail branches key on sanctions and criminal matches only. A hit can still reach Fail, but only because a tenant configured it to — a per-category warning-type override, or an escalate-high-risk-band policy. It never happens on the strength of the news hit alone.

Bringing your own adverse-media endpoint is also supported — see Data providers.

Operator configuration — the knobs that matter

These are the settings that change what this feature is, rather than tuning it at the margin. Everything below is read from configuration at startup; there is no AdverseMedia section in appsettings.json, so every value comes either from the C# option defaults or from your deployment's environment.

Knob	Default	What moving it does
`AdverseMedia:Prefetch:DelaySecondsBetweenSubjects`	`60`	Pacing of the back-history sweep. This is the number that sets how fast a book enrols (60 s ⇒ ~1,440 subjects/day ceiling). Lower it only if your egress is not rate-limited; on a shared IP a faster sweep enrols slower, because GDELT raises a multi-minute wall.
`AdverseMedia:LiveFallbackEnabled`	`false`	Let a cache miss fetch during the screen. Only sane where your egress IP has its own GDELT quota. Costs screening latency and reintroduces a third-party dependency on the hot path.
`AdverseMedia:LookbackYears`	`8`	How far back a fetch reaches, floored at the 2017 archive boundary. Raising it costs nothing per screen — the depth is paid for once, in the background fetch.
`AdverseMedia:Prefetch:MaxSubjectsPerRun`	`500`	Bound on a single sweep so an unexpectedly large subject set cannot run all day.
`AdverseMedia:SliceTail:Enabled`	`false in code, true in our hosted deployment`	The 15-minute forward tailer. Not rate-limited, but forward-only — it never recovers back-history.
`Per-tenant BYO provider (AM-2)`	`unset`	Point a tenant at their own adverse-media endpoint/credentials. The clean way around the shared-IP rate limit, and the reason the live path was kept rather than deleted.

Data protection — what you are responsible for

Adverse media on a natural person is GDPR Article 10 data. Information relating to criminal convictions and offences — or to alleged offences — is Article 10 data under the GDPR, processed under stricter conditions than ordinary personal data. Adverse-media screening of natural persons falls in that category. We state this as a fact about the data, not as advice, and we make no claim that using this feature makes you compliant. Establishing a lawful basis for the processing, and handling data-subject rights over that evidence, are the operator's responsibility and should be settled with your own legal counsel before the feature is switched on in production. On retention, be aware of a current product limitation: the built-in retention purge is off unless explicitly enabled, and even when enabled it covers screening requests only — it does not age out the stored adverse-media article evidence, which therefore persists indefinitely by default. The cache-hours settings control when an entry is re-fetched, not when it is deleted. A retention and erasure capability for that evidence is in development; until it ships, factor the current behaviour into your DPIA rather than assuming a retention window is being enforced for you.

Attribution

Adverse-media results are derived from The GDELT Project (gdeltproject.org). Headlines, publishers and links are the property of their respective publishers. This citation is a condition of GDELT's terms, not a courtesy, so it travels with the data: it is rendered alongside adverse-media results in the API response, the PDF report and the regulator pack. 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.