Batch Screening
Batch screening is the process of running an entire existing customer base, or a defined subset of it, through sanctions, PEP, and watchlist checks at scheduled intervals, rather than checking one customer or transaction at a time as it happens. It’s the mechanism that turns ongoing monitoring’s rescreening requirement into something operationally executable across thousands or millions of customer records, and it runs on genuinely different architecture from real-time screening, not just a slower version of the same check.
Key takeaways
- Batch screening runs an entire customer base through checks at scheduled intervals, rather than one record at a time as it happens.
- Three real triggers exist: a routine schedule, a reference data update (new sanctions designation), and regulatory or internal examinations.
- Rescreening cadence should be risk-based: commonly daily or monthly for high-risk customers, quarterly for standard-risk, and less frequent for genuinely low-risk relationships.
- “Screening” (point-in-time identity checks) and “monitoring” (ongoing behavioural analysis) are distinct concepts, not interchangeable terms.
- Event-driven monitoring closes the lag window inherent to fixed-interval batch scheduling, which is why higher-risk portfolios increasingly favour it for sanctions data.
- Batch runs generate alerts in bulk, requiring prioritised triage, unlike real-time alerts, which arrive individually and block a specific transaction.
- Beyond routine rescreening, batch screening handles vendor list checks, system migrations, and retrospective transaction analysis.
On this page
What batch screening actually isThe three real triggers for a batch runHow rescreening cadence actually gets setWhy “screening” and “monitoring” aren’t the same wordBatch vs event-driven: a genuine architectural differenceWhy batch runs generate alerts in bulk, and what that changesWhere batch screening gets used beyond routine rescreeningThe false positive challenge, at batch scaleBuilding a batch screening process that holds upFAQsRead more
What batch screening actually is
Batch screening runs large volumes of customer or transaction data against sanctions, PEP, and watchlist reference data at scheduled intervals, rather than checking each record individually as it occurs. It’s how a firm re-screens its entire existing customer base against updated reference data, since running that same volume through a live, transaction-by-transaction check would be neither practical nor necessary for records that aren’t part of an active transaction at that moment.
The three real triggers for a batch run
Batch screening runs get triggered by three distinct events, not just a generic calendar. A scheduled periodic run happens on a fixed cadence, nightly, weekly, or monthly depending on risk tier, re-checking the customer base regardless of whether anything specific prompted it. A reference data update triggers an unscheduled run: when OFAC, the UN, or the EU publishes a new or amended sanctions list, a firm needs to rescreen its full database against the updated data, not wait for the next scheduled cycle. A regulatory or internal examination often triggers a dedicated run specifically to demonstrate current, functioning ongoing monitoring ahead of an audit or inspection.
How rescreening cadence actually gets set
Cadence follows the same risk-based logic that governs review frequency generally. Higher-risk customers, PEPs, high-risk jurisdictions, complex structures, commonly get rescreened daily or monthly. Standard-risk customers are typically rescreened quarterly. Lower-risk relationships might reasonably be rescreened annually. None of these intervals is a hard international mandate; they reflect a firm’s own documented risk assessment, and a firm extending an interval beyond what its risk assessment supports needs to be able to explain why.
Why “screening” and “monitoring” aren’t the same word
This distinction gets blurred constantly, and it’s worth being precise about. Screening is a point-in-time or event-driven check of identity against static or periodically refreshed reference data, checking who someone is against a list. Monitoring is the ongoing behavioural analysis of activity, transaction patterns, account usage, against expected behaviour, checking what someone is doing against a baseline. Batch screening is a specific technique inside the broader screening category; it isn’t itself transaction monitoring, even though both feed into the same overall ongoing monitoring programme.
Batch vs event-driven: a genuine architectural difference
Two real technical models exist for keeping screening current. Scheduled batch rescreening re-runs the full customer list against updated reference data at a fixed interval; a new match discovered between one scheduled run and the next simply isn’t known until the next batch executes, creating a real, bounded window of lag. Event-driven monitoring instead watches the reference data itself for changes and pushes an alert the moment a match appears, without waiting for any scheduled job to run. Event-driven monitoring closes the lag window that batch scheduling structurally can’t avoid, which is why higher-risk portfolios increasingly move toward event-driven architecture for sanctions data specifically, while retaining batch cycles for lower-urgency categories like periodic KYC refresh.
Why batch runs generate alerts in bulk, and what that changes
A single batch run against a large customer base can generate hundreds or thousands of alerts at once, all landing on a compliance team’s queue simultaneously, in sharp contrast to real-time screening, where alerts arrive one at a time as individual transactions occur. That difference genuinely changes the operational challenge: a real-time alert needs rapid, individual triage before a payment can proceed, while a batch run’s alert volume needs to be prioritised and worked through systematically, without a live transaction sitting blocked and waiting on any single decision.
Where batch screening gets used beyond routine rescreening
Beyond periodic customer rescreening, batch screening is the standard tool for a handful of other recurring situations: screening an entire vendor or counterparty list during a procurement or credit review cycle, screening a full customer base migrating into a new system or after a merger or acquisition, and historical transaction analysis when investigating a pattern retrospectively rather than checking activity as it happens.
The false positive challenge, at batch scale
Every match a batch run surfaces still needs the same disposition judgement a real-time false positive requires, but arriving in bulk changes how that judgement gets managed operationally. Firms running batch screening at scale generally need workflow tooling that can prioritise alerts by risk and route them efficiently, rather than working through a large queue in the order it happened to be generated, since not every alert in a large batch carries the same urgency.
Building a batch screening process that holds up
A batch screening process that holds up under review generally documents three things clearly: the specific cadence applied to each risk tier and the rationale behind it, the triggers, beyond the routine schedule, that launch an unscheduled run, and evidence that batch-generated alerts actually get worked through and dispositioned in a reasonable timeframe rather than accumulating in an unreviewed backlog.
Automate risk-tiered rescreening
Set up screening cadence calibrated to actual customer risk, not one uniform schedule.
Frequently asked questions
What is batch screening?
Batch screening runs an entire existing customer base, or a defined subset, through sanctions, PEP, and watchlist checks at scheduled intervals, rather than checking one customer or transaction at a time as it happens.
What triggers a batch screening run?
Three main triggers: a scheduled periodic cadence, an update to underlying reference data such as a new sanctions designation, and regulatory or internal examinations requiring demonstrated current monitoring.
How often should batch rescreening happen?
Cadence follows a risk-based approach: higher-risk customers are commonly rescreened daily or monthly, standard-risk customers quarterly, and lower-risk relationships potentially annually, though the specific interval should reflect a documented risk assessment.
Is batch screening the same as screening in general?
Batch screening is one specific technique within the broader screening category. Screening itself is a point-in-time or event-driven identity check, distinct from monitoring, which is ongoing behavioural analysis of activity.
What is the difference between batch screening and event-driven monitoring?
Batch screening re-runs the full customer list at fixed intervals, creating a bounded lag window between updates. Event-driven monitoring pushes an alert immediately when reference data changes, closing that lag entirely.
Why do batch screening alerts need different handling than real-time alerts?
Batch runs can generate hundreds or thousands of alerts simultaneously, requiring prioritised, systematic triage, while real-time alerts arrive individually and need rapid disposition before a specific transaction can proceed.
What else is batch screening used for besides periodic rescreening?
Screening an entire vendor or counterparty list during procurement or credit review, screening a customer base during a system migration or merger, and retrospective historical transaction analysis.
Read more: our ultimate guides, whitepapers and templates
Related guides and resources to help you act on what you just read.
Last reviewed July 19, 2026 · 9 min read · Written for compliance and risk professionals · By the WhoWiki editorial team
Key takeaway: Batch screening is the process of running an entire existing customer base, or a defined subset of it, through sanctions, PEP, and watchlist checks at scheduled intervals, rather than checking one customer or transaction at a time as it happens. It’s the mechanism that turns ongoing monitoring’s rescreening requirement into something operationally executable across thousands or millions of customer records, and it runs on genuinely different architecture from real-time screening, not just a slower version of the same check.