Real-Time vs Batch Sanctions Screening: A Compliance Professional's Guide

Sanctions screening is a process that every financial institution must conduct properly in order to prevent organisations from engaging with sanctioned people, entities, jurisdictions, and more. Sanctions screening is done by using sanctions lists provided by governments and regulatory bodies.

As an important part of a compliance program, sanctions screening has two ways, it can either be done in real-time or in batches. Batch sanctions screening is completed in a scheduled manner, with customers being scanned all together in a decided time. Real-time sanctions screening is continuous and involves the checking of transactions as they happen.

It’s crucial for companies to know the difference between real-time and batch sanctions screening to make sure they’re using the right kind for the appropriate situation. In this blog post, we’ll be detailing what real-time sanctions screening is, what batch sanctions screening is, the differences between the two, when real-time sanctions screening or batch sanctions screening is needed, how to use both processes to better protect companies, and more.

What Is Real-Time Sanctions Screening?

Sanctions screening becomes more and more important each year since regulatory bodies demand these frameworks from financial institutions. As transactions become more complex and requirements for each jurisdiction continue to change, companies should pay more attention to sanctions screening.

Real-time sanctions screening is checking a person, transaction, entity against sanctions lists as it is relevant to do so, like during customer onboarding, transaction start, payment request. With real-time sanctions screening, there’s no delay or queue. The screening happens continuously and the result is out before the process continues.

One example of real-time sanctions screening breaches is from the Bank of Scotland. In 2026, Bank of Scotland was fined £160,000 for opening a bank account and processing payments for an ally of Vladimir Putin, Dmitrii Ovsiannikov. This was achieved by the ally because the Bank of Scotland lacked fuzzy matching features in the real-time sanctions screening process that failed when Ovsiannikov used a variation of his name during onboarding. The EU made Ovsiannikov a designated person under its sanctions legislation in November 2017, and the failure of Bank of Scotland in 2025 cost them thousands of pounds.

How Real-Time Screening Works

Real time sanctions screening uses an event-driven and API-based model to complete the process. The mechanics of the process aren’t difficult but understanding the architecture may be more challenging for companies.

First, an event needs to occur. This may be a customer completing an onboarding form, a payment instruction being submitted, a transaction being initiated. That event then triggers an API call to initiate the screening process. The relevant data is sent to the screening engine. These details are name, date of birth, country, account number, counterparty details, or other identifiers that may be available and needed.

The screening engine checks the data against the pre-existing sanctions lists. These lists are usually OFAC SDC, EU Consolidated List, UN Security Council Consolidated List, HMT, or others that are relevant to each jurisdiction. A pass, flag, or block decision then gets returned to the system and this process takes milliseconds.

If the result is a pass, there will be no interruption to the process. If the result returns as a flag or block, the system then chooses from three options accordingly. Holding the transaction, escalating for review, rejecting the interaction is possible at this stage.

Since real-time sanctions screening returns results in milliseconds, it’s obvious that it uses different tools than traditional compliance solutions do. Real-time screening engines should have sanctions lists in memory or in extremely low-latency data stores. The engine should be applying fuzzy matching logic while accounting for name transliterations, aliases, spelling variations, partial matches. Doing all of this without giving up speed is the unique challenge of real-time sanctions screening tools. Any latency introduced by the screening layer may add friction to the customer journey and can breach SLA commitments or regulatory timing requirement.

Strong and newer real-time screening platforms are built on available and horizontally scalable architectures. Downtime in this process means that transactions will clear without being screened, leading to compliance exposure which can be difficult to recover from.

What Real-Time Screening Is Designed For

Real-time screening is built for important and time sensitive interactions. This means that a sanctions match must be identified before a process completes. The primary use cases for real-time screening is shared below.

• Customer onboarding: Real-time sanctions screening verifies that a customer isn’t a designated person before a relationship is established.
• Payment execution: Real-time screening helps with screening the originator, beneficiary, and any intermediary parties before a wire or SWIFT message is released.
• Transaction initiation: Real-time screening flags high-risk counterparties at the point of trade or contract execution.
• Card authorisation: Real-time screening screens merchants or cardholders in real time during authorisation flows.

What Is Batch Sanctions Screening?

Batch sanction screening processes a large amount of records like customer databases, a portfolio of counterparties, a backlog of transactions in one go and it’s a process that has been previously scheduled.

Batch screening shouldn’t be seen as a compromise made by companies. It’s a distinct process that is also needed in a compliance program, and it solves issues real-time sanctions screening can’t. The risk that’s in the company’s existing customer base and transaction history can only be reached and analysed by batch sanctions screening.

One example of batch screening failure is the case of Starling Bank. Starling Bank was fined 29 million £ by the FCA because the bank had let 49,000 high-risk customers go unnoticed between September 2021 and November 2023. This was caused by the lack of sanctions lists used during batch screening.

How Batch Screening Works

Batch screening runs on a schedule or in response to a trigger that’s external like a sanctions list update. The first step is the extraction of a dataset. This dataset could be the full customer master file, an active counterparty list, a portfolio of unusual transactions, or a different structured dataset requiring screening.

The dataset is then submitted to the screening engine. The dataset is uploaded to the engine as a file upload or database-connected job at once rather than as individual API calls. The entire database is then processed by the screening engine against various sanctions lists, the same matching logic used in real-time screening is applied but this time, for generally millions of records.

Alerts are then generated for any record that is a match or potential match, and a results file or dashboard view is sent back to the compliance team for review. The compliance team then works through the alert queue to essentially clear false positives and further escalate true matches accordingly.

Batch sanctions screening is started if one of these three conditions are met. The first is a scheduled processing window. This is obviously the most common reason for batch sanction screening checks. Scheduled batch sanctions screening checks are overnight runs that make sure that the entire customer base is screened against the most recent sanctions lists before a new day begins.

The second condition is a sanctions list update. When institutions like OFAC, the EU release a new version to their respective sanctions lists (like the SDN List, the Consolidated List), compliance teams need to use these updated lists to rescreen the company’s entire database. The last condition is regulatory or internal examinations. Periodic rescreening checks are done to show ongoing monitoring compliance, usually right before an audit or examination.

Companies may face thousands of alerts and matches in a single batch sanctions screening run, especially if they are a large financial institution with many customers. Planning and getting ready for these alerts beforehand will give the company and their compliance team an advantage for the screening process.

What Batch Screening Is Designed For

Batch screening is used for complying with ongoing monitoring obligations. The process works particularly well during sanctions list updates, overnight runs, before regulatory examinations. Some other use cases for batch screening is listed below.

• Batch screening is great during retrospective screening of historical transaction data when new designations require looking back at prior activity.
• Another great use case for batch screening is for counterparty and vendor list rescreening during procurement or credit review cycles.

Real-Time vs Batch: Side-by-Side Comparison

The difference between real-time sanctions screening and batch sanctions screening isn’t just based on speed. Real-time screening and batch screening’s trigger mechanism, coverage scope, when they are expected regarding regulatory contexts, the resource intensity they require, the false positive numbers they generate are different as well. The difference between both processes in these dimensions are detailed below.

Regarding false positives, real-time screening deals with them one by one since they arrive one at a time due to continuous checking, and this type of false positive requires rapid triage to make sure the compliance team isn’t blocking legitimate customers or payments. When it comes to batch screening, thousands of alerts come back after a single run; therefore, a different kind of approach is needed. Bulk review tooling, prioritisation logic, a tiered approach to differentiate high-confidence matches and lower-confidence matches is used during batch screening.

Another area to focus more on and explain is the failure mode risk. If or when a real-time screening system experiences downtime, transactions and onboarding events may need to stop. An even worse scenario is onboarding events or transactions continuing without being checked when the real-time screening system is down. If a batch screening fails or gets delayed, the entire customer database stays unchecked even though it is needed for that period of time.

When Regulators Expect Real-Time Screening

There are multiple scenarios and processes that regulators point to when asked about when real-time screening is expected from companies. Some of these situations are during payment screening, customer onboarding and CDD, for high-risk jurisdictions and sectors, for regulatory references.

Payment Screening

For payment processes like SWIFT wire transfers, CHAPS payments, interbank message flows, regulators expect real-time sanctions screening before the payment is finalised. Completing this screening before a payment is done will make sure that no sanctioned individual can transfer funds without being stopped. OFAC’s enforcement history shows that companies that screened payments afterwards have received penalties and fines, since it’s more important to conduct screening before the funds are sent.

Any payment workflow that could involve a sanctioned party whether it be originator, beneficiary, intermediary, or correspondent requires real-time screening which can block or hold the transfer until clearance. Batch screening isn’t particularly helpful during this scenario since the screening may run hours after the payment is done.

Customer Onboarding and CDD

Know Your Customer (KYC) and Customer Due Diligence (CDD) are compliance processes that are especially widely used in the EU, UK, U.S., Singapore, and these frameworks categorise sanctions screening as a part of the pre-relationship verification process. The EU’s Anti-Money Laundering Directives, OFAC’s guidance, MAS Notice 626 all show that regulators demand companies to screen customers before a relationship between the two is established.

Since sanctions screening is treated as a pre-relationship verification process component, it doesn’t make sense to use batch screening for this process. Real-time API integration with the onboarding framework is the solution recommended for customer onboarding and CDD.

High-Risk Jurisdictions and Sectors

For jurisdictions like Iran, North Korea, Cuba, Russia that are counted as high-risk, or sectors like correspondent banking, trade finance, crypto asset services that are of higher risk, additional precautions are needed. Regulators may have stricter and heightened expectations for companies that are operating in these jurisdictions or sectors. The Financial Action Task Force (FATF) Recommendations and related guidance manuals prove that EDD in high-risk scenarios demands stricter monitoring, which points to real-time sanctions screening rather than batch sanctions screening.

When Batch Screening Is Appropriate and Necessary

Even though we’ve detailed extensively the scenarios that would benefit from the usage of real-time sanctions screening, it doesn’t mean batch sanctions screening is an unnecessary part of compliance programs that should be phased out from modern frameworks. The nature of the ongoing monitoring obligation keeps batch screening just as relevant as real-time screening when it comes to compliance. The purpose of batch screening, therefore, should be understood correctly by compliance teams in order to create a strong and well-prepared compliance system.

Batch screening isn’t a lesser alternative to real-time sanctions screening. The risk of a customer that passed screening during onboarding but has since been designated, or of a customer that’s recently popped up on an updated sanctions list can’t be identified using real-time screening, and this is where batch sanctions screening shines.

Ongoing Monitoring of the Existing Customer Base

Real-time sanctions screening is especially crucial for the customer entry point. Batch screening helps protect the overall database afterwards. A customer who was cleared during onboarding years ago may become sanctioned later. Batch screening is great for noticing these changes and blocking the customer accordingly.

Most sanctions compliance frameworks require ongoing monitoring as well as onboarding screening. The ongoing monitoring requirements can’t be fulfilled by real-time screening alone.

Post-Designation Rescreening

Post-designation rescan is one of the most important parts of catching designated individuals within the company’s customer database. When OFAC adds a new group of names to the SDN List, companies are expected to rescan their entire customer database to figure out if any of their customers are involved with the designated list.

This is something that needs to be done immediately, but it requires a full rescan. Thus, batch screening gets triggered automatically to rescan the full database against the updated list. Companies that can’t immediately complete batch screening will surely face compliance exposure.

Portfolio-Wide Rescreening for Regulatory Examinations

For regulatory examinations, it’s recommended to rescreen the company’s entire database to show that the ongoing monitoring part of the compliance system is functioning properly. Moreover, adding batch screening logs, run histories, alert disposition records to documents that are shown during examinations will also serve as the primary evidence of efficient screening practices.

Companies that only rely on real-time screening and can’t prove how they continue ongoing monitoring will most likely not be able to satisfy examiners with their ongoing monitoring practices, leading to revisions and lower efficiency.

The Hybrid Approach: Why Most Firms Need Both

It should be clear to companies by now why real-time and batch sanction screening are both needed for a strong compliance program. These two processes are complementary capabilities that address different risk vectors, deal with different regulatory obligations, operate in different parts of the compliance program. Most modern and mature sanctions compliance programs need both processes.

In a hybrid architecture, real-time sanctions screening is what comes first. This process does the heavy-lifting in onboarding and payment processing which both use API-driven screening calls to block sanctioned parties. Batch screening works in the background and runs on a daily schedule unless needed after updates or for regulatory examinations.

Real-time screening handles the point of entry and batch screening handles the ongoing monitoring part of the compliance program.

Real-time alerts need rapid triage since they may be blocking a live customer or transaction from continuing. However, batch alerts can be managed in bulk, with more of a structured approach. These two processes should come together in a unified case management system to avoid duplication.

List update management is more difficult to master. When OFAC updates the SDN List, the real-time screening engine must receive the updates before continuing with onboarding and payment actions. The batch rescan should also be triggered immediately after list updates. Companies that manage list updates manually may suffer more from penalties and fines.

When real-time and batch operations run on the same engine with the same list versions, the same matching logic, and the same alert management infrastructure, compliance teams work more efficiently. Discrepancies between the two modes create gaps that are difficult to explain to regulators, and are also difficult to manage operationally.

A platform that handles both modalities also simplifies the list update workflow. A unified platform can apply a list update once and immediately make it available to both real-time screening and batch screening.

Regulators expect both real-time and batch screening. OFAC, the EU, MAS, and other regulators all expect compliance from pre-relationship verification to ongoing monitoring. A program built on real-time screening alone can’t satisfy the ongoing monitoring obligation. A program with only batch screening can’t satisfy pre-execution payment screening requirements.

Pınar Meltem Üstündag

Content Writer

View full profile →