TL;DR: Automated screening alerts are a configuration, not a switch. A LexisNexis article on screening, citing a KPMG footnote, notes that false positive rates of 95 percent or more are not unusual. OFAC's Framework for Compliance Commitments tells an institution to select and calibrate screening to its risk profile, test that calibration routinely, and keep a record of what the screen identified, interdicted, escalated, and reported.
Decide which lists you screen
List coverage is a policy choice made before the tool is turned on. OFAC's Framework for Compliance Commitments tells an institution to select and calibrate screening solutions to its risk profile. The Framework names the SDN List and the SSI List among the lists a program should be ready to use. Those two names are the starting inventory, not a reason to accept every file a vendor bundles into a default feed.
The SDN List and the SSI List do not share one disposition. The setup should store, for each list the policy includes, the action a true match requires. A screen that collapses every list into one alert code forces the analyst to rediscover that difference on every case.
Other lists enter the screen only when the risk profile says a product, a customer type, or a geography creates exposure those lists address. Adding a list the policy never names creates alerts no queue owns. Omitting a list the policy does name is a gap the test pack should catch before an exam does. Write the included lists into the procedure with the reason each one is there. A vendor checkbox is not that reason.
Refresh is part of coverage. The Framework says to update screening when OFAC changes a program or a list. Name who checks that the new file loaded, which version identifier is stored with that day's alerts, and what happens if the load fails. Screening yesterday's SDN file against today's payments misses a designation posted in between. That miss is a setup failure.
Name screening of the customer on those lists is a separate step from ownership analysis. A clean result on the customer's own name does not answer whether owners, aggregated, change the outcome. That question is covered in the OFAC 50 percent rule guide. The list decision in this setup still has to be explicit: which files run, on which parties, and which version was live when the alert fired.
Set the match bar from your risk
A fuzzy-match threshold decides which name differences become alerts. Transposed tokens, missing punctuation, shortened legal endings, and transliteration all push a true name away from an exact string. The threshold is how far the institution is willing to reach. OFAC's Framework says to calibrate the solution to the risk profile and to test that calibration. A number copied from a vendor default has no record of the names, scripts, or products it was chosen for.
The cost of a wide bar shows up as false alerts. The same LexisNexis screening article, citing a KPMG footnote, states that false positive rates of 95 percent or more are not unusual. That figure is a warning about an uncalibrated screen, not a target to copy. A bar wider than the risk profile floods the queue. A bar tighter than the profile suppresses names the policy says must surface. Neither failure is visible from the vendor default alone.
Set the bar from cases the institution can explain. One set holds names the policy must catch: a current SDN name, an SSI name if that list is in scope, and variants the business actually sees, such as a reordered surname. A paired set holds names the policy expects to clear. Run both at the proposed threshold and record the threshold, the list version, the catches, and the extras. That record is the calibration. Sanctions screening name matching describes how string differences produce the extras. The threshold still belongs to the institution's risk, not to the matcher.
Write the threshold into the procedure: the value, the lists it applies to, and the reason it fits the names and products in scope. If payments, onboarding, and periodic rescreening use different bars, say so and say why. When the value changes, keep the old value, the new value, the date, and the retest. The Framework also expects an update when OFAC changes a program or a list, and a rerun of the catch set and the clear set before the old bar is treated as still fit.
Every alert needs a place to go
An alert that fires and sits in a general inbox is not a control. OFAC's Framework expects the program to identify, interdict, escalate, report, and keep records. Each word needs a path before the screen goes live. Identify stores the list, the version, the submitted name, the listed name, and why the matcher connected them. Interdict is the action the policy requires while the match is unresolved. Escalate is the handoff when the first reviewer cannot finish the case. Report is the notice the policy requires once a match is confirmed. Records show that each step happened.
Keep the disposition codes few, and keep a clear distinct from an escalation. A workable minimum is a clear with a written reason, an escalation with a written reason, and a confirmed match that follows the interdict-and-report path for that list. Auto-clear belongs only where the procedure names the pattern and the system writes the reason. Make the reason required. Store it with the analyst, the time, the list version, and the evidence reviewed.
Finish the paths before go-live. LexisNexis and Forrester reported on February 21, 2024 that screening alerts rose at 83 percent of mid-size and large organizations and at 87 percent of small organizations. A rising count punishes a setup that never decided where an alert goes. The paths depend on codes, required reasons, and a queue that matches the policy. A February 2025 survey by SAS, KPMG, and ACAMS of 850 members found that 28 percent said triaging alerts is where AI and machine learning offer the most value. That finding is a reason to make the triage path precise, with a written reason on every clear and every escalation.
The file on a cleared alert has to stand alone. A later reviewer should see the listed name, the submitted name, the list and version, the match reason, what was checked, and why the names are not the same party. "Not a match" is not that explanation. On an escalation, the first reviewer records what was already checked. On a confirmed match, the file keeps the interdict action and the report that followed.
Test the screen before the exam does
Routine testing is part of the Framework, not an extra the vendor offers after an exam comment. Run the test pack before the screen processes live customers, and run it again when OFAC changes a program or a list, when the threshold changes, and on the cycle the procedure names. A test that happens only at install goes stale the first time the SDN file changes. The result to keep is a record: date, list version, threshold, cases, expected outcomes, actual outcomes, and who reviewed the differences.
The pack needs a true name from the current SDN List in the test environment, an SSI name if that list is in scope, a non-match the policy expects to clear, and a list-update case. The SDN case must alert onto the interdict path. The SSI case must land on the SSI disposition, not the SDN one. The non-match must stay quiet or clear with a written reason. The update case must show that a newly added name alerts and that the stored version identifier changed. If the true name does not alert, the clear saves with an empty reason, or the two lists share one disposition code, fix the configuration and rerun. Do not go live on a partial pass.
After go-live, sample clears, escalations, and confirmed matches for the same contents: a written reason that distinguishes the parties, a handoff note, and, on a confirmed match, the interdict action and the report. A count of closed alerts will look healthy while empty reasons accumulate. Tool choice comes after these decisions. A comparison of sanctions screening software is useful once the procedure says what the software has to record. The product can load lists and open cases. The product does not choose the lists, the bar, or the queue.
Where Sphinx fits
Sphinx agents apply the institution's lists and thresholds, clear or escalate with a written reason, and keep that record in the case system. Humans still own matches the policy will not auto-clear.
Frequently Asked Questions
Which sanctions lists should an automated screen include?
OFAC's Framework for Compliance Commitments expects screening calibrated to the institution's risk profile, and it names the SDN List and the SSI List. The list set should match the products, customers, and geographies the institution actually touches. Update that set when OFAC changes a program or a list.
How often should the SDN list be refreshed?
Refresh the SDN List when OFAC changes it, not on a schedule a vendor chose by default. OFAC's Framework tells institutions to update screening when OFAC changes a program or a list. A screen that runs a stale file can miss a designation posted since the last refresh.
What is a defensible way to set a fuzzy-match threshold?
Set the fuzzy-match threshold from the institution's risk profile, then test it against names the policy must catch and names the policy expects to clear. OFAC's Framework says to select and calibrate screening solutions to that profile and to test them routinely. A threshold copied from a vendor default has no record of why it fits the names and products the institution screens.
What should the file show when an analyst clears a screening alert?
The file should show which list fired, why the name matched, what the analyst reviewed, and a written reason for the clear or the escalation. OFAC's Framework expects institutions to identify, interdict, escalate, report, and keep records. A cleared alert with no written reason leaves the record short of that standard.
.png)
