Sanctions screening testing is how a bank proves that its screening raises the alerts it should, against the list as it stands today, and that the people and rules behind it clear those alerts correctly. Most programs test the first half, the filter, with lists of seeded names. Fewer test the second: whether a reviewer, a suppression rule or a priority score lets a real match go. The most useful test file is not invented. It is built from the root causes OFAC and UK regulators have already penalized: a missing bank identifier code, a transliterated name, an exact name and date of birth ranked low, a stale list, a list loaded only in part. Botminds' Sanctions Alert Review is built to be tested this way: proposed screening changes run against seeded names first, and a sample of every analyst's closures is re-reviewed blind.
Examples from the solution use a fictional sample, Norrell Federal Credit Union. The cases are quoted from OFAC's and the FCA's own notices.
What untested screening has cost, in recent cases
$1.11M
TradeStation, 2026: 481 trades from sanctioned regions while controls failed and a test tool lay unreplaced
£28.96M
Starling Bank, 2024: screening against a fraction of the Consolidated List since 2017
6months
Bank of America took to fix the ranking of exact name and date-of-birth matches after finding it
5
components OFAC expects in every program; testing and auditing is the fourth
What sanctions screening testing has to prove
Sanctions screening testing has to prove three things: that every list the bank says it screens is loaded in full and current, that the matching logic flags the variants of listed names the bank's risk assessment says it must catch, and that the alerts it raises are cleared, escalated and prioritized as the procedures say. A test that proves only the second is a test of a vendor's algorithm, not of the bank's control.
OFAC lists testing and auditing as one of five essential components of a sanctions compliance program, and describes the function it wants: "A comprehensive, independent, and objective testing or audit function within an SCP ensures that entities are aware of where and how their programs are performing and should be updated, enhanced, or recalibrated" (OFAC, A Framework for OFAC Compliance Commitments, 2019). The Wolfsberg Group puts the same aim in screening terms: banks "should deploy an independent risk based testing regime to ensure that the screening application generates expected alerts" (Wolfsberg Guidance on Sanctions Screening, 2019).
How do you test a sanctions screening system?
You test a sanctions screening system by running a file of known cases through it and comparing what it does with what it should do, then checking that the results feed back into its settings. The known cases are seeded names and transactions, each with an expected outcome: alert or no alert, high or low priority, escalate or close. The comparison is automatic; the judgement about a failure is not.
The cases worth seeding first are the ones OFAC has seen fail. Its 2019 Framework lists "Sanctions Screening Software or Filter Faults" among the root causes of apparent violations, describing organizations that "failed to update their sanctions screening software to incorporate updates to the SDN List or SSI List, failed to include pertinent identifiers such as SWIFT Business Identifier Codes for designated, blocked, or sanctioned financial institutions, or did not account for alternative spellings of prohibited countries or parties". Its examples: "Habana instead of Havana, Kuba instead of Cuba, Soudan instead of Sudan". Each of those is a test case.
What a sanctions screening test file should contain
A sanctions screening test file should contain at least one case for every failure mode a regulator has penalized, with the expected result written down before the test runs. The table below builds one from the cases, and marks which part of the program each case tests: the list, the filter, the priority logic or the person.
A seed set built from penalized failures: what to plant, and what should happen
| Plant | Penalized failure it reproduces | What it tests | Pass when |
|---|---|---|---|
| A wire naming a designated bank only by its BIC | Deutsche Bank Trust Company Americas, 2020: the BIC was never added to the filter | The filter's identifiers | The BIC alone raises an alert |
| A close variant of a listed name: one changed letter, one added, a middle name dropped | Bank of Scotland, 2025: a passport spelling the screening did not reconcile | The matching logic | An alert at the production threshold |
| Habana, Kuba, Soudan in an address or free-text field | OFAC Framework, 2019: alternative spellings of sanctioned countries | Jurisdiction screening | An alert naming the sanctioned jurisdiction |
| A customer whose name and date of birth exactly match an SDN | Bank of America, 2026: such alerts were ranked low or medium priority | Priority logic | The alert is high priority and reaches a reviewer first |
| A name added to the SDN List yesterday | MidFirst, 2022, and Bank of America, 2023 and 2025: lists re-screened monthly or not updated | List currency | An alert the same day the update is published |
| A sample of entries from every list you screen | Starling Bank, 2024: only a fraction of the Consolidated List was screened | List completeness | Every sampled entry alerts against itself |
| A seeded alert with first name, last name and date of birth matching, middle name missing in your file | TD Bank, 2021: such alerts were dismissed four times | The reviewer | Escalated, not closed |
| A previously cleared false positive whose entry has since been amended | Bank of America, 2026: alerts suppressed on an earlier false-positive decision | Suppression and duplicate rules | The hit reopens for a person |
Every row is drawn from a record. Deutsche Bank Trust Company Americas "failed to include Krayinvestbank's SWIFT BIC as an identifier when it originally added the bank's information to its interdiction filter" (OFAC, DBTCA, 2020). At Bank of America, "Due to a design flaw in its alert prioritization logic", the system classified customers whose name and date of birth both matched a blocked person "as low- or medium-priority, rather than high-priority"; three designated individuals made 31 transactions totaling $56,258 before the fix (OFAC, Bank of America, 2026). At Starling, the FCA found that since 2017 its automated system "had only been screening the names of new and existing customers against a fraction of the names on the Consolidated List" (FCA, Starling Bank, 2024).
Payoneer's 2021 settlement adds three more rows: a matching algorithm too weak to flag close variants of SDN names, no screening of bank identifier codes even where the SDN entry listed them, and, when queues backed up, flagged payments that released themselves with nobody reviewing them (OFAC, Payoneer Inc., July 23, 2021; the release question is taken up in real-time payment screening). The third is a workflow test: fill the queue past its limit in a test environment and confirm that nothing releases on its own.
Silent failures: the alerts that stop arriving
The hardest failures to test are the ones that produce nothing. A list file that stops updating, a feed that stops sending, a rule that suppresses more than intended: each makes the queue quieter, and a quiet queue looks like good news. Testing has to include the absence of alerts.
TradeStation's case is the clearest example. A firewall control was disabled for a software update in June 2021 and never re-enabled; a second control had been broken by a 2018 change to the mobile platform. A third-party service that sent daily notices of blocked access attempts lapsed when an employee failed to renew it. In OFAC's words, "For a period of over eight months, TradeStation's sanctions compliance personnel failed to address the absence of its once-daily OFAC alerts". The firm had built an automated test that simulated access from sanctioned regions, but its providers blocked the test traffic, and "TradeStation discontinued the use of this tool in November 2021 without replacing it" (OFAC, TradeStation Securities, Inc., March 17, 2026).
For alert review the equivalent test is volume monitoring with expectations: how many hits a list update of a given size should raise, how many payment hits a normal Tuesday produces, how many closures each analyst makes. The FCA found Starling had "no operational MI relating to alert volumes and trends which would have allowed Starling to monitor the effectiveness of configurations and overall screening effectiveness". A sudden fall is as much a finding as a spike.
How do I test alert review, not just the filter?
Test alert review by re-reviewing a sample of real closures blind, and by planting known true matches in the queue. The filter test asks whether an alert was raised; the review test asks whether the person or rule that cleared it was right. Most enforcement cases on this page failed at the second step, after the filter had done its job: TD's alerts fired five times, Bank of America's exact matches fired and were ranked low, and its suppression rule released alerts that had fired.
Two tests, two different failures: the filter, and the review Sanctions Alert Review samples
Testing the filter: Did the screening raise an alert on this name, BIC or country?
Testing the review: Did the person or rule that handled the alert reach the right answer?
Testing the filter: Seeded names and transactions with an expected alert
Testing the review: A sample of real closures, plus planted true matches in the live queue
Testing the filter: Model validation, IT or a vendor, independent of the team that set the threshold
Testing the review: A QA reviewer who did not make the closure and does not see its answer first
Testing the filter: Missing identifiers, unreconciled spellings, stale or partial lists
Testing the review: Closing on an absent identifier, skipping escalation, suppression across a changed entry
Testing the filter: Share of seeded cases alerted, at the production setting
Testing the review: Agreement between the blind re-review and the closure, by analyst and reason code
In the sample, the review test runs every day. The solution's QA sampler draws 10% of each analyst's closures at random, 25% in an analyst's first 90 days, every override of the agent's reason codes and every closure below 0.95 confidence. The reviewer sees the customer and the list entry with the identifier marks, the analyst's decision and the agent's verdict hidden, and answers first: not the listed person, possible match or can't tell. On the sample Thursday, 39 closures were drawn, 31 at random and 8 by rule.
Blind re-review in Sanctions Alert Review: the reviewer answers before seeing anyone's view
The filter side is tested the same way before any change goes live. In the sample, a proposal to raise the threshold for single-token names from 85 to 88 was run against seeded names first, and the expected result was written down before approval: about 70 fewer hits a day, while 180 of 180 list-derived variants still hit. That is a seeded test with an expected result, attached to the change it justifies. The mechanics of the threshold itself are in what a sanctions screening threshold can and cannot say.
Who should do independent testing, and how often?
Independent testing should be done by people who did not configure the screening or clear the alerts, at a frequency set by risk. The FFIEC manual says "Every bank should conduct an independent test of its OFAC compliance program that is performed by the internal audit department, outside auditors, consultants, or other qualified independent parties", with frequency for large banks "based on the known or perceived risk of specific business areas" and for smaller banks "consistent with the bank's OFAC risk profile" (FFIEC BSA/AML manual, OFAC section).
Wolfsberg names the same candidates for screening specifically, "internal audit, an independent group within the FI's compliance division, a third-party vendor engaged for this purpose or a combination of these", and adds that the screening application "may also be submitted for consideration as a model". Neither sets a calendar. In practice the events that should trigger a test are clearer than any interval: a new list or program, a threshold or rule change, a vendor or platform change, a large designation round, and any finding from the blind review.
When to run the test file, beyond the annual audit
- Before any threshold or rule change goes live
With the expected effect written down and approved by someone other than the proposer.
- After every vendor, platform or algorithm change
OFAC asked users of its own search tool to repeat their testing after it changed its algorithm in 2021.
- When a new list, program or channel is added
A new list loaded in part is the Starling failure in miniature.
- After a large designation round
Confirm the new entries alert, including their aliases and identifiers.
- Every day, on volume
Expected alert counts by source; a fall is a finding.
- Every day, on review
A blind re-review of a sample of closures, with overrides and low-confidence closures always included.
Measuring sanctions screening system effectiveness
Sanctions screening system effectiveness is measured by detection of seeded true matches, the accuracy of reviewed decisions, the timeliness of list updates and escalations, and the stability of alert volumes, each tracked over time rather than reported once. Wolfsberg asks that "Regular testing of the system should be supported by metrics, analysis and reporting". The four measures that map to the cases on this page are seeded-case detection at the production setting, blind-review agreement by analyst and reason code, the hours from OFAC publication to re-screen, and the minutes from escalation to the officer's desk.
The sample credit union reports the last two directly: 9 of 9 OFAC updates loaded on the day they were published in October, and 41 of 41 potential matches on the OFAC Officer's desk within the hour, at a median of 22 minutes. Those figures come from fictional sample data, not from a customer. What they show is that each measure can be produced from the work itself, without a separate exercise. How to use the same measures to judge automation before trusting it is covered in piloting automated sanctions screening on closed alerts.
The measures, from the work itself: Sanctions Alert Review's audit trail and its export for a period
What OFAC said about testing in the TradeStation case
OFAC used the TradeStation settlement to say what testing is for and what it is not. The release opens with the lesson that firms should "deploy testing mechanisms to ensure that compliance tools are adequately implemented and functioning as intended", and the compliance considerations are blunter:
Controls only work if they are effectively implemented. The most well-designed sanctions compliance program can be rendered wholly ineffectual by human and technical errors.
OFAC, settlement with TradeStation Securities, Inc., March 17, 2026
OFAC went on: "Firms should not treat testing and auditing—or any other sanctions compliance undertaking—as a box-checking exercise", and warned against leaning on a patchwork of tools that are switched on and never looked at again (the subject of OFAC interdiction software). For a sanctions team the practical reading is that a test file is a living document: every new case, here or in your own QA, is a row to add. To see the blind review and the seeded tuning tests in the product, start from Sanctions Alert Review.
Questions people ask
What should a sanctions screening test file contain?
Known cases with expected results: listed names and realistic variants, identifiers such as BICs and vessel numbers, alternative spellings of sanctioned places, newly added entries, a sample from every list screened, and planted true matches for the reviewers. OFAC's 2019 Framework names missing identifiers, stale lists and alternative spellings as root causes of violations.
How often should sanctions screening be tested?
The FFIEC manual leaves frequency to risk, and Wolfsberg sets no calendar. Most programs run an independent test at least annually and add event-driven tests: before a threshold change, after a vendor or platform change, when a list is added, and after a large designation round.
Is sanctions screening software a model that needs validation?
It can be. Wolfsberg's 2019 guidance says the screening application "may also be submitted for consideration as a model". Since April 2026, the U.S. banking agencies' revised model risk guidance, SR 26-2, places generative and agentic AI outside its scope and leaves their controls to each bank's governance.
Can the vendor test its own screening?
A vendor can run the tests, and Wolfsberg lists a third-party vendor engaged for the purpose among qualified testers. But the bank remains responsible for its own compliance whatever it outsources, so it should own the test file, the expected results and the review of findings.
What is the difference between testing and tuning?
Tuning changes the settings to improve results; testing proves what the settings do. A tuning change should be tested on seeded cases before it goes live, with the expected effect written down and approved by someone other than the person who proposed it.