For teams that maintain an existing customer base, not just onboarding checks
When a sanctions list changes, who do you re-screen?
Screening at onboarding answers a question about one moment. Lists move afterwards. When a source adds, amends or removes a listing, some, but rarely all, of your existing customers need to be re-screened, quickly, with a record that it happened. This page turns a source change into a bounded re-screening job instead of a full-book rescan or a missed obligation.
Primary sources
- Regulation (EU) 2024/886, Article 5d, immediate re-verification
For in-scope instant credit transfers, PSPs must re-verify their users against the EU list immediately when a new or amended listing enters into force, the clearest primary-law expression of re-screening on a source change.
- Directive (EU) 2015/849, Article 13, ongoing monitoring
Customer due diligence includes ongoing monitoring of the business relationship, which supports re-assessing existing customers when the risk picture, including sanctions status, changes.
- EBA/GL/2024/14, controls and alert handling
Expects current-list ingestion and disciplined handling of the alerts a list change produces, rather than deferring them to the next periodic review.
What actually triggers a re-screen
- A new entity or person is added to a source you rely on.
- An existing listing is amended, a new alias, a corrected name, a new date of birth, which can change who it matches.
- A source you depend on comes back after being unavailable, so a population screened during the outage now has coverage it lacked.
- A de-listing, which is not a re-screen risk but is an evidence event: you should record that a previously-flagged customer is no longer listed.
Scope the population, don't rescan the book
Re-screening your entire customer base on every list change is slow, noisy and expensive, and it buries the one match that matters under thousands of unchanged results. The change itself tells you who to look at.
A single added entity implies a narrow candidate population, names that could plausibly match the new listing. Scoping to that population turns a daily stream of list changes into a manageable, evidenced job.
- 1Detect the source change from a change feed, and capture what changed and when.
- 2Derive the affected population, the customers whose names could match the added or amended listing, rather than the whole book.
- 3Re-screen that population against the current list version, and record the version and outcome.
- 4Route new matches to review; record de-listings as evidence events; keep the whole run reconstructable.
Limitations
- Scoping depends on knowing precisely what changed. A source that only publishes a full snapshot, with no diff, forces a broader rescan or a computed diff, and the quality of the scoping is only as good as the change data.
- Detecting changes requires a reliable change feed. A change you never observe is a re-screen you never run; freshness and source-health monitoring are prerequisites, not extras.
- Immediate re-verification obligations (for in-scope instant payments) are stricter than periodic-review cycles. Do not fold a same-day obligation into a monthly batch.
- This page is an implementation reference, not legal advice.
Build the evidence, not just the alert
Questions
Do I have to re-screen everyone when a list changes?
Usually not, and doing so hides the signal. The change identifies a narrow affected population; re-screen that population against the current list rather than the whole customer base.
How fast must re-screening happen?
It depends on the obligation. For in-scope EU instant payments, re-verification is immediate on a new or amended listing. For general ongoing monitoring, it is risk-based, but a same-day listing should not wait for a periodic cycle.
How does Verifex support this?
Verifex surfaces detected source changes and live source freshness, and preserves the evidence for each re-screening run. Where a source was unavailable, that gap is visible rather than assumed away.
This page is an implementation reference for engineering and compliance teams. It is not legal advice and does not certify any regulatory outcome. Regulatory obligations, their interpretation, and the decision to treat any result as clear remain yours. Verifex supports the workflow and preserves the evidence; it does not make the compliance decision.