Automated sanctions screening means software that does more of the work on each hit than raise it: gathering the customer and the full list entry, comparing identifiers, drafting the rationale and proposing a decision. The safe way to adopt it is to replay alerts the bank has already closed, including every true match it has ever escalated, and score the automation against tests written before the run: no true match proposed for closing, no close on a name alone, every identifier cited, and agreement with blind QA at least as good as the analysts'. The alerts are already decided, so a replay risks nothing and measures everything, and the record it produces is the evidence an examiner asks for. Botminds' Sanctions Alert Review is piloted that way, on a sample of the bank's own past hits and list updates, before it touches a live one.
The settings and figures from the solution come from a fictional sample, Norrell Federal Credit Union; the guidance and cases are quoted from the agencies and the Wolfsberg Group. The pilot timeline is our suggestion, not a regulatory requirement or a promise.
Four tests a pilot of automated sanctions screening must pass
0
true matches from the replayed quarter proposed for closing
0
closes proposed on a name alone, or with fewer than two conflicting identifiers
100%
of compared identifiers cited to a source and a list entry version
≥
the analysts' own agreement rate with blind QA, on the same alerts
What automated sanctions screening should automate, and what it should not
Automate the reading, the comparing and the drafting; keep the deciding with people. The enforcement record is consistent on where automation goes wrong: when it releases or clears without a person. Payoneer's filter released flagged payments automatically during backlogs; Bank of America's suppression rule released alerts that matched an earlier false-positive decision; Deutsche Bank Trust Company Americas' filter sent only exact matches to a person. Each was automation of a decision, not of the work behind it.
Automation can also be the control. After a high-confidence alert was closed against its own procedures, American Express's remediation included "Launching reporting and automated solutions designed to ensure compliance with Amex's internal requirement to perform a second level of review of high confidence sanctions alerts, and to notify Amex's compliance leadership of high confidence sanctions alerts closed without a second level of review" (OFAC, American Express National Bank, July 15, 2022). Software that enforces a rule on people, rather than replacing their judgement, is the model.
What Sanctions Alert Review automates on a hit, and what it leaves to people
Automate: Attach the customer, the payment or application and the list entry in its version to every hit
Keep with people: Ask the customer for documents when the files cannot settle it
Automate: Lay out every identifier side by side, each value cited, and count matches and conflicts
Keep with people: Judge a conflict that might be a keying error, a dual nationality or a transliteration
Automate: Draft a verdict, reason codes and rationale; never propose a close on a name alone
Keep with people: Close, override with a reason, or escalate
Automate: Link a hit to an earlier closure only on an identical entry version; reopen when it changed
Keep with people: Confirm each linked duplicate
Automate: Draw the QA sample, enforce second approvals, run the report clocks
Keep with people: Re-review blind; decide matches; approve blocks and rejections
Is automated sanctions screening allowed?
Yes. The FFIEC examination manual expects banks' procedures to say how they identify and review possible OFAC violations, "whether conducted manually, through interdiction software, or a combination of both" (FFIEC BSA/AML manual, OFAC section). OFAC prescribes no technology. What is required is the outcome and the evidence: that prohibited dealings are stopped, that decisions are documented, and that the program, including any automation, is tested.
The governance expectation comes from the Wolfsberg Group. Its screening guidance asks banks to write down how each screening system is set up, show that the set-up fits the sanctions risks the bank actually runs, and say openly what the controls were never designed to catch (Wolfsberg Guidance on Sanctions Screening, 2019). Its AI principles add: "FIs should also monitor the use of AI/ML for consistent and stable performance after implementation" (Wolfsberg AI/ML principles, 2022). A pilot is where both start.
Can you test automation on alerts you already closed?
Yes, and it is the best first test, because every closed alert already has an answer to compare against and replaying it touches no customer. The replay runs the automation on each historical hit as it stood on its date: the customer's details then, the list entry in the version that raised it, the settings in force. Its proposals are then compared with what the bank decided and with what blind QA said about those decisions.
Two kinds of closed alert carry most of the pilot's evidence. The first is every true match and every escalation in the period, and further back if the period has few: a pilot that has not seen the automation handle a real match has not tested the one thing that matters. The second is every case where the list entry changed between two hits on the same customer, because that is where reuse fails, as false-positive procedures when the entry has changed explains. Seeded cases built from fined failures, set out in sanctions screening testing, fill the gaps history leaves.
What data a sanctions screening pilot needs
A pilot needs the hits, the decisions, and the information each decision was made on, as they stood on the day. The table lists what a bank brings and why. Most of it exists already; the piece most often missing is the list as it read on the date of each hit.
What to bring to a pilot of automated sanctions screening
| Data | Why the pilot needs it | Usual source |
|---|---|---|
| A quarter of closed hits, from every channel | The base for the replay: onboarding, payments and list re-screens | Screening service and case management |
| Every escalation and true match, further back if needed | The pilot's hardest test: none may be proposed for closing | Case management, OFAC reports, the officer's log |
| Closure reasons and QA results | The human baseline the automation must meet or beat | Case management; QA spreadsheets |
| Customer details as of each hit date | Identifiers to compare: date of birth, nationality, address, IDs | Core banking, account opening |
| Held payments and applications for those hits | Wire details, BICs and parties for payment hits | Payments hub, account opening |
| The OFAC list as published on each hit date | Comparisons must use the entry version that raised the hit | OFAC Sanctions List Service archives and delta files, or the vendor's history |
| Screening settings and their change history | Thresholds and rules in force on each date | Screening service configuration |
The pass/fail criteria for a pilot
Write the pass and fail criteria before the replay runs, and make the first one absolute: no true match from the replayed period may be proposed for closing. The others measure the quality of what the automation leaves for people, and the improvement it buys.
Pass and fail criteria for a replay of closed sanctions alerts
- Zero missed true matches
Every hit the bank escalated or blocked is escalated by the automation, not proposed for closing. One miss fails the pilot.
- No close on a name alone
Every proposed close cites at least two conflicting identifiers; missing identifiers are never counted as conflicts.
- Every value cited
Each identifier on each side traces to its source and to the list entry version that raised the hit.
- Amended entries reopened
Every hit whose earlier closure rested on a since-changed entry is reopened, with the old reason shown.
- Agreement at or above the human baseline
Blind QA agrees with the proposals at least as often as it agreed with the analysts on the same alerts.
- Escalations faster
Potential matches reach the officer sooner than they did historically; the sample setting is within one hour.
- Every disagreement explained
Each case where the proposal and the bank's decision differ is reviewed by the officer and written up.
- Seeded failures caught
The test file of fined failures raises the expected alerts and escalations.
The agreement test needs care. The human baseline is not perfect: a replay will find some closures the automation would have escalated where the analyst closed. Those are not automation errors; they are findings, and each should go to the officer. In the sample credit union's October, the QA sample produced 1,092 results through the 22nd. A replayed quarter with a comparable sample gives a baseline large enough to compare, by analyst, channel and reason code.
The agreement measure in Sanctions Alert Review: the blind answer, the closure and the verdict
How long a sanctions screening pilot takes
Plan on roughly ten weeks from data extraction to a go or no-go decision, most of it spent on data and on reviewing differences rather than on running the replay. The timeline below is our suggestion for a mid-sized credit union or bank; the length depends mostly on how quickly historical list versions and customer data as of each hit date can be assembled.
A pilot on closed alerts, then a parallel run: about ten weeks
- Extract and map hits, decisions, lists and data2 wk
- Replay the quarter, run seeded tests2 wk
- Review differences with the officer and an independent tester1 wk
- Parallel run on live hits, both outputs compared daily4 wk
- Go or no-go, with the results file1 wk
The parallel run is where list updates are tested live. A designation round during those four weeks is welcome: it shows whether the automation re-screens the same day, links and reopens correctly, and keeps payment hits moving while the re-screen block is worked. How the clock runs from publication to restriction is covered in OFAC sanctions list updates.
What a replay of closed alerts cannot prove
A replay proves how the automation treats the hits a bank has already seen; it cannot prove how people will treat the automation. The main risk after go-live is not a wrong proposal but an analyst who stops checking right ones. That risk is measured, not assumed: the override rate by analyst, the time each analyst spends on a proposal before accepting it, and the blind QA agreement rate, all watched from the first live week. A falling override rate with steady QA agreement is a team trusting good proposals; a falling override rate with falling agreement is a team that has stopped reading.
A replay also cannot test what history does not contain: a new program, a new kind of identifier, a list format change, a designation round larger than any in the replayed quarter. Seeded cases cover some of it; the parallel run covers more. The rest is monitoring, which is why the sample settings send every override and every closure below 0.95 confidence to QA, whatever the random draw, and why the 10% random sample never stops. The Wolfsberg principles put the duty simply: performance is watched after implementation, not certified once before it.
How to show examiners the pilot results
Show examiners the pilot as a test of a control, not a product demonstration: what was tested, against what criteria set in advance, with what results, who reviewed the differences, and what was decided. OFAC's TradeStation settlement explains why examiners value this: "Comprehensive, independent, and objective testing and auditing can help catch problems early and provide opportunities for remediation, thereby limiting risk of violating sanctions" (OFAC, TradeStation Securities, 2026).
The results file should contain the pass and fail criteria with their approval date, the data inventory and its gaps, the replay results by criterion, every disagreement with its review, the seeded test results, the configuration in force with its versions, and the governance that will apply after go-live: who approves setting changes, what the QA sample is, and how performance is monitored. In the sample, the same export that builds a period's examiner export, with every comparison, decision, QA result, list version and setting, assembles the pilot's evidence too.
The evidence export: comparisons, decisions, QA results and list versions for a period
What the transition itself can break
A pilot can pass and the go-live still fail, because a transition creates its own risk. Moving to a new screening or review platform usually means re-screening the whole customer base, which produces a block of alerts no team has seen before. Bank of America's October 2026 settlement records a blocked customer business left unreviewed for months during such a move: "This delay was due to a significant volume of alerts generated by the voluntary rescreening of all existing customer records in connection with the transition to the new screening platform, for which Bank of America was insufficiently prepared" (OFAC, Bank of America, 2026).
The Wolfsberg glossary names the pattern: an alert spike "could be caused by, for example, remediation exercises, changes or updates to policies, procedures or Watchlists". Plan the cut-over re-screen like a designation round: size it in advance, staff it, give it its own clock, and keep payment hits on their own lane. Its guidance also says risk-based screening decisions "should be undertaken prior to the deployment of a new screening system and thereafter on an on-going basis", which is the case for writing the settings, thresholds and reuse rules down before the switch, not after. To plan a pilot on your own past hits and list updates, start from Sanctions Alert Review.
Questions people ask
Can automated sanctions screening run without human review?
Raising hits can be fully automated; deciding them should not be. The enforcement record shows the cost of automation that clears or releases on its own, from Payoneer's backlog releases to Bank of America's suppression rule. In the sample settings, agents propose and people close, escalate and decide.
How many closed alerts should a pilot replay?
Enough to include every kind of hit the bank sees and every true match: a quarter of closed alerts across all channels is a practical base, with true matches and escalations taken from further back if the quarter has few. The sample credit union handled 10,214 hits in the first 22 days of October.
What is a good QA agreement rate for automation?
The bank's own: the rate at which blind QA agreed with its analysts on the same alerts in the same period. Automation should meet or beat it, with every disagreement reviewed by the officer. There is no published regulatory benchmark.
Does automation change what OFAC requires us to keep?
No. Records still have to be kept for 10 years under 31 CFR 501.601, and blocked or rejected transactions reported within 10 business days. Automation should make the records fuller: the list version, every identifier compared and who decided.
Who should sign off a sanctions automation pilot?
The officer responsible for OFAC compliance, with an independent reviewer such as internal audit confirming the method and results. In the sample settings, any later change to thresholds or rules needs both the BSA/OFAC Officer and the Deputy BSA Officer before it is applied.