Sanctions screening software is the detection layer of a trade compliance program. It ingests counterparty records from upstream systems, normalises the relevant fields, and compares those fields against entries on the screening lists. Where a comparison produces a similarity score above the configured threshold, the software generates an alert.
This article describes how the system runs in practice. It covers the inputs the software ingests, the matching algorithms it applies, the lists it screens against, the outputs it produces, and the points where the system stops. The description is mechanical, intended to make the working parts visible to compliance professionals who already understand the regulatory stakes.
The system has two distinct surfaces. The first generates alerts. The second has to act on them. Most of the engineering attention has gone to the first.
What Sanctions Screening Software Does
Sanctions screening software is a name-comparison engine that runs against a set of sanctions and watchlists. The software ingests records describing counterparties (customers, suppliers, freight forwarders, business partners, beneficial owners), normalises the relevant fields, and compares those fields against entries on the screening lists. Where a comparison produces a similarity score above the configured threshold, the system generates an alert.
The screening can run in several modes. In real-time mode, the software intercepts a transaction as it is created in an upstream system (an order in SAP S/4HANA, a customer onboarding event in a CRM) and decides whether to allow the transaction to proceed. In batch mode, the software runs periodically against the full business partner list and flags any record that has changed status. In ad-hoc mode, an operator runs a single query against the database for a one-off check.
Most production deployments combine batch and real-time screening, with batch covering the master data baseline and real-time covering changes at the point of transaction. A company processing 25,000 alerts per month across multiple subsidiaries will typically run all three modes against counterparty masters drawn from several business systems.
The software produces alerts. An alert is a notification that a potential match has been identified and requires human review. The decision about whether the match is genuine, the documentation of the reasoning, and the audit-ready record of what was concluded sit outside the screening tool's output. Those are part of sanctions resolution, which sits downstream.
What Does Sanctions Screening Software Compare?
The comparison runs across several fields, but the primary field is almost always the name. Address, country, date of birth (for individuals), entity type, and identifiers such as registration numbers can be included where they are available, but in most production deployments the name field carries the comparison and the other fields serve as filters or boosters. The architecture supports broader field use where the data is reliable enough to depend on.
Names are messy data. The same legal entity can appear in source records as "Volkswagen AG", "VW AG", "Volkswagen Aktiengesellschaft", or with diacritics, transliteration variants, abbreviations, and partial spellings. Sanctions lists themselves contain alias entries, "also known as" variations, and historical names. The matching algorithm has to bridge these surface differences while still distinguishing "Volkswagen AG" from a legitimately different entity that happens to share characters.
Several matching techniques run in parallel inside a typical screening platform. Exact-match comparisons catch the cleanest cases. Phonetic algorithms (Soundex, Metaphone) catch some cross-script and pronunciation-based variations. Edit-distance algorithms (Levenshtein, Damerau-Levenshtein, Jaro-Winkler) score the number of insertions, deletions, and transpositions required to transform one string into another.
Token-based algorithms compare strings as sets of substrings rather than as single tokens. Transliteration tables convert non-Latin scripts (Arabic, Chinese, Cyrillic, Korean) into a comparable Latin form before scoring. Most production screening platforms run several of these techniques together and combine the scores into a composite similarity figure, which is then compared against the configured threshold.
Which Sanctions Lists Does the Software Screen Against?
The lists themselves come from multiple regulatory sources. The EU Consolidated List, maintained by the European External Action Service, aggregates restrictive measures imposed by the Council of the European Union under the Common Foreign and Security Policy. The OFSI-maintained UK Sanctions List captures the UK's standalone sanctions framework following the European Union (Withdrawal) Act.
The US OFAC Specially Designated Nationals list captures entities designated under United States primary sanctions, alongside the sectoral and non-SDN lists OFAC publishes for narrower purposes. The UN Security Council Consolidated List captures designations made under UN resolutions. National competent authorities such as BAFA in Germany or De Nederlandsche Bank in the Netherlands publish supplementary lists in some cases.
Watchlists beyond the official sanctions lists are also commonly screened: politically exposed person lists, adverse media lists, internal denial lists, sectoral or industry-specific watchlists. The mechanics of the comparison run identically across these list types, with data-quality differences and threshold adjustments handled at the configuration layer.
Sanctions lists are published in heterogeneous formats. OFAC publishes XML and CSV exports of the SDN and consolidated lists, with field structures broadly stable but periodically extended. The EU Consolidated List is published in XML by the European External Action Service. The UK Sanctions List is published in CSV and XML by HM Treasury.
The UN Consolidated List is published in XML by the UN Security Council. National competent-authority lists and sectoral lists vary further in format. The screening software has to ingest all of these, normalise them into an internal representation, and keep them current as the lists update. Update cadence varies from daily to ad-hoc, and the operational requirement is that screening runs against the most recent available version of every list it depends on.
How Does Threshold Tuning Affect Alert Volume?
The threshold is the variable that determines alert volume. A threshold of 90% similarity will produce far fewer alerts than a threshold of 75%, and a higher threshold will also miss matches where the screening list spelling differs from the counterparty record by more than 10% of the string. The trade-off sits between false positives at the low-threshold end and missed designations at the high-threshold end.
A company processing 500 alerts per month at a 90% threshold may move to 1,500 alerts per month at 85%, and to 4,000 at 80%. The exact numbers depend on the input , but the curve is steep at the low end. False positive rates of 80% or higher are common across trade-intensive companies, and false positive reduction is one of the largest operational levers available to a compliance program.
A defensible position, though contested, is that threshold tuning past a certain point trades false positive reduction against detection robustness in ways most programs do not measure. The instrumentation for measuring detection robustness is harder to build than the instrumentation for measuring false positive volumes. Volume is visible every day in the alert queue. Detection failures are visible only in the rare cases where a designated entity slipped through and was caught by some downstream control, by an audit, or by a regulatory enforcement action.
Programs tune for what they can see, and what they can see is volume. The result is a steady drift toward thresholds that minimise alert load while gradually eroding the screening program's ability to catch designations that fall outside the algorithm's narrowing comfort zone.
How the Software Reads from Upstream Data
The data the screening software reads from is rarely as clean as the comparison logic assumes. Counterparty data lives in ERP systems, CRM systems, supplier management systems, customer onboarding flows, and trade-finance systems. Each carries its own field structure, conventions for company suffixes, address-field handling, and data-quality history.
A company processing 25,000 alerts per month across multiple subsidiaries will typically be screening against a counterparty master assembled from several upstream systems, each with different field layouts and different ages of last data refresh. The screening software accepts all of it and runs the comparison anyway. Where field-level data is incomplete (no country, no entity type, no registration number), the comparison falls back to the name field alone.
The fallback is the situation in which false positive rates are highest. The name field on its own carries the least information and the smallest distinguishing surface. Adding more data fields to the comparison at screening time (a confirmed jurisdiction, a confirmed entity type, a registration number) would shift the volume profile considerably, because the matching algorithm could disqualify many candidates that look similar by name but differ on other input variables.
The reason most production deployments do not work this way is upstream economics. The ERP integration required to deliver clean field data alongside the name has been more expensive than threshold tuning, so threshold tuning has become the path of least operational resistance. The market may move this way as the volume problem grows, but the path is not yet established at scale.
What Does Sanctions Screening Software Output?
The primary output is the alert. An alert typically contains the matched record from the counterparty side, the matched entry from the list side, the similarity score, the algorithm or algorithms that produced the match, and metadata identifying the screening run and the source system.
The richer the alert payload, the faster the analyst can triage. Some screening platforms expose the similarity score and the algorithm trace; others surface only the matched name pair and a binary match indicator. The difference determines whether the analyst can recognise a clear false positive in seconds or has to reconstruct the match from scratch.
Alongside individual alerts, the software produces operational metrics: alert volumes per period, matches per list, false positive rates over time, and queue-depth indicators. These metrics drive the threshold-tuning conversations that compliance teams have with their screening vendor. They also drive the screening evaluation criteria that buying teams apply when assessing vendors against each other.
Often resolution records sit outside the screening software's output. The screening tool indicates that an alert exists. The conclusions an analyst reaches, the evidence that supports those conclusions, and the form in which a regulator three years later will see the documentation are mostly assembled outside the screening platform. Most programs build the resolution record across screenshots, spreadsheets, and case-management tools that were never designed for sanctions work.
Where the Screening Tool Stops
The screening tool stops at the alert. The work that follows the alert is investigation, decision, and documentation, and that work runs on people, browsers, registries, and shared drives rather than on the screening platform itself. The investigation workflow is largely manual across the trade-intensive industrial sector.
A straightforward false positive takes between three and seven minutes to clear. An ambiguous match takes thirty minutes to an hour, sometimes longer. At a fully loaded analyst cost of €45 per hour and a volume of 3,000 alerts per month with an 80% false positive rate, the monthly time cost sits between 200 and 400 analyst hours.
The screening platform played its part in identifying the alert. The 200 to 400 hours run on resources that sit outside the screening platform.
Audit readiness sits in the same place. The auditor focuses on what the team concluded about a given alert, why that conclusion was reached, and on what evidence. According to OFAC's recent-actions summary, the agency recorded approximately $1.5 billion in settlements and penalties in 2023, and the actions touching non-financial industrial companies have grown across the past three years.
The penalties cited in those actions track resolution-quality failures more often than detection failures: poor documentation, inconsistent decision logic, missing escalation paths, and gaps between what was investigated and what could be reconstructed under regulatory request.
How a Screening Program Runs in Practice
The picture across most trade-intensive industrial companies is consistent. The screening platform is mature: a vendor product, configured against the major sanctions lists and a set of internal watchlists, running in batch and real-time modes against counterparty masters drawn from several upstream systems. The threshold has been tuned over time, often through several cycles of vendor-led adjustment, and produces a stable monthly alert volume that the compliance team has learned to staff against.
False positive rates run high. The team has established protocols for the most common false positive patterns and clears those quickly. The remaining alerts (the ambiguous ones) absorb the majority of investigation time per alert and produce the majority of the variance in investigation quality across the team.
The investigation work runs on analysts. Analysts open alerts in the screening tool, read the matched name pair, then leave the screening tool and assemble the rest of the investigation in other systems. Corporate registry portals, news searches, internal denial-list checks, regulator publications for designation details, occasional paid-database lookups for ownership structures.
The investigation produces a decision and a case note. The case note is recorded in whatever case-management system the program uses, which may be the screening tool's bundled module, a separate compliance platform, a ticketing system, or a shared drive. Documentation quality varies considerably across these channels.
The detection layer is the maturest part of the trade compliance technology stack today. The variability that remains in compliance program quality sits in the resolution layer, and that is where most of the audit risk and most of the operational cost concentrates. The screening tool generates the alert. What happens to that alert determines what the compliance program looks like under regulatory scrutiny, and that part runs on people, manual context-gathering, and case notes scattered across whatever systems the program has assembled.