Ongoing AML Monitoring When Watchlists Change
Onboarding screening is necessary and not sufficient. Re-screen the book when lists update, keep stable external ids, and route overnight hits to REVIEW.
A customer who cleared last year can be designated tomorrow. **Onboarding screening** checks a name before you activate them. **Ongoing monitoring** re-checks that name when watchlists change. Skipping either leaves a gap. Transaction monitoring (payment patterns) is a third control—do not rename it as list re-screening.
Keep customer.externalId stable. Overnight hits must join to the same case as the original screen. Alert volume follows list deltas, not signup volume. Staff a REVIEW queue. Do not page the company for AUTO_CLEAR.
Real-time plus batch
Use a synchronous screen when the user is waiting (signup, payout). Use batch screening or event-driven re-screening for the existing book. Naiza AML product copy describes continuous monitoring with automatic re-screening on list updates—confirm the current behavior in the AML docs before writing it into a policy memo.
Definitions: ongoing monitoring, watchlist screening. Architecture: onboarding vs ongoing AML and real-time vs batch.