Adverse media screening

Adverse media screening at onboarding should return a ranked queue. Each remaining hit carries the article cite, a short extraction of who, what, and when, and a name-match rationale against the applicant file. An analyst still dispositions every true-name hit and every ambiguous hit. The model does not clear a true-name match, even when it is confident the article is old, low-severity, or not really about crime. Confidence is not a control.

The quality bar is simple. If the hit is about the person on the application, a human records the decision. If the model cannot tell, a human records the decision. If the model would have to guess a match from a common name alone, it must not invent one.

This step sits in the onboarding path, not after the account is live. Search depth can follow risk-tiered onboarding routing: a higher-risk product or geography may pull a wider corpus or a longer lookback. The disposition rule does not change with the tier.

Start from the applicant's legal name and known aliases as they appear on the application and supporting ID. Query the same media sources your program already names in policy. Banks typically already buy screening and news from vendors in this class: NICE Actimize, Dow Jones, Refinitiv, ComplyAdvantage. Treat those platforms as the hit factory. Do not replace the named corpus with an open web search, and do not let the model expand the name into people who might be the same person before retrieval.

Bound the pull. Fix lookback, language set, and source types in the procedure: licensed news, court reporting, regulator notices, and the vendor's adverse-media taxonomy. Record the query string, the timestamp, and the raw hit list. If retrieval returns nothing, that is a result: empty set, logged, not a silent skip.

Failure starts here if you skip identifiers. A query on a common name with no date of birth, nationality, or location returns a pile of unrelated people. Downstream scoring cannot repair a retrieval that never had enough to distinguish them. Pass through what KYC already collected: date of birth, place of birth, nationality, known cities, occupation, and employer. Those fields constrain retrieval.

If this screen is one node in a larger onboarding graph, keep retrieval deterministic so agentic KYC orchestration can replay the same query when an analyst or auditor asks what was searched.

For every raw article or vendor snippet, extract three facts before you talk about match quality.

Who: the name as printed, any secondary identifiers in the piece (age, job title, city, company), and whether the article is clearly about one person or a list of names.

What: the conduct in the article's own words, plus the source type. A regulator final notice is not the same object as a blog post repeating a rumour. Extract the allegation as alleged unless the source is a conviction, a court judgment, or a named enforcement outcome. Treating a blog rumour as a confirmed crime is a control failure, not an extraction win.

When: the date of the events described, the date of publication, and any later appeal or acquittal language. Stale reporting still belongs in the queue if the name match is true. Recency is for the analyst, not a reason for the model to drop the hit.

Cite the article. Store a stable identifier from the vendor feed, or a permalink plus headline, publisher, and date. The ranked row an analyst opens should show that cite first, then the extraction, then the match rationale. If the model cannot find who, what, and when, mark the hit as extraction-failed and queue it. Do not drop it because the prose was messy.

One pass through a typical file: the applicant is David Park, date of birth 14 March 1987, Korean national, applying for a UK current account. Retrieval returns three items. First, a 2019 US district-court report: David Park, age 62 at sentencing, convicted of wire fraud in California. Second, a personal blog post claiming Dave Park at a small fintech probably knew about a customer-data leak, with no employer, age, or location that matches the file. Third, a 2024 UK enforcement notice naming David J. Park as CFO of a payments firm, with an age band consistent with 1987 and a career history in London. The extractor should say, for each row, who the article is about, what it alleges, when it happened, and that the second item is rumour-grade source material. It should not rewrite the blog post as a confirmed data-theft conviction.

Name match is a comparison to the applicant file, not a resemblance score. Use the identifiers you hold: full name and aliases, date of birth or age, nationality, place of birth, known addresses, occupation, employer. State which fields agreed, which conflicted, and which were absent from the article.

A true-name hit is a hit where the article's person is the applicant on the evidence you have, not merely the same string. An ambiguous hit is a hit where the name overlaps and remaining identifiers are missing or mixed. A non-match is a hit where a material identifier conflicts: age off by decades, different nationality with no alias story, a different person clearly identified.

Do not match on a common name with no other identifiers. David Park plus a crime story is not a true-name hit. If the article has no second identifier, the score is ambiguous at best, and the row still goes to an analyst. Do not invent a match to be safe, and do not invent a clear because the name is common.

Write the rationale in plain language a second-line reviewer can read without the model. Same given name and surname; article age 62 in 2019 conflicts with applicant date of birth 1987; classify as non-match. Or: same name, age band consistent, London payments-sector role consistent with declared occupation; residual uncertainty on middle initial; classify as true-name pending analyst. That sentence is the audit artifact.

Never raise a match the identifiers do not support. Inventing a match creates false case pressure and poisons the queue. Inventing a non-match to keep onboarding moving is an auto-clear of a person you have not distinguished.

Send true-name hits and ambiguous hits to the analyst worklist, ranked by a documented mix of match strength and conduct severity, with the cite and rationale attached. Non-matches can leave the analyst queue if the conflict is explicit and logged. Empty retrieval is a pass-through with a record.

The analyst dispositions. The model does not. Auto-clearing a hit because the model was confident (low severity, old article, common name so probably not them, blog so ignore) is the failure this design exists to prevent. A true-name hit on a minor or dated matter still needs a human to apply policy: escalate, accept with rationale, or convert to a financial-crime case. Confidence scores can order the queue. They cannot close it.

If the disposition is that this is the customer and the conduct is in scope, hand the same cite and extraction into the case process you use later in the journey, including AML case disposition at funding when the hit should block or delay activation. Do not make the onboarding screener a second, unofficial suspicious-activity decision.

After go-live, the same person can attract new coverage. That is a different control: adverse media continuous monitoring and, on a refresh cycle, perpetual KYC refresh. Onboarding screening remains a point-in-time ranked queue with human disposition. Do not reuse an onboarding auto-clear logic there either.

Keep the operating rule short enough for the procedure: retrieve a bounded set, extract who, what, and when, score the name against identifiers you have, queue true-name and ambiguous hits, never auto-clear a true-name hit, never invent a match.