Ongoing AML Monitoring When Watchlists Change

A customer who cleared last year can be designated tomorrow. That sentence is the whole argument for ongoing monitoring, and teams still ship onboarding-only screening because the signup flow was the ticket that got staffed.

Onboarding screening checks the customer before activation. Ongoing screening checks the relationship again as watchlists change. Transaction monitoring evaluates payment activity. Naiza supports all three, connecting list evidence and transaction alerts with investigation cases.

Keep the customer key boring

Keep customer.externalId stable so watchlist updates connect new screening results to the original customer record and case history. When a list update produces a new screening, it lands on the same customer record, the same case thread, and the same support view as the signup screen. Store each screening ID alongside the existing investigation notes and support history.

Persist every screening id, including AUTO_CLEAR results. This gives investigators a record of completed checks as well as the matches that entered review.

Alert volume follows list deltas, not signup volume. A quiet week of onboarding can still produce a busy morning if a publisher updates a file. Staff a REVIEW queue for that shape of work. Do not page the company for AUTO_CLEAR. Do not invent a war room because a batch job completed.

Real-time where someone is waiting

Use a synchronous screen when the user is waiting: signup, a first payout, a new counterparty. That call should block activation or fulfillment the same way a payment authorization does. The user can tolerate a pending state if support can explain it.

Naiza automatically re-screens existing customers on watchlist updates. Keep customer identifiers stable so later matches join the existing record and case history. The AML integration guide covers screening and event integration.

If you are choosing architecture, onboarding versus ongoing AML is the split. Do not hide a nightly batch behind a “real-time AML” slide. Real-time is for the person in the app. Batch is for the names already in the ledger.

Handling matches from overnight re-screening

Route new potential matches to REVIEW, open a case, and notify the assigned reviewer. Apply holds and escalation through your configured workflow, with identity evidence supporting each action.

Show the previous screening result, new source entries, and stored identity fields in the case. Investigators can compare the evidence and record the outcome. See watchlist screening versus OFAC-only coverage for source coverage.

Run the first months in shadow if you have never measured overnight volume. Store the new screening ids. Do not change customer-facing state until you know how many REVIEW items a typical list update creates. Then enforce holds on the flows you staffed. That is the same posture as shadow mode versus enforcing.

Combine list monitoring with full transaction monitoring

Naiza supports full transaction monitoring alongside automatic watchlist re-screening. Combine payment rules, counterparty checks, and new list matches in the investigation timeline. Label each alert source so reviewers can connect customer identity with transaction behavior.

Verify the workflow on an existing customer: retrieve the latest screening, the source update, related transaction alerts, and the recorded investigation outcome. This establishes a traceable history from onboarding through ongoing monitoring.