2026-09-17, News · Google · Engineering · Fundamentals

Perpetual KYC and adverse media: event-driven screening between reviews

Perpetual KYC is customer due diligence that updates when something changes, not when the calendar says so. Instead of reviewing every customer every one, three or five years depending on risk tier, a perpetual KYC (pKYC) program watches for trigger events, such as a change of ownership, unusual transactions or new adverse media, and reviews the customer when one occurs. Periodic reviews often remain as a backstop.

Adverse media is harder to run continuously than internal triggers because the data lives outside the institution’s own systems. This article is for the engineers and analysts who build that pipeline. It is not legal advice, and nothing here makes a program compliant: your compliance function decides what screening is required and how hits are adjudicated.

What public guidance says

Three public sources, all checked on 2026-09-17, are useful for framing the design. They come from different jurisdictions and have different legal status, so read them as context, not as a checklist.

European Banking Authority, ML/TF Risk Factors Guidelines (EBA/GL/2021/02, consolidated version):

• Among customer risk factors, it asks whether there are adverse media reports about the customer and says firms “should determine the credibility of allegations on the basis of the quality and independence of the source of the data and the persistence of reporting of these allegations.” It adds that the absence of criminal convictions alone may not be sufficient to dismiss allegations.
• Guideline 4.76 states that firms must keep CDD information up to date, and 4.78 says a change in the customer’s circumstances is likely to trigger a requirement to apply CDD measures, without necessarily re-applying all of them.
• Guideline 4.71 says firms should determine the frequency and intensity of monitoring on a risk-sensitive basis.
• Its general list of enhanced due diligence measures (4.64) includes adverse media searches, and several of its sector-specific guidelines mention carrying out “open source or adverse media searches.”

FinCEN, CDD Rule FAQs (fincen.gov), for covered US financial institutions: FAQ F.6 says “there is no categorical requirement that financial institutions update customer information on a continuous or periodic schedule,” and that the requirement to update “is risk based and occurs as a result of normal monitoring.” FAQ B.18 makes the same point for beneficial ownership information: updates are triggered by risk-relevant information found in monitoring, not by routine periodic reviews alone. The CDD Final Rule page describes the requirement to conduct ongoing monitoring and, on a risk basis, to maintain and update customer information.

The Wolfsberg Group, Negative News Screening FAQs (2022) (wolfsberg-group.org). Wolfsberg is an association of banks, not a regulator, but its FAQs are practical: it notes there is no single, universally agreed approach to negative news screening, recommends precise wrongdoing terms over generic ones that inflate alert volumes, discusses assessing source reliability and materiality, and suggests that after onboarding it may only be necessary to screen against new media events.

Read together, the design constraints are clear: monitoring intensity follows risk, a material change should prompt a review, source quality matters, and ongoing screening should focus on what is new.

Periodic review versus event-driven review

The last row is the one engineers own. A periodic program that skips a review is visible in a backlog report. An event-driven program whose news feed stopped three weeks ago looks exactly like a quiet month. Coverage monitoring is not optional.

Trigger events and where they come from

This article covers the first row. The rest belong to other systems, and a pKYC orchestration layer consumes all of them.

Designing the adverse media delta screen

Onboarding screen versus ongoing screen

The onboarding screen is broad: full name variants, several risk-term families, several languages, multiple result pages, and a human review of everything that matches. The ongoing screen is narrow: the same subject, the same templates, but only results that were not seen before get to a reviewer.

The delta can be enforced in two layers:

1. Query layer. Google documents after: and before: operators on its Refine Google searches help page (checked 2026-09-17). Adding after:2026-09-01 to a Google Search query narrows results by date. Verify on your own templates that it narrows Google News queries the way you expect before relying on it.
2. Store layer. Keep every URL already shown to a reviewer for that subject, with the decision. This layer is the one to trust, because date signals on the web are imperfect.

Query templates

Structure templates the same way for onboarding and ongoing screens so decisions stay comparable:

"{full_name}" (fraud OR "money laundering" OR bribery OR corruption)
"{full_name}" (indicted OR charged OR convicted OR sentenced)
"{full_name}" (sanctioned OR "enforcement action" OR fined OR "cease and desist")
"{full_name}" {disambiguator} (lawsuit OR "ponzi" OR embezzlement)

Precise wrongdoing terms keep alert volumes manageable. For individuals with common names, add a disambiguator such as employer, city or industry, and route anything ambiguous to a person, not an auto-dismiss rule. Screen in the languages relevant to the subject, not only English.

Cadence by risk tier

The frequency is your policy decision. A starting shape many teams test:

The screening call

A single check for one subject in one market:

curl -X POST https://api.answerline.dev/v1/monitor/google/news \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "\"Jane Example\" (fraud OR \"money laundering\" OR bribery)",
    "country": "GB",
    "hl": "en"
  }'

The response carries result.newsResults[] with position, title, link, snippet, source, date and page. Request fields are on the Google News engine page. The same screen against Google Search uses POST /v1/monitor/google and reads result.organicResults[], which also surfaces court-reporting sites, regulator pages and blogs that News does not cluster.

For a book of customers, submit async tasks in batches of up to 500 with a webhook and an idempotency key per subject, template and screening cycle. The adverse media screening use case has the full batch, webhook, storage and matching code; this article does not repeat it.

From hit to trigger: the delta and re-scoring logic

When a completed task arrives, the pipeline decides whether anything new and material happened.

from urllib.parse import urlsplit, urlunsplit

def canonical(url):
    p = urlsplit(url)
    return urlunsplit((p.scheme, p.netloc.lower().removeprefix("www."), p.path.rstrip("/"), "", ""))

def new_hits(subject, news_results, seen_urls):
    names = [n.lower() for n in subject["names"]]
    for item in news_results:
        url = canonical(item["link"])
        if url in seen_urls:
            continue
        text = f"{item.get('title', '')} {item.get('snippet', '')}".lower()
        if not any(n in text for n in names):
            continue
        yield {
            "subject_id": subject["id"],
            "url": url,
            "title": item.get("title"),
            "snippet": item.get("snippet"),
            "publisher": item.get("source"),
            "displayed_date": item.get("date"),
        }

Every yielded hit goes to a reviewer, never straight to a rating change. The reviewer records three judgments that the EBA and Wolfsberg material both point to:

1. Identity match. Is this article about our customer, or someone with the same name?
2. Credibility. Quality and independence of the publisher, and whether other independent outlets report the same allegation.
3. Materiality. Does the information indicate heightened financial crime or reputational risk?

Only a hit that passes all three becomes a trigger event. A trigger then does two things in the orchestration layer: it recalculates the customer risk score with the new factor, and if the score crosses a threshold or the category is severe, it opens a targeted review. A targeted review asks for what the event makes relevant, for example source of funds after a fraud allegation, rather than repeating the whole onboarding file.

Using AI answers carefully

Assistants such as ChatGPT or Gemini will summarise what they find about a name. That is useful for a reviewer who wants a quick orientation on a corporate customer, and risky for anything else. An answer can merge two people with the same name, present old allegations as current, or state things its sources do not say.

If you include AI answers, store them as context attached to the review item, read the sources they cite, and base every decision on the underlying articles. Never let an AI answer create a trigger event on its own.

The audit trail pKYC needs

An event-driven program has to show why a customer was or was not reviewed. For each screening run, store:

• subject id, template id, engine, market, language, and the task id
• the request payload and the task completion time
• every result shown to a reviewer, with the reviewer, decision, reason and timestamp
• the risk score before and after any trigger, and the review it opened

Store the task id with every hit. It ties any decision back to the exact check that produced it.

Coverage is a control

Because a silent feed looks like a quiet book, measure the feed itself:

Alert on coverage dropping, not only on hits appearing. GET /v1/async/status and the task status on each webhook give you the raw numbers.

Cost planning

Credits per async task: Google News 3, Google Search 3, each extra results page 2. A ChatGPT question is 5.

Multiply by languages and markets where they apply. Compare the totals with plans on the pricing page, and prototype templates on the free tier’s 500 monthly credits before committing to volume. The dominant cost in most programs is reviewer time, not data, which is why template precision and URL suppression matter more than query price.

Pitfalls

• Rescreening the full history every cycle. Reviewers see the same old articles; suppression by URL fixes it.
• Auto-dismissing on name mismatch alone. Transliterations and middle names break exact matching; send ambiguous cases to people.
• English-only templates for customers whose coverage is in other languages.
• Treating a feed outage as a quiet period. Track coverage.
• Letting a hit change a rating without review. Identity, credibility and materiality are human judgments.
• Assuming the data is complete. Search and news results show what was published and indexed for that query at that moment. They are not an archive.

Related: third-party risk monitoring applies the same pattern to vendors, and the Google News API guide covers the endpoint in more depth.

Start with the quickstart to run your first screen.

Keep reading