Batch sanctions screening processes a defined population of people or organisations together. The population may be supplied as a CSV file, prepared in Excel and exported to CSV, or passed through another supported bulk workflow. “Bulk sanctions screening” usually describes the same population-level job.
A screening control can be delivered as a defined population exercise or as a response to a business event. The better choice is not inherently batch or real time: it depends on the trigger, population, available data and required review evidence.
This page explains batch, bulk, CSV and Excel-prepared screening and compares those delivery models. It does not determine which parties an organisation must screen, which sanctions regimes apply or whether an activity may proceed.
Key takeaways
- Batch screening evaluates a defined population, commonly through a CSV file, remediation exercise or scheduled review.
- Real-time screening evaluates supplied data when a defined event calls the screening workflow, often through an API connection.
- Both need usable identity data, an owned review path and evidence of the request, result and outcome.
- A potential match is not a legal conclusion. The organisation's authorised process determines the response.
- A hybrid design can combine event-driven checks at important control points with batch refreshes or configured ongoing monitoring for existing records.
Batch, bulk, CSV and Excel screening: what is different?
| Term | Practical meaning |
|---|---|
| Batch sanctions screening | Processing a defined set of parties as one run or controlled population |
| Bulk sanctions screening | Common search and buyer language for batch or high-volume population screening |
| CSV sanctions screening | Batch screening where the population is delivered in CSV format |
| Excel sanctions screening | Usually a population maintained or prepared in Excel, then exported into a supported upload format, or a spreadsheet-led manual process |
Checklynx currently documents CSV delivery. If your customer list is maintained in Excel, prepare the required columns and save or export the worksheet as CSV. Do not assume that “Excel screening” means native XLS/XLSX upload.
Maintaining a spreadsheet is also different from screening the population represented in it. The file holds source data; matching, candidate generation, analyst review, recurring control and evidence belong to the screening process.
Batch and real-time screening at a glance
| Decision dimension | Batch screening | Real-time screening |
|---|---|---|
| Starting point | A defined file or population | A defined business event |
| Typical use | Remediation, migration, periodic customer or supplier review | Onboarding, approval, counterparty or other system event |
| Data handoff | CSV or another supported bulk workflow | Supplied data from the connected workflow |
| Operational question | Which known records should we review together? | Should this event enter a screening and review path now? |
| Evidence to retain | Population, input, run context, results, exceptions and review outcomes | Event context, supplied input, result, review and outcome |
| What it does not decide | Legal scope or final action | Legal scope or final action |
The comparison is about delivery, not a universal legal sequence. A policy may use batch screening for a controlled population and real-time screening for a different event. The appropriate mix depends on the organisation's risk assessment, operational model and applicable requirements.
When batch screening is the better fit
Batch screening is useful when the team already knows the population it needs to examine and does not need every record to enter through a live system event.
Examples include:
- a customer-master remediation or migration;
- a periodic review of approved customers, suppliers, distributors or counterparties;
- a controlled review after a data-quality or scope change; and
- a spreadsheet-led process where compliance needs to connect results back to stable source-system IDs.
CSV Batch Screening supports uploads for a defined population, customer-record updates, review context and the reuse of prior false-positive decisions where appropriate. The organisation remains responsible for the records supplied, the relevant policy and the action after review.
For a supplier population, the choice is more specific than “use a file or use an API.” Read API vs. Batch Sanctions Screening for Supplier Populations to compare CSV, event-driven screening and configured ongoing monitoring.
When real-time screening is the better fit
Real-time screening is useful when a defined business event should send supplied party or transaction context into a screening workflow as it occurs. Typical examples can include customer onboarding, a supplier-approval event, a counterparty change or a payment-related control point.
The event itself does not determine the legal response. Teams should define the data contract, the records in scope, who reviews a potential match, what happens if the technical request fails and who is authorised to make the final decision.
Checklynx's real-time screening API can connect supplied data from a customer workflow to screening and review. It does not decide which parties are legally required to be screened or whether an organisation must approve, hold, reject or report an event.
Choose by control point, data and review capacity
Before selecting a delivery model, answer these questions:
- What is the control point? Is the need tied to a business event, an approved population, a remediation exercise or a policy-defined refresh?
- Which records belong in scope? Define the customer, supplier, owner, counterparty or related party before choosing a format.
- Which identifiers are available? Name data alone may not be enough to resolve a potential match. Preserve the identifiers and relationship context available to the reviewer.
- Who owns the review? A delivery route needs a queue, escalation path and accountable decision maker.
- What needs to be retained? Keep the trigger or population, input, timestamp, screening context, reviewer rationale and outcome. Record exceptions such as rejected rows or failed requests as well.
Case management and audit trail and evidence can keep screening context, notes, review work and outcomes connected. They support a controlled workflow; they do not replace the organisation's legal assessment or human judgement.
How to prepare a customer population
Give every party a stable identifier from the source system so that results, corrections and later runs can be connected to the same record. Include the identity attributes that are legitimately available and useful for investigation, such as full name, aliases, date of birth, nationality, address, company registration number and relevant relationship context.
Record the source system, extract date, file version, population scope and whether the file contains the complete active population or only additions and changes. Remove accidental duplicates without collapsing genuinely different people or entities that share a name.
A name match is a candidate, not proof that the party is the designated person. OFSI's UK guidance, for example, explains that additional identifiers should be considered when deciding whether a name match is a target match.1
Recurring CSV sanctions-screening control map
This is a practical operating model, not a universal regulatory checklist. Adapt it to the organisation's regimes, policies, systems and supervisory requirements.
| Control point | Operating question | Evidence to retain |
|---|---|---|
| Stable party identifier | Can the same party be connected across runs? | Source ID and mapping convention |
| Full or incremental file | Does the run represent the full active population or only changes? | Feed type, extraction cutoff and scope |
| Identity fields | Are enough attributes available to investigate candidates? | Field inventory and completeness exceptions |
| Accepted and failed rows | Which source records completed processing? | Accepted IDs, rejected IDs, reasons and retry state |
| Source and configuration context | Which sanctions data and settings applied? | Run timestamp and recorded source/configuration context |
| Candidate review | Who reviewed each candidate and what was decided? | Reviewer, rationale, status and escalation |
| Previous non-match decision | Can prior work be reused when relevant facts remain unchanged? | Prior disposition and relationship to the current record |
| Changed party or sanctions data | What requires an earlier decision to be reconsidered? | Changed facts and review rationale |
| Reconciliation | Do source, accepted, failed and processed totals agree? | Control totals and explained exceptions |
| Rerun | How is a corrected or partial run distinguished from the original? | Incident, rerun reference and superseded-run record |
The table describes controls a buyer should design. It does not claim that Checklynx automatically supplies every reconciliation, rollback or change-trigger mechanism shown.
How to reconcile a batch run
Compare the source population with accepted, rejected and processed records. Investigate missing IDs, duplicate identifiers, malformed rows and partial failures. Correct and rerun failed records through an owned process, retaining the relationship between the original run and the correction.
Do not report a batch as complete merely because some results were returned. The organisation should be able to explain which population was intended, which records completed, which did not and what happened next.
A hybrid model can be appropriate
The models can work together without becoming duplicate controls. For example, a supplier may be screened when it enters an approval workflow, then included in a policy-defined review population later. A customer file may be remediated through CSV before selected recurring records enter configured monitoring.
The important point is to keep one clear record of scope, trigger, delivery route and outcome. Avoid treating a periodic CSV upload as a substitute for maintaining the source data or assuming that a prior decision answers every future change.
The supplier sanctions screening checklist covers the data, ownership, approvals and evidence that procurement teams should define. For an example of a spreadsheet-led quarterly process, see the anonymised supply-chain customer story.
Batch and real-time results both need investigation
A batch result or real-time result can identify a potential match or review signal. It does not establish that a person or entity is the listed subject, that a sanctions restriction applies or that a transaction must be stopped.
Reviewers should use the supplied identifiers, source context, relationship information and applicable internal procedure to investigate the result. The practical sanctions-screening guide explains the broader control framework.
File delivery is not the whole control
Keep these concepts separate:
| Concept | Meaning |
|---|---|
| File delivery | How the population reaches the screening process; Checklynx documents CSV for this workflow |
| Screening methodology | The sources, identity fields, matching configuration and scope used |
| Analyst review | Human investigation and disposition of generated candidates |
| Ongoing monitoring | Maintained re-screening based on configured recurring or change-driven processes |
| Transaction screening | Screening a payment or transaction-related party or message at an event |
| Behavioural transaction monitoring | Analysis of transaction activity and patterns; a separate control not provided by this batch sanctions-screening workflow |
Frequently asked questions
Is batch screening less compliant than real-time screening?
No. A batch workflow can be appropriate for a defined population or periodic review, while an event-driven workflow can be appropriate at a control point. Compliance depends on the applicable requirements, scope, data, review process and evidence—not on the format alone.
Can a CSV batch replace ongoing monitoring?
Not automatically. A CSV can support a defined population exercise. Ongoing monitoring requires a maintained scope, configured records and an owned response to relevant changes. The ongoing monitoring solution explains that workflow.
Does a real-time screening result automatically stop an event?
No. Screening returns information for the organisation's authorised workflow. The customer decides how results are evaluated and what action, if any, is permitted under its policy and the applicable legal framework.
Is bulk sanctions screening the same as batch screening?
Usually. “Bulk” emphasises the size of the population; “batch” describes processing a defined population together. Confirm what a provider means and which formats and controls it supports.
Can I screen a customer list from Excel?
Yes, by preparing the required fields in Excel and exporting the worksheet as CSV for the documented Checklynx CSV workflow. Native XLS/XLSX upload should not be assumed.
Do I need an API for bulk sanctions screening?
Not necessarily. A CSV workflow may suit a known population or remediation exercise. An API is more useful when a defined business event must send data into screening as it occurs.
What happens to previously reviewed false positives?
Prior decisions can reduce repeated work where the record, candidate and relevant context remain sufficiently unchanged. Define what changes require the decision to be reviewed again.
How should failed rows be handled?
Retain their stable IDs and failure reasons, correct the data or process fault, rerun them through an owned procedure and reconcile the corrected run to the original population.
Choose a reviewable delivery model
Use batch screening where a defined population needs a controlled review. Use real-time screening where an event needs supplied data assessed in the workflow. In either case, make the control reviewable: define the trigger, retain the evidence and give a qualified person responsibility for the final outcome.
Official sources
Footnotes
-
UK Office of Financial Sanctions Implementation, UK financial sanctions general guidance, official UK guidance on name and target matches, identifying information and ownership/control; accessed 10 September 2026. ↩