Adverse-media screening that cuts the noise

Adverse-media screening fails when tools match a name and stop there. A common name pulls hundreds of articles about namesakes, and a keyword list cannot separate a fraud conviction from a quote in a local sports report. Two models fix this: entity resolution decides whether an article is about your customer, and relevance scoring decides whether it describes conduct you care about.

You can see the failure in any queue. An analyst opens a case, finds four hundred articles attached to a common name, and clicks through the first forty before deciding the alert is junk. The other three hundred and sixty go unread. That is a search box with a compliance label on it, and it fails in the direction nobody notices, because the one article that mattered was ranked four hundred and second.

The name is not the person

Entity resolution is the part most vendors quietly skip, because it is hard and it does not demo well. The question it answers is narrow: is this article about the same individual or company in your customer record? A string match cannot answer it. “James Miller” returns a fraudster, a footballer, a city councillor and a man who won a pie contest, and the tool treats all four as the same alert.

Resolution works by scoring the agreement between attributes you hold and attributes the article exposes.

• Date of birth or incorporation date, when the article states one.
• Location: the customer’s registered address versus the geography of the reporting.
• Employer, role and sector, which disambiguate two people who genuinely share a name.
• Known associates and corporate structure, which let you connect a director to a company named in an enforcement notice.

None of these are guaranteed present, and that is the design constraint. A good resolver produces a calibrated probability that the mention and the customer are the same entity, and it degrades gracefully when the article gives you almost nothing to work with. Low-confidence matches do not get thrown away. You route them differently and you record why. This is the same matching problem sanctions screening faces, so the entity model should be shared between the two rather than rebuilt per feed.

Relevance is a scored decision

Once you believe an article is about the right entity, you still have to decide whether it says anything that matters. Negative news is a wide category. A parking dispute, a defamation claim the subject won, a decade-old article about a company with the same name, and a live money-laundering indictment all trip the same keyword lists. Treating them as equivalent is what floods the queue.

Relevance scoring assigns a category and a severity to the conduct described, tied to your own risk taxonomy: financial crime, corruption, sanctions evasion, violent crime, regulatory action, and so on. A few decisions matter more than the model architecture:

• Read the subject’s role. The subject’s role changes everything: a fraud victim is not a risk event, the accused is, and an expert quoted for comment is neither.
• Weight by source and recency. A regulator’s enforcement page outranks an aggregator that rewrote it, and a resolved matter from 2009 is not a current concern.
• Keep the category explicit in the output, so an analyst reads “regulatory action, high severity” rather than a bare number they have to reverse-engineer.

What reaches an analyst should be a short, ranked list carrying a stated category, a severity, a resolution confidence and the sentence that triggered the score. A human can clear or escalate that in minutes. Four hundred undifferentiated links, they cannot.

Governing the model you now depend on

The moment relevance scoring decides what an analyst never sees, it becomes a control, and it has to be governed like one. Under SR 11-7 that means the model is documented, independently validated and monitored in production, with false-negative behaviour treated as the primary risk rather than an afterthought.

• Hold a labelled eval set that includes hard true positives, the real cases an analyst escalated. Track recall on it on every change to the model, the prompt or the feed. A precision gain that quietly costs recall is a loss.
• Set a false-positive budget and a conservative auto-close threshold, and keep everything below the auto-close line in a human queue rather than deleting it. Auto-closing a hit is a logged decision, and it should read that way in the audit trail.
• Watch for drift. News language shifts, sources come and go, and a new syndication partner can change the mix of what the model sees overnight. Alert on the distribution of scores, not just the model’s own confidence.
• Preserve lineage for every decision. The article, its source, the resolution probability, the relevance category and the score all need to survive to an audit two years later, when a regulator asks why a customer with adverse coverage was cleared.

There is a point-in-time correctness issue here that is easy to miss. When you re-screen a customer, you are asking what was knowable at the review date, not what the internet says today. A case cleared in March should be reconstructable as it stood in March, with the sources available then, so that a later reviewer is judging the decision and not the passage of time. Screening that cannot reproduce its own past state cannot defend it either.

So there is no filter to switch on. What works is two models, an eval set that punishes missed risk, and lineage deep enough to reconstruct any single decision on demand. Get those right and the analyst reads the cases that matter. Skip them and you have automated the act of not looking.