Best Sanctions Screening Software: 8 Criteria

Last updated: October 2026

The best sanctions screening software for a financial institution is the software whose matching the institution can see, tune and defend. It screens every party and every payment field the institution must screen, as soon as a list changes, it finds entities that are blocked through ownership, and it leaves a record of why each hit was cleared. OFAC will not choose the tool, set the threshold or confirm a match, so the only reliable way to compare products is to test them on your own customers and payments. Read the missed true matches first, and count the false positives saved only after that.

This guide sets out eight criteria for choosing sanctions screening software. Each criterion covers what it is, what to ask a provider, what a weak answer sounds like and how to test it on your own data, and a scorecard at the end collects all eight.

TL;DR

• No sanctions screening software is best for every institution. OFAC says the size and needs of each institution determine what to look for, and it does not recommend a match threshold.

• Judge screening tools on eight criteria: list coverage and update speed, name matching you can see and tune, ownership under the 50 Percent Rule, customers and payments, how false positives get cleared, thresholds you own, match quality on your own data, and a record an examiner can follow.

• List data and the matching engine are separate purchases. Evaluate each on its own terms.

• Test every candidate on your own labelled history before signing. The bar for missed true matches is none; false positives removed is the second number, not the first.

• OFAC's recordkeeping rule now requires records to be available for at least 10 years, a change that took effect in March 2025.

• Oscilar wrote this guide. The criteria name no products, and a later section applies the same criteria to Oscilar, including the ones Oscilar does not answer itself.

The short answer: how to choose sanctions screening software

Choose the sanctions screening software that fits your institution's risk profile, shows you how it matches names, screens customers and payments against every list you need as soon as those lists change, handles ownership, and records why each hit was cleared. Then prove it on your own data. There is no single best tool among sanctions screening solutions, because OFAC leaves the choice to the institution: its FAQ 31 says "The size and needs of each institution help to determine what to look for in a package."

OFAC is also clear that the decisions inside the tool belong to the institution. On threshold scores, OFAC's FAQ 250 says users "must make their own match threshold determinations based upon their own internal risk assessments and established compliance practices." On individual hits, FAQ 5 says "OFAC does not confirm potential matches or false positives to our sanctions lists and instead encourages organizations to make risk-based determinations consistent with the guidance above."

A sanctions manager at a payments fintech put the buyer's job in one line: "sanctions screening is finding what I'm looking for. So how do I better define what I'm looking for". The software finds; the institution defines what it is looking for, sets how closely a name must match, and decides each hit.

That is why the test matters more than the feature list. The head of screening at a large bank described how they would read a vendor's results on their own data: "is there a loss on trues, no great. Then how many of the false positives were you able to ... get rid of?" Missed true matches come first, because a missed true match is a potential sanctions violation and a false positive is analyst time.

Ask every provider the same questions in writing, and run every test on your own customers and payments rather than on demonstration data. Oscilar wrote this guide; the criteria name no products, and the section after them judges Oscilar by the same criteria.

What sanctions screening software does

Sanctions screening software compares the names on customer records and payments with sanctions lists, raises a hit when a name looks close enough to a listed one, and puts that hit in front of a person who decides whether it is a true match. Sanctions screening tools, watchlist screening software, name screening software and OFAC screening software are all names for the same job, applied to customers (name screening at onboarding and rescreening) and to payments (payment screening, sometimes called transaction screening). In OFAC's 2019 Framework for OFAC Compliance Commitments, the tool is one internal control inside a program with five components: "(1) management commitment; (2) risk assessment; (3) internal controls; (4) testing and auditing; and (5) training."

OFAC's own free Sanctions List Search already applies fuzzy logic to names, combining string and phonetic matching, so what an institution buys is coverage of its whole book and every payment, matching it can tune and defend, and a record of each decision. Transaction monitoring is a different job with its own buying criteria; see our guide to choosing transaction monitoring software. Choosing AML software as a whole, of which sanctions screening is one part, is a wider evaluation with its own criteria.

1. List coverage, and how fast updates land

What it is: List coverage is which sanctions lists the software screens against, including the SDN List, OFAC's other lists, any other lists your risk assessment calls for and your own internal watch lists. Update speed is how quickly a new designation reaches the screening that runs in production. OFAC's Framework names this as a root cause of compliance breakdowns, under "Sanctions Screening Software or Filter Faults": organizations "failed to update their sanctions screening software to incorporate updates to the SDN List or SSI List".

List data and the matching engine are separate purchases, and many institutions now buy them separately. A principal architect for financial-crimes systems at a large bank described the plan: "our list feeds ... it's probably going to be one of the bigger players ... but our [tool] which actually does the screening that's what we're thinking of replacing. And we don't want that to be tightly coupled." A tool that only works with its own list data makes both decisions for you.

Internal lists need the same reach as official ones. An OFAC sanctions lead at a regional bank described a tool that could screen the bank's own internal watch list against customers but not against live wires, so the internal list stopped at onboarding.

What to ask a provider:

• Which lists do you screen against, and can we add our own internal lists and screen them against both customers and payments?

• Can we use the list data we already license, and change list provider later without replacing the screening tool?

• When OFAC adds a designation, how long until it is live in production screening, and who triggers the update?

• How do we show an examiner which list version was live at any moment?

An SVP of FIU operations at a community bank asked that last question directly: "How do we show the examiners or auditors that when the list was updated with some timestamps, date stamps, things like that. Do we have that functionality?"

What a weak answer sounds like: An assurance that lists update every night, with no timestamp of when each list version went live. An internal-list feature that covers customers only is another warning sign.

How to test it on your own data: Take a recent designation, replay your customer file and a day of payments against the list version from before and after it, and check when the software would first have raised a hit. Then ask for the log that proves which list version was live at each point.

2. Name matching you can see and tune

What it is: Name matching is how the software decides that a name on a record or a payment is close enough to a listed name to raise a hit. The methods include fuzzy and phonetic matching, comparison of name parts, transliteration, alternative spellings and aliases. The same OFAC sanctions lead at a regional bank put it plainly: "fuzzy, I know is becoming outdated but you still need fuzzy."

How names are compared matters as much as whether they are compared. Treating a full name as one string misses cases that comparing given and family names separately would catch, in both directions. OFAC's Framework lists failing to "account for alternative spellings of prohibited countries or parties" among the screening faults, with examples such as Habana for Havana and Soudan for Sudan.

Some choices are explicitly the institution's to make. OFAC's FAQ 5 says "Some listed aliases may be classified by OFAC as 'weak aliases,' and your screening tool may exclude these aliases as part of a risk-based decision." The FFIEC BSA/AML Examination Manual says "the bank should clearly define its criteria for comparing names provided on the OFAC list with the names in the bank's files or on transactions". A setting that matters this much has to be visible and documented, not buried in the vendor's defaults.

Matching also needs context beyond string similarity. The same head of screening at a large bank asked of one hit: "why would a vessel be in a name field?" A chief compliance and risk officer at a cross-border payments company drew the same line between the list and the matching: "it's not just data. It's the logic they built to assess this data".

What to ask a provider:

• Which matching methods do you use, on which fields, and can we see which method produced each hit?

• How do you handle name order, name parts, transliteration and aliases, and can we choose whether weak aliases are screened?

• Can our team change matching settings, and is each change logged with who made it and why?

• What context beyond the name, such as the field the name appeared in or a date of birth, do you use to separate hits?

What a weak answer sounds like: A proprietary match score that nobody at the vendor can explain to an examiner, or matching settings only the vendor can change.

How to test it on your own data: Build a set of variants of recent designations, covering reordered names, transliterations, dropped name parts and aliases, and seed them into a copy of your customer file and payment data. Check which variants each candidate catches and whether it can show why.

3. Ownership and the 50 Percent Rule

What it is: Under OFAC's 2014 guidance on entities owned by blocked persons, "any entity owned in the aggregate, directly or indirectly, 50 percent or more by one or more blocked persons is itself considered to be a blocked person." Such an entity's property is blocked "regardless of whether the entity itself is listed". A name screen alone cannot find it, because the entity's name is on no list.

Ownership is aggregated. OFAC's FAQ 399 gives the example: "if Blocked Person X owns 25 percent of Entity A, and Blocked Person Y owns another 25 percent of Entity A, Entity A is considered to be blocked." It adds that "the ownership interests of persons blocked under different OFAC sanctions programs are aggregated." Below the threshold, the 2014 guidance still advises U.S. persons "to act with caution when considering a transaction with a non-blocked entity in which one or more blocked persons has a significant ownership interest that is less than 50 percent".

The beneficial ownership data an institution collects for customer due diligence answers a different question. FinCEN's CDD rule (31 CFR 1010.230) identifies each individual who "owns 25 percent or more of the equity interests" of a legal entity customer, plus one individual with significant control. OFAC's test adds up the holdings of blocked persons, however small each holding is, so CDD data does not by itself answer the 50 Percent Rule question.

Ownership is also layered. An AVP managing KYC and sanctions at a community bank asked whether ownership could be screened through every layer at onboarding, such as a company owned by a company owned by individuals, and whether the middle layers would be rescreened later.

What to ask a provider:

• Do you screen the owners of an entity, through every layer of ownership, and aggregate the holdings of blocked persons across sanctions programs?

• Where does the ownership data come from, and is it a separate purchase?

• When an owner is designated after onboarding, does the entity raise a hit at the next rescreen?

What a weak answer sounds like: An offer to screen whichever beneficial owners you supply. That screens the CDD owners by name and leaves the aggregation question unanswered.

How to test it on your own data: Take a sample of your entity customers with layered ownership, add a hypothetical designation of one owner at each layer, and check whether the software flags the entity, and how it shows the ownership path that produced the hit.

4. Customers and payments, not one or the other

What it is: Sanctions screening covers two different flows. Customer screening checks names at onboarding and again whenever a list changes; payment screening checks every party and field in a payment before it moves. The same sanctions manager at a payments fintech described why rescreening matters: "we've onboarded someone, they're already an existing customer, new sanctions come out. They're now designated and now we need to take appropriate action".

Payment screening has to cover the whole message, not the fields a vendor chose. The same OFAC sanctions lead at a regional bank said: "I don't care where Iran is in a payment. You screen that whole ... payment for Iran." OFAC's Framework lists failing "to include pertinent identifiers such as SWIFT Business Identifier Codes" among the screening faults.

Payment screening also runs against the clock. The same head of screening at a large bank described the chain: a client calls to ask why a payment is still held, the business presses operations, and operations blames sanctions. OFAC's 2022 guidance on instant payment systems says "the speed necessitated by this commercial feature should not discourage financial institutions from implementing risk-based sanctions compliance controls," and that OFAC "encourages the use of such tools and other emerging technologies and solutions to manage sanctions risks that could arise in the context of instant payments" where appropriate on a risk basis.

What to ask a provider:

• Do you screen customers at onboarding, rescreen the whole book when a list changes, and screen payments in real time and in batch?

• Which fields of each payment message format do you screen, including free text and identifiers such as SWIFT BICs?

• Do our internal lists apply to payments as well as customers?

• How long does a payment wait while a hit is reviewed, and what does the reviewer see?

What a weak answer sounds like: Internal lists that apply only to customers, payment screening limited to named fields, or rescreening that runs on a fixed calendar rather than when a list changes.

How to test it on your own data: Run a sample of your own payment messages through each candidate with a listed name planted in a free-text field, and run a list change against your customer file to see which existing customers would be rescreened and when.

5. How false positives get cleared

What it is: Most hits are not true matches. OFAC's FAQ 5 says "Many potential matches identified through screening are false positives." The FAQ, updated on 9 September 2026, sets out six steps for reviewing a potential match: determine whether the hit is against an OFAC list; determine what it potentially matches; evaluate the quality of the match; determine next steps for a valid match; determine whether to block or reject; and report valid matches to OFAC and keep records.

The quality step is where software makes the most difference to a reviewer. FAQ 5 says "To verify or disqualify a potential match, compare all of the details in the OFAC listing with the information available to you about the data in your transaction or activity that led to the 'alert' or 'hit.'" Those details include "full names, former names, known aliases, nationalities, passport, tax ID, national identification numbers, place of birth, date of birth, business registration numbers, or known addresses." Good software puts those identifiers side by side in front of the reviewer, showing which matched, which did not and which were missing.

The volume of false hits is itself an examination signal. The FFIEC manual's OFAC section says "A high volume of false hits may indicate a need to review the bank's interdiction program."

How a cleared hit is carried forward matters as much as how it is cleared. The same OFAC sanctions lead at a regional bank described a tool's suppression feature: "It basically writes a false positive reduction rule. However I don't like the parameters on the false positive reduction rule. It's one and done". A suppression with no expiry, and no rescreen when the list entry changes, can hide a hit that should come back.

If any hits are cleared automatically, someone has to be able to check them. A senior AML specialist at a cross-border payments fintech asked: "Do we have the ability to review the ones which the AI has made decisions to close them?" How AI agents can prepare that review for an analyst is covered in our guide to how AI agents review sanctions alerts.

What to ask a provider:

• For a hit, show us the identifiers compared, which matched, which did not and which were missing, and the list entry and alias that produced it.

• How is a cleared hit carried forward? Does it expire, and is it rescreened when the list entry changes?

• What can be cleared without a person, who sets that, and how do we sample and review it?

What a weak answer sounds like: A list of cleared names or a suppression rule that is set once and never revisited, or automatic clearing with no record of what was compared.

How to test it on your own data: Take a sample of hits your team has already cleared, run them through each candidate, and compare the evidence the software presents with what your analysts needed to decide. Then change a list entry behind one suppressed hit and check that the hit returns.

6. Thresholds you own, and who can change them

What it is: The match threshold is how close a name must be to a listed name before the software raises a hit. No regulator sets one. Asked whether it recommends a specific match threshold score for its own Sanctions List Search tool, OFAC answered in FAQ 250: "OFAC cannot make such a recommendation because each search has its own unique set of facts surrounding it." The FFIEC manual says "Decisions to use interdiction software and the degree of sensitivity of that software should be based on a bank's assessment of its risk and the volume of its transactions."

That puts the threshold, and the explanation of it, with the institution. The same head of screening at a large bank described what examiners expect: "My regulators ... expect it to be in my house and me to own it. Me to tune it, me to write rules in it, me to be able to explain every single way that it functions".

Raising a threshold is not a free way to cut false positives. A higher threshold lowers alerts and coverage together, whereas better context, such as dates of birth, addresses and the field the name appeared in, lowers alerts while coverage holds. When a threshold does change, sample the activity just above the new line to check that the remaining hits are worth reviewing, and just below it to check that nothing that should have alerted has dropped out. The below-the-line sample is what shows an examiner that coverage held.

What to ask a provider:

• Who can change thresholds and matching settings, and is every change versioned with the reason recorded?

• Can we test a threshold change on our own historical data before it goes live?

• Can we set different thresholds by list, by customer segment or by payment type?

What a weak answer sounds like: A claim that the vendor's default threshold suits most banks. A threshold that only the vendor can change, or that cannot be tested before it goes live, is another warning sign.

How to test it on your own data: Run your own history at the current threshold and at the proposed one, and read the hits that disappear before celebrating the drop in volume.

7. Match quality tested on your own data

What it is: Match quality is how well the software finds true matches and avoids false ones on your customers and payments, not on a demonstration set. OFAC's Framework expects institutions to have "selected and calibrated the solutions in a manner that is appropriate to address the organization's risk profile and compliance needs, and the organization routinely tests the solutions to ensure effectiveness."

The strongest test design is the one buyers already use. The same head of screening at a large bank designed a bake-off as a period of labelled alert data the vendor could learn from, followed by a period of unlabelled data, with the vendor's outcomes then checked against the bank's own labels. The same chief compliance and risk officer at a cross-border payments company planned to test a vendor on a large sample of their own records before signing, because without confidence in the system, any system, there is no point signing.

Read the results as two numbers, and read them in order. The first is critical misses: true matches the software would have missed or cleared, and the bar for those is none. The second is the false positives it removed, which shows how much review time it can save. Then read the disagreements one by one, because some are software errors, some are data your analyst had that the hit did not, and some are practice nobody wrote down.

Control names make a simple first gate. A principal architect for financial-crimes systems at a large bank described testing whether a vendor's system catches exact control names from a major list at a strict threshold, calling it "like a go, no go filter if you will for selecting a vendor". Examiners use the same method: the FFIEC manual's exam procedures say "If there is any doubt regarding the effectiveness of the OFAC filter, then run tests of the system by entering test account names that are the same as or similar to those recently added to the OFAC list".

What to ask a provider:

• Can we run your software on our own labelled history before signing, and then on unseen data checked against our labels?

• Will you report critical misses separately from false positives removed?

• Can we keep a test environment after go-live, so every threshold or list change can be tested before it reaches production?

What a weak answer sounds like: An assurance that you will not need a test environment. The same OFAC sanctions lead at a regional bank described a vendor saying the bank would not need a testing platform, and the bank found it did, because a parallel environment it cannot actually test in is not a test environment.

How to test it on your own data: Backtest on labelled history, then run in shadow on live traffic alongside your current tool and compare the two on the same customers and payments. Include control names and variants of recent designations in both runs.

8. A record an examiner can follow

What it is: The record is what the software keeps about each hit and each decision, and it is what OFAC asks for. OFAC's FAQ 5 says "Organizations should keep complete, accurate records detailing the steps taken to investigate the potential match and the information relied upon to ultimately determine whether the potential match was valid." Under 31 CFR 501.601, records must be "available for examination for at least 10 years after the date of such transaction"; the change from five to 10 years was published on 13 September 2024 and took effect on 12 March 2025. Blocked property and rejected transactions must also be reported to OFAC within 10 business days (31 CFR 501.603 and 501.604), and the record has to support those reports.

Audit findings tend to be about the rationale, not the screening alone. An officer overseeing sanctions, onboarding and QA at a community bank said: "the findings that we usually see on the sanctions front would be that the users typically forget to complete sanctions screening ... or if they did conduct it, they clear it out with the wrong rationale." The Framework puts the fix with the institution: "it is the organization's responsibility to enhance its program, including all program-related software, systems, and other technology, to remediate any identified compliance gaps."

The record of a cleared hit should contain:

• the list, the entry and the alias that produced the hit, and the list version or date

• each identifier compared (name parts, date of birth, nationality, address, ID numbers) and its result: match, mismatch or missing

• any further information requested and received

• the recommendation and its reasoning, where the software makes one

• the analyst's decision and rationale

• who confirmed the decision, and when

• for a possible true match: the escalation, and the block-or-reject decision made by a person

What to ask a provider:

• Show us the full record for a cleared hit and for an escalated one, exactly as an examiner would receive it.

• How long are records kept, can we export them, and do they survive if we leave?

• Is every change to lists, thresholds and matching settings logged alongside the hits it affected?

What a weak answer sounds like: Records available only on request from the vendor, or a disposition that stores the outcome but not the reasoning.

How to test it on your own data: Pick a handful of hits cleared during the trial and ask a colleague who was not involved to reconstruct each decision from the record alone.

Where Oscilar fits, judged by the same criteria

Oscilar wrote this guide, so here is Oscilar judged by the same eight criteria, including the ones it does not answer itself.

Criteria 1 and 2, list coverage and name matching: Oscilar does not answer these itself. List data and the matching engine come from the screening tool and list provider an institution licenses, and this guide makes no claim that Oscilar replaces either one. Evaluate those on their own terms using the questions above. Because Oscilar's agents "can run inside the full Oscilar platform or as a standalone layer on top of your existing stack," choosing Oscilar does not tie an institution to a particular list provider or screening tool.

Criteria 3, 4 and 6, ownership, customers and payments, and thresholds: These are properties of the screening tool that generates the hits, including where the match threshold is set, so judge them there.

Criterion 5, how false positives get cleared: This is where Oscilar sits. In the house view behind Oscilar's design, the screening tool generates hits against the lists it licenses, and the agent reviews each hit against the list entry and the customer or payment data, recommending clearing or escalating with its work shown. Oscilar's Agent Hub describes its Sanctions Screening agent as "Explainable, pre-filled disposition guidance for every sanctions hit." A person still decides: "Agents never autonomously close or escalate alerts," which is what an AVP managing KYC and sanctions at a community bank asked for: "the approval needs to come from an analyst and not from AI".

Criterion 7, match quality on your own data: Test Oscilar the way this guide recommends testing anything: backtest on hits your team has already decided, then run in shadow next to your current process, and read critical misses before review time saved. For the models it runs, Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment.

Criterion 8, the record: Oscilar provides a full audit trail per decision with stored reasoning, and human-in-the-loop by design.

Two further points, stated for what they are. The Oscilar platform is specified for sub-100ms decisions; that is a platform specification, not a measure of how long a sanctions hit takes to screen or review. Chartis named Oscilar to the 2026 FCC50 with category wins for Agentic AI Innovation and Low-Code/No-Code Customization; that is an analyst's recognition, not a ranking in this guide.

The eight criteria at a glance

Use the second column as the script for every provider conversation and the last column as the test plan.

Frequently asked questions

What should sanctions screening software do that OFAC's free search tool does not?

OFAC's free Sanctions List Search applies fuzzy logic to the name field only, combining string matching and phonetic matching. Sanctions screening software has to do the work around that: screen the whole customer book and every payment against every list the institution needs, rescreen when lists change, let the institution see and tune its matching, and keep a record of each decision. OFAC's FAQ 27 notes that commercial interdiction software packages "vary considerably in cost and capabilities."

Does OFAC recommend a match threshold or a screening product?

No. OFAC's FAQ 250 says it "cannot make such a recommendation" on threshold scores, and users "must make their own match threshold determinations based upon their own internal risk assessments and established compliance practices." On whether an institution has to buy expensive software, OFAC's FAQ 27 says it "is primarily a question for your regulator," and FAQ 31 says the size and needs of each institution determine what to look for.

How often should a financial institution rescreen its customers?

A financial institution should rescreen its customers whenever a sanctions list it screens against changes, as well as screening at onboarding and when customer details change. OFAC's guidance cited in this article does not set a fixed calendar, and its Framework lists failing to update screening software for list changes as a root cause of compliance breakdowns. A rescreen that waits for a periodic review can leave a newly designated customer active in the meantime.

Is PEP screening the same as sanctions screening?

No. Sanctions screening checks customers and payments against sanctions lists, and a valid match can mean the institution must block or reject. PEP screening identifies politically exposed persons, which raises a customer's risk and calls for more due diligence rather than a prohibition. Our guide to what US rules require for PEP screening covers it in full.

How long must sanctions screening records be kept?

Under OFAC's recordkeeping rule, 31 CFR 501.601, records must be available for examination for at least 10 years after the date of the transaction. The period was extended from five to 10 years by a rule published on 13 September 2024, and the change took effect on 12 March 2025. OFAC's FAQ 5 expects the records of a potential match to include the steps taken and the information relied on.

Is Oscilar a sanctions screening provider?

Oscilar's Agent Hub includes a Sanctions Screening agent, described as "Explainable, pre-filled disposition guidance for every sanctions hit." It works on hits, alongside the list data and screening tool an institution licenses, and an analyst confirms every recommendation. Because Oscilar wrote this guide, test it on your own hits as you would any other candidate.

The best sanctions screening software is the one that performs on your own customers and payments. It covers the lists you need and updates them fast, matches names in a way you can see and tune, finds ownership, screens customers and payments alike, clears false positives with the evidence shown, leaves the threshold with you, survives a test on your own data and leaves a record an examiner can follow. To see how disposition guidance on sanctions hits works alongside an existing screening tool, look at the Sanctions Screening agent in Oscilar's Agent Hub and put it through the same test as any other candidate.