Real-Time vs. Batch Sanctions Screening: API Architecture Tradeoffs for Compliance Engineering Teams

Ask a compliance engineering team whether their screening should be "real-time," and most will say yes without thinking much further — faster obviously sounds better. But real-time and batch screening aren't the same system running at different speeds. They answer different questions, cover different populations of counterparties, and optimizing one at the expense of the other is a common architecture mistake.

1. Two Fundamentally Different Screening Patterns

Real-time (inline) screening runs synchronously, in the request path of a live transaction: releasing a wire, approving a checkout, admitting a new account. The result gates whether the action proceeds. Latency here is a product-facing constraint — it sits in a user's or a payment network's critical path.

Batch (or update-triggered) screening runs asynchronously, independent of any single transaction: rescreening an entire existing customer or vendor base whenever a sanctions list changes, or reconciling a backlog of records against an updated list. Nothing is waiting on the result in real time; the goal is coverage and completeness, not latency.

Treating these as one system with a speed dial misses the actual distinction: real-time screening answers "is this new counterparty clean, right now, before I let this proceed?" Batch rescreening answers "has anything changed about a counterparty I already approved?" A counterparty can pass real-time screening cleanly on Monday and be added to the SDN list on Wednesday — only batch rescreening, triggered by that Wednesday list update, catches it.

2. When Real-Time Is Actually Required

Real-time screening belongs wherever a decision needs to be blocked pending the result:

• Releasing a payment or wire transfer before funds move.
• Gating account creation or KYC/KYB onboarding before granting access.
• Checkout or order-acceptance flows where shipping to a restricted party needs to be prevented before fulfillment begins.

In each case, the cost of a false negative (letting a bad actor through) is immediate and hard to reverse, so the check has to happen before the action, not after.

3. When Batch Rescreening Is the Right Tool

Batch rescreening solves a structurally different problem: an existing relationship that was compliant at onboarding can stop being compliant without any new transaction triggering a fresh check. Regulatory expectations around ongoing monitoring exist precisely because sanctions designations are forward-looking events that don't wait for your next transaction with that party. A well-built compliance program rescreens its existing book whenever the underlying list changes — not on a fixed calendar cadence alone, but triggered by the list update itself, so the detection lag between "designated" and "flagged internally" stays as short as possible.

Running full inline re-checks of your entire existing customer base on every single list update, instead of a dedicated batch process, is usually the wrong tradeoff: it turns an update that affects a handful of records into a load spike across your real-time path for zero benefit, since none of those existing relationships have a pending transaction to gate.

4. The Real Engineering Tradeoff: Latency Budget vs. Match Recall

Fuzzy name matching — accounting for transliteration, phonetic variants, and partial matches — gets meaningfully more expensive as you widen the match tolerance. A real-time path sitting inside a payment or checkout flow has a hard latency budget; a batch job reconciling an update against your existing book does not. That difference should shape the matching strategy on each path, not just the infrastructure around it:

The common mistake is building one matching pipeline and pointing both paths at it. A pipeline tuned for real-time's latency ceiling will under-match on the batch side, where you can afford more thorough (and slower) comparison; a pipeline tuned for batch's exhaustiveness will blow the latency budget if reused inline. For a deeper look at the matching algorithms themselves — phonetic indexing, transliteration handling, and the tradeoffs in scoring thresholds — see our related piece on fuzzy matching architecture for sanctions screening.

5. List Update Propagation Is the Part Teams Underbuild

Neither pattern works if the underlying list data is stale. OFAC does not publish updates on a fixed schedule — new designations, delistings, and identity-record corrections can happen multiple times within a single week without advance notice. An architecture that treats the list as a snapshot refreshed on a convenient internal cadence (nightly, weekly) is building in a detection lag equal to that cadence, regardless of how fast the matching engine itself runs.

A more resilient design treats list ingestion as its own pipeline stage, independent of both screening paths:

1. Ingest and diff each list publication against the previous version, so you know exactly which records were added, removed, or modified — not just that "the list changed."
2. Version every snapshot. Every screening decision — real-time or batch — should record which exact list version it was checked against, so a later audit or investigation can answer "was this counterparty on the list at the time we checked" precisely, rather than approximately.
3. Trigger batch rescreening from the diff, not the full list. Rescreening your entire book against every record on every update wastes compute; rescreening against just the delta gets you the same coverage far faster.
4. Rebuild the real-time index from the new snapshot before batch rescreening starts, so new transactions are protected first and the backlog reconciliation follows.

6. A Decision Framework

7. Designing for Both: A Hybrid Architecture

Most mature compliance engineering setups don't pick one pattern — they run both against a shared, versioned list index: a real-time query API serving the transaction-gating path, and an update-triggered batch worker handling ongoing monitoring of the existing book. The list ingestion and versioning layer described above sits underneath both, so a screening decision made inline and a screening decision made in a batch reconciliation job are both traceable to the exact list version they were evaluated against — which is what actually holds up under an audit, rather than a vague claim that "we screen everyone."

Frequently Asked Questions

Should sanctions screening always run in real time? No. Real-time (inline, synchronous) screening is for decisions that must be gated before they proceed — releasing a payment, approving an account. Ongoing monitoring of an already-onboarded customer or vendor base against list changes is a different problem: it's about detecting a status change on an existing relationship, which batch rescreening triggered by list updates handles more efficiently than re-running every relationship inline on every list change.

How often do sanctions lists actually change? OFAC updates the SDN list on its own schedule, sometimes multiple times within a single week, without advance notice. Any architecture that treats the list as a static snapshot refreshed occasionally is building in a detection lag between when a party is designated and when your systems reflect it.

Does real-time screening replace the need for batch rescreening? No — they cover different populations. Real-time screening only evaluates counterparties at the moment of a new transaction or onboarding event. It says nothing about existing customers or vendors who were clean when onboarded but may have been designated since. That population is only caught by rescreening the existing book against list updates, which is inherently a batch (or update-triggered) process.