Sanctions Screening API vs Manual Batch Screening: A Technical Buyer's Decision Guide

Between 2018 and 2020, Cash App's unprocessed transaction monitoring alert backlog grew from 18,000 to over 169,000. The NYDFS consent order against Block, Inc. issued in April 2025 found that suspicious activity reports were filed on average 129 days after the triggering alert was first generated, and in some cases more than a year later. The statutory SAR filing window under the Bank Secrecy Act is 30 days from identification of suspicious activity. Block's architecture was generating alerts at a rate the review pipeline could not absorb, and the gap between generation and disposition accumulated into one of the most documented compliance failures of the decade. 

Block was not an isolated case. ING was fined €775 million in 2018 and ABN AMRO paid €480 million in 2021, both after failing to adequately screen and monitor clients for money laundering risk, underscoring that screening architecture failures are a recurring, not exceptional, feature of enforcement history.

This is what happens when a screening architecture cannot process what it generates at the volume and pace the business requires. It is also the right starting point for any organisation deciding between a real-time sanctions screening API and a batch-based implementation: which method belongs where in a specific compliance workflow, and what the regulatory and operational consequences are of getting that wrong.

The real risk 

Every batch screening architecture has a blind window: the period between the completion of one batch run and the start of the next during which a new sanctions designation can be published, a customer in the existing book can match it, and the system has no mechanism to detect or act on that match. In a nightly batch model, this window is typically 18 to 23 hours. In a weekly model, it extends to days.

At the same time, OFAC updates the SDN list with no advance notice and no fixed schedule. Designations are published in response to geopolitical events, criminal investigations, and enforcement decisions, none of which align to a compliance team's batch calendar. In a single month, OFAC may publish multiple SDN updates, each adding new individuals, entities, or wallet addresses. Every update resets the blind window for any customer whose match would only be caught by the next scheduled run.

That’s the main argument for real-time screening in time-sensitive workflows. It is not an argument against batch screening universally. Batch is appropriate, efficient, and in some contexts the correct implementation. The question which method to deploy at each workflow stage, because the answer differs depending on where in the customer lifecycle the screening event sits and what the consequence of a delayed detection is.

The Decision Matrix: Matching Implementation to Use Case

Onboarding

Real-time API is the correct implementation at the onboarding gate. The customer is present. The decision is binary: proceed or hold pending review. A batch run that completes hours after onboarding is initiated is not compatible with a live user flow. By the time the batch result is available, the customer has either been admitted without a screening result or is waiting in a queue with no clear resolution timeline.

The false positive risk at the onboarding gate is real and must be managed through match-quality configuration rather than by reducing screening sensitivity. A match threshold calibrated too loosely will generate alerts on legitimate customers at a rate that creates pressure to lower sensitivity, a dynamic that, left unresolved, produces exactly the kind of configuration drift that the 

NYDFS identified in Block's Bitcoin threshold settings. The answer is not to screen less carefully, but to configure the matching algorithm with sufficient precision that the false positive rate is manageable within the onboarding flow without creating a queue.

Periodic rescreen of the existing customer book

Scheduled batch is the appropriate and efficient implementation for periodic rescreen of an existing customer base, with one important qualification: the batch cadence must be calibrated to the realistic frequency of list updates, not to operational convenience.

A nightly batch rescreen of the full book catches designations published during the day, closing the intraday window to a maximum of 24 hours. This is an acceptable posture for lower-risk customer segments where the probability of a match and the consequence of a delayed detection are both limited. For higher-risk segments, customers in elevated-risk jurisdictions, PEPs, high-value accounts, the appropriate complement to the nightly batch is a webhook architecture that triggers an immediate rescreen when a relevant list update is published, rather than waiting for the next scheduled run. 

Continuous monitoring built on webhook notifications closes the intraday window without converting the entire rescreen operation to real-time, which would be architecturally unnecessary and operationally expensive at scale.

Payment interdiction

Real-time API is required for payment interdiction. The payment is in flight. Settlement on modern rails, SEPA Instant, RTP, FedNow, occurs within seconds. The decision to permit or hold must be made before settlement, which means the screening call must return a result within the latency budget of the payment flow itself. Batch cannot function here by definition: by the time a batch run processes a payment instruction, the transaction has either settled or been abandoned.

FATF's June 2025 update to Recommendation 16 on payment transparency reinforces this direction. The updated standard tightens expectations around the completeness and speed of information accompanying cross-border payments, establishing a regulatory trajectory toward faster, more granular screening at the point of transaction rather than retrospective batch review. 

Organizations building payment infrastructure should treat real-time screening at the payment gate as the baseline the regulatory standard is converging on.

Ongoing monitoring between events

The hybrid model, real-time API for event-triggered screening, batch for scheduled rescreens, webhooks for list-update propagation, is how mature compliance programmes handle the full customer lifecycle. These are complementary capabilities that address different risk vectors at different points in the workflow. 

A program that deploys only real-time API screening is over-engineering the periodic rescreen use case and incurring unnecessary per-call costs. A program that deploys only batch is creating a blind window at the onboarding gate and the payment stage. 

The right architecture is the one that matches implementation mode to use case over a one-size-fits-all model. 

Use case

Recommended implementation

Reason

Onboarding gate

Real-time API

Customer present; decision must be made before admission

Periodic rescreen

Scheduled batch + webhook triggers for high-risk segments

Efficient at scale; webhook closes intraday window for elevated risk

Payment interdiction

Real-time API

Settlement occurs before batch could run

List-update response

Webhook-triggered rescreen

Targets only affected records; avoids full-book reprocessing

Regulatory examination prep

On-demand batch

Produces point-in-time audit record across full book

{{snippets-guide}}

Real-Time's Weakness: False Positives at the Gate

Real-time screening at the onboarding gate or payment stage can introduce a failure mode that batch does not: a false positive that blocks a legitimate customer or payment in a live flow.

In a batch environment, a false positive sits in a review queue. The compliance analyst reviews it at their next session, clears it, and the customer or transaction proceeds. The customer may not be aware anything happened. In a real-time environment, a false positive is immediately visible: an onboarding flow stalls, a payment is held, and the customer is waiting for a resolution. 

The commercial pressure this creates is real and documented. It is the pressure that, if unmanaged, leads compliance teams to lower match sensitivity thresholds until the false positive rate drops to a manageable level, at which point the screening programme has traded false positive friction for false negative risk, which is the regulatory exposure direction.

The scale of the underlying problem is well documented in the academic literature on sanctions screening. A 2024 study published in Frontiers in Artificial Intelligence found that false positive rates in conventional sanctions screening programs commonly exceed 90 percent of all generated alerts, a figure the researchers attribute to the tension between the fuzzy matching thresholds needed to catch name variants and the volume of unrelated matches those same thresholds inevitably produce. 

The same study ran a controlled experiment comparing a standard Levenshtein distance matching program against a version with natural language processing applied to its fuzzy matching weights. The NLP-enhanced version eliminated false negatives entirely across the test set, correctly flagging every sanctioned entity, but did so by generating substantially more false positive alerts than the baseline model, a trade-off the researchers describe as a genuine and, in their assessment, justified cost of prioritising false negative reduction over overall accuracy. A vendor that claims to reduce false positives and false negatives simultaneously, without describing a specific mechanism for doing so, is making a claim the underlying research does not straightforwardly support.

Fuzzy matching thresholds that work for a domestic UK customer base will generate different false positive volumes than the same thresholds applied to a global customer base with significant representation from Arabic, Cyrillic, or Chinese-script name transliterations. Configurable match thresholds per risk category are not a theoretical nicety. 

Industry practice already varies meaningfully by jurisdiction and provider: one common weighting convention used in the Netherlands assigns 70 percent of the matching score to name similarity and 15 percent each to date of birth and place of birth, while another published framework allocates 50 percent to full name, 20 percent to birth year, and 30 percent to associated country. Neither weighting is objectively correct. The point is that the weighting has to be deliberately set and tested against the buyer's own data rather than left at a vendor default. Phonetic matching for non-Latin scripts, and a triage workflow that routes uncertain matches to rapid human review rather than auto-blocking, are the practical requirements that determine whether real-time screening is operationally viable at the onboarding gate.

Maintaining Lists In-House

The brief for any screening implementation eventually leads to the question: should the organization maintain its own list ingestion and matching infrastructure, or use a vendor API that handles this operationally?

The Block backlog finding is instructive here in a way that is rarely cited in build-versus-buy discussions. The consent order notes that the backlog was caused in part by "the increase in alerts generated by the implementation of new transaction monitoring tools." Adding a new tool increased alert volume without a corresponding increase in review capacity. This dynamic is compounded in an in-house build because the engineering team must simultaneously manage the tool, the list ingestion pipeline, and the normalisation logic that keeps the matching infrastructure current as list formats, update frequencies, and coverage requirements change.

OFAC publishes the SDN list in multiple formats. The EU consolidated list uses a different schema. The UN Security Council Consolidated List uses another. The UK sanctions list, since January 2026 the only authoritative source for UK designations following the closure of the OFAC-style OFSI consolidated list, is updated independently and frequently. Ingesting, normalising, and propagating changes across all of these in a way that closes the blind window within hours of publication is not a one-time engineering project. It is an ongoing operational commitment that competes with every other engineering priority the team has.

The scale of this commitment is reflected in how the industry itself has prioritised its technology investment. In its 2021 survey of AML/CFT technology adoption across public and private sector respondents, the Financial Action Task Force found that artificial intelligence, application programming interfaces, and digital tools for customer due diligence were identified as having the greatest potential to improve AML/CFT effectiveness, with 85 percent of respondents citing overall programme effectiveness as the primary benefit of adopting new technology. The same report notes that natural language processing and fuzzy matching tools are already recognised, at the standard-setting level, as a means of reducing false positives and false negatives in sanctions screening specifically, by improving how systems link inconsistent name spellings, cross-border transliterations, and adverse media data to a single underlying entity. 

For most organizations below the scale at which in-house list infrastructure is economically justified, the maintenance burden alone, not the initial build cost, is the factor that tips the analysis toward a vendor API. 

What Match Quality at Low Latency Actually Requires

The vendor evaluation question that matters most for a real-time implementation is not uptime. Every credible vendor claims 99.9 percent or higher, and for a compliance-critical system, the distinction between 99.9 percent and 99.99 percent is real but secondary to the question of what the system does when it is up.

At batch speeds, a matching algorithm can take seconds per entity, time enough to run multiple fuzzy matching passes, check transliteration variants, and aggregate ownership data before returning a result. At real-time speeds, the same algorithm must return in milliseconds. The engineering constraint is significant: a tool built for batch performance and retrofitted with a real-time endpoint will degrade one of these two properties. Either it runs the full matching logic and misses the latency budget, or it runs a simplified matching logic at speed and produces lower-quality results than its batch equivalent.

FATF's guidance on new technologies for AML/CFT notes that supervisors and regulated entities alike must be able to understand the logic behind an AI-driven matching model well enough to assess its accuracy and its relevance to the risks it is meant to catch, and that a lack of this explainability directly undermines the ability to establish a tool's effectiveness as a compliance control. In practice, this means a vendor should be able to explain, in specific terms rather than marketing language, how its model weighs name similarity against secondary identifiers, and why a given match threshold was chosen for a given risk category.

The questions that reveal which category a vendor falls into are specific. What is the p95 latency under production load, not demo environment load? What is the false positive rate at the buyer's expected transaction volume, not a controlled benchmark? How are match thresholds configured, at the account level, the risk category level, or only globally? Can thresholds be changed by the compliance team through the platform interface, or does it require a vendor engagement?

Your vendor should be able to answer all of these from production data to show that the real-time capability is native to the architecture. 

{{snippets-case}}

Conclusion

The choice between a real-time sanctions screening API and batch screening is not a binary decision to be made once for the whole compliance programme. It is a series of workflow-level decisions, each driven by where in the customer lifecycle the screening event sits, what the consequence of a delayed detection is, and what the false positive tolerance is at that stage.

Block's 169,000-alert backlog was a scalability failure at every level: tool configuration, alert management, and review capacity. The architecture chosen for screening is only as effective as the case management built around it and the list infrastructure that feeds it. 

Organizations that treat the API-versus-batch question as the primary decision and leave case management and list update latency as implementation details are at risk of building a programme that generates the right alerts at the wrong time, which is the failure the Block consent order documents in detail.

sanctions.io is a highly reliable and cost-effective solution for real-time screening. AI-powered and with an enterprise-grade API with 99.99% uptime are reasons why customers globally trust us with their compliance efforts and sanctions screening needs.

To learn more about how our sanctions, PEP, and criminal watchlist screening service can support your organisation's compliance program: Book a free Discovery Call.

We also encourage you to take advantage of our free 7-day trial to get started with your sanctions and AML screening (no credit card is required).

‍