Skip to main content
DoneThat

AI Adoption GuideBankingReview

Adverse media continuous monitoring

LLM agent monitors named-entity news feeds and flags new negative hits on existing customers, triggering a CDD refresh workflow.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

A usable hit is a cite that starts refresh, not an exit

Continuous adverse-media monitoring exists to catch negative reporting on people and entities you already bank, after onboarding adverse media screening has stopped looking. The control works when a new article is tied to the right customer with a name-match rationale, a source, and a date, and that package opens a CDD refresh. It fails when the file auto-exits the customer, treats a namesake as a match, or invents an allegation the article does not state.

The output is not a new risk rating. The output is the article, the reason this customer is the person named in it, the date it ran, and a CDD task. Exit, restriction, or no action come after that review.

Onboarding screening is a snapshot. Customers keep appearing in news after the account is live. Skipping later hits because the customer was already screened is how a true hit never reaches the file. Continuous monitoring should feed perpetual KYC refresh the same way a trigger event does: with evidence, not with a score dressed up as a decision.

Match the named person, not the named string

A news feed will return the same legal name for unrelated people. Usable matching needs enough identifiers that a second analyst can reproduce the yes or no. Typical anchors: full legal name plus at least two of date of birth, nationality or country of residence, known aliases, employer or role, and a unique customer or entity identifier already on the CDD file. For corporates, match the legal entity and the named natural person separately. A director hit is not a company hit, and a similar trading name is not your customer.

Name-only matching is how namesakes enter the queue. If the article names someone in one city and your customer has the same legal name in another city, with a different date of birth and no overlapping employer, that is not a match. Record the identifiers you compared and the mismatch. Do not promote the article onto the customer record for awareness. Awareness without a match pollutes the file and later looks like you treated the namesake as your customer.

Illustrative example: the book includes a private-banking customer, Daniel Reeves, born 1974, UK national, director of a Manchester logistics company. An agent flags a regional news piece dated 12 March about a Daniel Reeves charged in connection with a property fraud in Bristol. The article gives an approximate age in the mid-thirties and an address in Bristol. Your customer's date of birth, city, and employer do not align. The correct output is a rejected match with those points written down. The incorrect outputs are attaching the charge to the Manchester customer, or silently discarding the article without recording why it was not him, so nobody can see you considered it.

When identifiers do align, write the rationale the same way. Name, date of birth, and stated role as finance director of an entity already on file match the customer record; nationality in the article is consistent. That sentence is the name-match rationale. Without it, CDD cannot tell a true hit from a namesake someone was too busy to reject.

Cite the article, then open CDD refresh

A quality hit carries four things into the refresh workflow: the source (publication or wire, not a screenshot with no masthead), the publication date, a stable locator the bank can retrieve later (URL, wire ID, or vendor document ID), and a short extract of what the article actually alleges, in the article's words. Paraphrase only to name the topic, for example regulatory enforcement or a fraud charge. Do not upgrade "under investigation" into "convicted," and do not add facts the piece does not contain.

That package is what opens CDD refresh. The monitoring step does not re-rate the customer, freeze the account, or recommend offboarding. Those are CDD decisions, and where the facts warrant it, financial-crime case decisions. If the article also suggests unusual flows, treat that as a separate question for AML transaction network monitoring or an investigation case. Do not collapse news, transactions, and exit into one automated path.

The CDD officer should see the identifiers used in the match, the article cite, and a prompt to confirm or reject the match before they change risk rating, source-of-funds narrative, or relationship status. If they reject the match, close the hit as a namesake or as insufficient identifiers, not as no adverse media. If they accept the match, they run refresh: update the narrative, decide whether the allegation is material under policy, and only then consider restriction or exit.

Materiality is policy, not sentiment. A blog post repeating a rumor, an anonymous forum thread, and a named enforcement notice from a competent authority are not the same class of source. Continuous monitoring can surface all of them. The cite must make the class obvious so CDD does not treat a blog as a charging document.

Failure modes: namesakes, blogs as exits, and the onboarding skip

Same-name false hit. The feed is doing its job when it returns every Daniel Reeves. The control fails when those returns become customer-level flags without the identifier test. Name collision is normal in retail books and for common surnames across jurisdictions. The fix is a required match rationale, not a tighter news query that drops true hits you have not seen yet.

Exiting from a blog post. Negative language is not a finding. Opinion pieces, affiliate watchdog blogs, and recycled social posts often restate one original article with extra adjectives. If the only source is a blog, say that in the cite. Do not auto-exit, auto-restrict, or write that the customer is involved in the alleged conduct. CDD may still note the blog and look for a primary source. Until a primary source exists, the allegation is unverified reporting, not a fact you added in the case notes.

Skipping a true hit because onboarding screening was already done. This is a design error, not a matching error. Teams treat adverse media screening as a one-time gate and assume the customer is clear until the next periodic review. A customer who screened clear at account opening can be named in enforcement coverage months later. If that coverage never opens perpetual KYC refresh, you have a documented screen at day zero and a silent miss thereafter. Wire the hit to refresh even when the last periodic KYC is recent. Recency of KYC is not evidence that the new article is irrelevant.

A quieter miss: the agent finds a true article, then summarizes it into a charge the journalist did not make. Invented allegations are worse than missed articles because they create a false file history. If the piece is ambiguous, quote the ambiguous sentence. Do not resolve the ambiguity for the journalist.

These failures also distort downstream work. A namesake on the file can later look like prior knowledge in AML case disposition at funding. A skipped post-onboarding hit is a gap you cannot reconstruct unless you keep rejected-match logs as well as accepted ones.

Vendor feeds are inputs, not the decision

News and entity-resolution products from vendors such as Dow Jones, NICE Actimize, and Temenos sit in this control as feed, screening, or core-banking workflow classes. They do not replace identifier matching, certify that an article is about your customer, or decide exit. Use them as the source of candidate articles and, where already licensed, as the retrieval path for the cite. Procedures still require source, date, name-match rationale, and a human CDD decision.

Do not rank those vendors here, and do not assume a feature you have not contracted. Banks wire different combinations: a media database, an AML platform alert, a core workflow queue. The quality bar is the same regardless of which class produces the candidate: no namesake as a match, no allegation the article does not state, no automated offboarding.

The agent's job stops at a cited, identifier-backed hit in the refresh queue. CDD judgment starts there.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first