Ongoing Monitoring After Onboarding: Re-Screening Customers Against Updated PEP and Sanctions Lists

Most KYC programs put their effort into the onboarding moment. A customer submits an ID, passes document authentication and a face match, gets screened against PEP and sanctions lists, and is approved. Then the record goes quiet.

The lists do not stay the same. Sanctions designations are added after geopolitical events. People take public office, change roles, or leave it. A customer who was clean on day one can become a match months later without doing anything differently on your platform.

Ongoing monitoring closes that gap. This post covers how to design it: what to store, when to re-screen, and how to handle alerts. It does not cover how screening works in general, which is explained in our earlier posts on AML and PEP screening.

Why a One-Time Check Is Not Enough

Regulatory frameworks built on FATF guidance generally treat customer due diligence as an ongoing obligation rather than a single event. The details vary by jurisdiction and sector, so confirm the specifics with your compliance counsel. The core idea is consistent. You are expected to know whether an existing customer's risk profile has changed.

Customer risk changes in three ways:

• The customer changes status. Someone becomes a PEP, a relative or close associate of a PEP, or a sanctioned party.
• The lists change. New designations, delistings, and corrections to names, aliases, or dates of birth.
• Your data changes. A customer updates their legal name, nationality, or address, and the new details need screening.

A monitoring program has to account for all three.

What You Need to Store to Re-Screen

You cannot re-screen a customer if you have discarded the attributes the screen depends on. At minimum, screening generally relies on:

• Full legal name, including any transliterations captured during OCR
• Date of birth
• Nationality or issuing country of the ID document
• The customer's internal ID, so alerts map back to an account

This creates a tension with data minimization. You should keep what you need for ongoing due diligence and no more. Raw document images are usually not required for re-screening. Structured fields extracted at onboarding typically are.

Data extracted from the MRZ or barcode is especially useful here. It tends to give you a consistent, machine-readable name format and date of birth, which reduces noise when you screen the same person again months later.

Choosing a Re-Screening Cadence

There is no single correct schedule. Most teams combine scheduled sweeps with event-driven triggers.

Scheduled Re-Screening

A periodic job re-screens your customer base against current lists. Tie the frequency to risk tier:

• Higher-risk customers, such as existing PEPs, customers in higher-risk jurisdictions, or high-value accounts, are screened more often.
• Standard-risk customers are screened on a regular schedule your compliance team defines and documents.
• Dormant accounts are still screened. Reactivating a sanctioned party's account is exactly the scenario monitoring exists to prevent.

Document the rationale for each interval. Auditors will ask why you chose it.

Event-Driven Re-Screening

Some events should trigger an immediate check regardless of schedule:

• A change to name, nationality, or date of birth on the account
• A new document submitted for re-verification
• A large or unusual transaction, if your transaction monitoring flags it
• Publication of a major new sanctions package affecting a region where you have customers

Event triggers catch the cases that a quarterly or annual sweep would miss.

Building the Workflow

A practical re-screening pipeline has four stages.

1. Select

Query the customers due for screening based on risk tier, last-screened date, and any pending event triggers. Keep a last_screened_at timestamp and a screening_version on each record so you always know when and against what a customer was last checked.

2. Screen

Send the stored attributes to your AML/PEP screening service. Batch the calls and respect rate limits. Log the request, the response, and the timestamp. Many teams never get around to this part, but the screening log is your evidence that monitoring actually happened.

3. Compare

Compare new results against the previous result for that customer. You mainly care about differences:

• A new potential match that did not exist before
• A changed match, such as a PEP whose role or risk category has been updated
• A previous match that has disappeared, such as a delisting

Only new or changed results need human attention. Repeatedly surfacing a match that was already reviewed and cleared buries analysts in duplicate work.

4. Review and Act

Route new potential matches to a review queue with the customer data and match details side by side. Analysts confirm or dismiss each one and record a reason. Confirmed matches feed into your escalation process. Depending on the list and your policy, that may mean enhanced due diligence, restricting the account, or reporting.

Managing False Positives Over Time

Re-screening multiplies the number of times common names get checked. Without controls, alert volume grows with your customer base.

Practical controls include:

• Using date of birth and nationality as matching criteria, not just name
• Suppressing previously cleared matches unless the underlying list entry changes
• Keeping a whitelist with an audit trail, so every suppression is traceable to a reviewer and a reason
• Reviewing your matching thresholds periodically with your compliance team

The goal is that every alert reaching an analyst is one that deserves a fresh look.

Making It Auditable

When a regulator or auditor reviews your program, they generally want to see three things: a documented policy, evidence that you followed it, and a record of how alerts were resolved. Design your data model around those needs. Keep timestamps on every screen, preserve the history of results rather than overwriting them, and store reviewer decisions alongside the alerts they relate to.

Security matters as well. Screening data is sensitive personal data, so choose vendors with appropriate controls such as ISO 27001 certification. Organizations with strict data residency requirements can consider on-premise deployment through ID Fort.

The Takeaway

Onboarding verification shows that a customer was who they claimed to be, and that they were clean on the day they joined. Ongoing monitoring shows that you are still confident about them today. Store the right fields, re-screen on a risk-based schedule plus event triggers, surface only what has changed, and log everything. Built this way, re-screening becomes a routine background job that holds up under audit instead of a scramble during one.