September 10, 2026

Batch vs Real-Time Screening: Trade-offs

Axle Team

Key takeaways

Batch vs real-time screening is not an either/or decision. Real-time screening stops payments before execution; batch rescreening catches list updates and customer-data changes across the existing book. Mature programs run both.
The binding constraint on real-time screening is adjudication speed, not detection: every alert sits on the payment's critical path.
The binding constraint on batch is alert clustering: a major OFAC designation action can dump thousands of rescreening alerts into the queue overnight.
Wolfsberg treats screening frequency as a risk-based decision — daily rescreening where data changes fast, longer intervals where exposure is low.
OFAC's own root-cause list for enforcement includes screening software that simply wasn't updated with new SDN designations. List-update latency is a compliance exposure, not an IT detail.

Batch vs real-time screening: what each control actually does

Real-time screening checks a payment or customer against sanctions lists before the transaction executes, so a true match can be stopped. Batch screening rescreens a full population on a schedule — typically overnight — to catch list updates and data changes. Most programs need both: real-time for payments and onboarding, batch for ongoing rescreening.

The batch vs real time screening question, in other words, is really a question about which risk each mode addresses. Real-time transaction screening exists because a sanctions violation happens at the moment value moves. Batch rescreening exists because the world changes after you've onboarded someone: lists get new designations, customers change names and beneficial owners, and yesterday's clean record is today's true match.

The Wolfsberg Group's sanctions screening guidance draws the line cleanly:

"Transaction screening should be performed at a point in time where a transaction can be stopped and before a potential violation occurs."
— Wolfsberg Guidance on Sanctions Screening, 2019

That is the definitional case for real-time: screening after execution isn't a control, it's an incident report.

Where real-time is non-negotiable

Cross-border payments are the clearest case. Sanctions liability is strict, the counterparties are outside your KYC perimeter, and the payment is stoppable right up until release. Wolfsberg again:

"Screening cross-border payments prior to completing the transaction is common practice and known as screening in real-time. By contrast, screening domestic payments in real-time may be unnecessary for FIs that are subject to the same local regulatory requirements, including the jurisdictions' local sanctions and KYC requirements when on-boarding clients."
— Wolfsberg Guidance on Sanctions Screening, 2019

The second sentence matters as much as the first. Real-time screening of purely domestic payments between fully KYC'd parties often adds latency and false positives without adding detection — a risk-based decision you can document rather than a corner you're cutting. Crypto platforms should read "cross-border" broadly: a withdrawal to an external wallet leaves your perimeter the same way a SWIFT payment does.

Where batch earns its keep

Batch rescreening answers a different question: is anyone already in my book now sanctioned, or newly matchable because their data changed? Wolfsberg's guidance on frequency is explicitly risk-based:

"Where either internal or external data sets change frequently, periodic screening may be as often as daily, but longer intervals between periodic rescreening may be acceptable in situations where change is less frequent or the risk of a potential sanctions exposure is low."
— Wolfsberg Guidance on Sanctions Screening, 2019

The failure mode batch protects against is well documented. OFAC's Framework for Compliance Commitments lists screening software faults among the root causes it sees in enforcement actions — including organizations that "failed to update their sanctions screening software to incorporate updates to the SDN List or SSI List" (A Framework for OFAC Compliance Commitments). If your rescreening cycle runs weekly and OFAC designates on Tuesday, you're exposed until the following run — and that gap is on you, not your vendor.

The trade-offs, side by side

What it protects — Real-time screening: Value in motion — payments, withdrawals, onboarding. Batch screening: The existing book against list and data changes.
Latency requirement — Real-time screening: Seconds; alerts block the transaction. Batch screening: Hours; alerts queue for review.
Alert arrival pattern — Real-time screening: Distributed across the day. Batch screening: Clustered after each run or list update.
Match calibration — Real-time screening: Tighter — every false positive delays a payment. Batch screening: Can run wider fuzzy logic; review is asynchronous.
Main operational risk — Real-time screening: Adjudication SLA; payment delays and customer friction. Batch screening: Alert spikes after major designation actions.
Typical failure — Real-time screening: Understaffed real-time queue forces loose matching. Batch screening: Rescreening cadence lags list updates.

The trade-off nobody prices in: alert clustering

Here's the operational reality that rarely shows up in vendor comparisons. The real cost difference between the two modes isn't detection coverage — configured properly, both find the same names. It's the shape of the alert workload. Real-time screening spreads alerts across the day but attaches a seconds-to-minutes SLA to each one, so you staff for peak payment traffic. Batch inverts it: no SLA measured in seconds, but a major designation action — think a large Russia-related tranche — can turn tonight's rescreening run into several thousand alerts hitting the queue at once, most of them fuzzy name matches against a book that hasn't changed. Teams that staff for the average batch morning quietly build a multi-week backlog on those days, and a backlog on sanctions alerts is a very uncomfortable thing to explain. When we scope screening operations, we model the p99 morning-after-a-designation day, not the median day — that number, not average alert volume, decides whether the operation holds.

This is precisely where agentic adjudication changes the calculus: an AI screening agent that clears the obvious non-matches with documented rationale absorbs the spike without a hiring plan built around worst-case days. The ROI calculator lets you run that math against your own alert volumes.

Choosing your architecture: three questions

What can still be stopped? Anything stoppable at screening time (payments, withdrawals, onboarding decisions) defaults to real-time. Anything already settled belongs to batch rescreening.
How fast do your data sets change? High-churn customer data or frequent list updates push batch frequency toward daily, per Wolfsberg. Document the cadence decision and its rationale.
Can your team clear the alerts each mode produces? A real-time control with a 12-hour adjudication queue is batch with extra steps. Match calibration, staffing, and automation have to be designed per mode — not copied from one to the other. Axle's platform treats these as separate workflows for exactly this reason.

FAQ

Is real-time sanctions screening required by regulation?

No U.S. regulation mandates real-time screening by name. OFAC liability is strict — processing a prohibited transaction is a violation regardless of screening architecture — so screening before execution is the only reliable way to avoid violations on stoppable transactions. Regulators evaluate whether your screening program is risk-based and effective, not which architecture label it carries.

How often should customers be rescreened against sanctions lists?

Wolfsberg's guidance ties frequency to how often your data and the lists change: daily where change is frequent, longer intervals where exposure is low. In practice, most institutions rescreen the full book against list deltas within 24 hours of a list update, and treat trigger events (name changes, ownership changes) as immediate rescreening triggers.

Does batch screening create regulatory exposure between runs?

Yes — if a designated party transacts between your last run and the next, the transaction is still a violation. That's why stoppable, outbound value movement should be screened in real-time, with batch reserved for rescreening populations where no transaction is pending.

Baley, Axle's screening agent, adjudicates both real-time hits and batch rescreening spikes with a documented rationale on every disposition. See how Baley works →

Batch vs Real-Time Screening: Trade-offs

More from the blog