OFAC interdiction software: replay last quarter's held payments first

OFAC interdiction software is the filter that screens payments, and often customers, against OFAC's sanctions lists and stops potential matches for a person to review. OFAC does not require banks to use it: no law or regulation obliges a bank to run software or scan its payments (OFAC FAQ 43). What OFAC does require is that no blocked person is paid and no prohibited payment is processed, and the federal banking examiners expect the choice of software and its sensitivity to follow the bank's risk and volume. That puts the burden of proof on the bank. The most convincing evidence, before buying a filter or adding an agent layer such as Botminds' Payment Sanctions Screening, is a replay: run a closed quarter of your own held payments, including every reject and block, through the candidate and count what it would have done.

Is OFAC interdiction software required?

No. OFAC's FAQ 43 says so directly, and adds the obligation that remains: the bank must still never deal with a target or let blocked property through (OFAC FAQ 43; what that leaves software to do after a block is set out in OFAC compliance software). Asked whether a bank has to buy expensive software, OFAC sends the question to the bank's regulator and observes that the packages on the market differ widely in price and in what they can do (OFAC FAQ 27; how to compare them is in sanctions screening software comparison). It also notes that its lists can be scanned by hand and that it offers a free online search engine.

The regulators' view is in the FFIEC examination manual: a bank with low OFAC risk and few transactions may screen by hand, and whether to buy interdiction software, and how sensitive to set it, should follow from the bank's own risk assessment and volumes (FFIEC BSA/AML Examination Manual, OFAC). For a bank that sends international wires every day, interdiction software is not a legal requirement, but it is hard to imagine meeting the obligation without it.

What the regulator expects you to prove

Regulators expect the bank to show that its filter finds what it should, at a sensitivity the bank chose for a reason. The FFIEC sets the bar for high-risk areas: where risk and volumes are high, the filter should catch close variants of listed names and send them to a person, and banks "should periodically reassess their OFAC filtering system" (FFIEC BSA/AML Examination Manual, OFAC). The Wolfsberg Group adds the testing expectation: testing that is independent and sized to the risk, proving the filter raises the alerts it is supposed to raise (Wolfsberg Guidance on Sanctions Screening, 2019; a seeded test file built from enforcement cases is in sanctions screening testing).

OFAC has been pointed about tools that are installed and then trusted. In a March 2026 settlement it wrote that "firms should ensure they are not overly relying on a patchwork of software or taking a 'set it and forget it' approach to compliance" (OFAC, TradeStation Securities, March 2026).

A filter is proved on the payments it has already stopped, with the answers held back, not on a vendor's demonstration.

How do I know my interdiction filter works?

You test it two ways: with planted cases you know should hit, and with your own real traffic. Planted, or seeded, tests check sensitivity: listed names spelled differently, transliterated, abbreviated or reordered; listed BICs and vessel IMO numbers in the agent and free-text fields; sanctioned cities under alternative spellings. Real-traffic replay checks everything else: false hits, behaviour on messy data, and whether the results would have matched the decisions your analysts made.

OFAC's own cases show which seeded tests to include. Its 2019 Framework names filters that missed other spellings of sanctioned places and parties, the Spanish, German and French forms of Havana, Cuba and Sudan among them (OFAC, A Framework for OFAC Compliance Commitments). In the UK, OFSI's penalty against Bank of Scotland turned partly on a passport name four small edits away from the listed one, two in the forename, one in the surname and a dropped middle name, which the bank's screening failed to connect (OFSI, Bank of Scotland, penalty imposed November 10, 2025). Each belongs in a seeded set as a planted case.

The point of the seeded set is to measure the trade-off, not to eliminate it. A peer-reviewed study of name matching for sanctions screening frames it as a curve: set the similarity line low, around 70%, and false alarms multiply; set it near 99% and they fall, but real matches start to slip through (Kim and Yang, Frontiers in Artificial Intelligence, 2024; where a bank should draw that line is the subject of sanctions screening threshold). The replay tells you where on that curve a candidate sits with your data.

Can I replay old payments through a new tool?

Yes, and you already hold what you need. OFAC requires records relating to transactions subject to its rules to be kept for at least 10 years after the transaction (31 CFR 501.601), so a bank has the original messages, the alerts its filter raised and the decisions its analysts made. A replay feeds those messages to the candidate, in a test environment, and compares its output with what happened.

Run it twice. First against the list versions in force at the time, so the candidate's recommendations can be compared fairly with your analysts' decisions. Then against today's lists, as a lookback: a payment that cleared correctly in March may involve a party designated since. Bank of America's 2026 settlement shows the cost of doing the lookback too narrowly: the bank "initially performed only a single, narrowly tailored lookback" and found the full scope of its payments through blocked banks only after OFAC's subpoena (OFAC, Bank of America, October 2026).

Building the replay set

The set should be large enough to be honest and built around the cases that matter most. A closed quarter of held payments is a good unit: long enough to include list updates and seasonal traffic, short enough to review the differences by hand. Every reject and every block in the quarter goes in, because those are the stops a candidate must not miss. Then a random sample of releases, every list-update day, and seeded cases for what the quarter did not happen to contain.

The sample bank behind this guide applies the same idea to its own changes: every new version of the agents' prompts or models is tested on 600 seeded payments, 60 of them true hits, before the Head of Sanctions approves it. The bank, payments and figures in that example are fictional sample data.

What results should a replay show?

It should show four things, in this order: no missed stops, the false-hit volume by field, agreement with your past decisions, and the time and evidence behind each recommendation. Missed stops first, because a quieter filter that misses one blocked party is worse than a noisy one that misses none. Payoneer's 2021 settlement is the reminder of what testing is for: OFAC urged "performing algorithm testing to be sure filters are flagging payments within expected parameters" (OFAC, Payoneer Inc., 2021).

Agreement is the measure most vendors will lead with, and it needs care. On the sample bank's data in Payment Sanctions Screening, the agents' recommendation matched the analyst on 638 of 643 decided hits; each of the five differences is recorded with the analyst's reason. High agreement says the candidate reasons the way your analysts do. It does not say either is right; that is what reading the differences is for.

How do I compare false positives between tools?

Only on the same payments, the same list version and the same threshold, and per field. A tool that reports fewer alerts may simply screen fewer fields; a tool that clears more hits may be clearing some it should not. Count alerts per 1,000 payments for each tool on the replay set, split by where the hit sat: party name, bank, vessel, place or free text. Then count, for each tool, how many of its non-alerts were in fact rejects, blocks or seeded true hits.

Be wary of headline reduction figures. The most rigorous public study, by Federal Reserve Board economists, found large language models cut false positives by 92 percent against the best fuzzy-matching baseline while detecting 11 percent more true matches, but on synthetic name variants generated for the study, and in a working paper rather than a peer-reviewed journal (Allen and Hatfield, FEDS 2025-092). A vendor's figure from its own data is weaker still. Your replay is the only figure that describes your payments.

Separate the two layers when you compare. Payment Sanctions Screening does not change the filter's threshold, which stays with the bank's screening service; it works on the payments the filter has already stopped. Its replay is therefore measured on recommendations and evidence for held payments, not on alert volume. How that layer sits beside an existing filter is set out in payment screening solutions that sit beside your filter.

The stops a replay must not miss: blocks and rejects with their reports

Reading the results: four failure patterns from enforcement

When a replay finds a miss, OFAC's enforcement history usually has a name for it. Four patterns recur, and a replay set should be built to expose each one.

• Tuned too tight. A filter set to alert only on exact matches lets a listed bank with a near-identical name through, as Deutsche Bank Trust Company Americas found in 2020.
• Identifiers left out. A filter that does not load the BICs in OFAC's entries misses a listed bank named differently, one of the failures in the Payoneer case.
• Spelling variants not reconciled. The Bank of Scotland case turned on a few changed characters in a passport name.
• Lists not updated. At Bank of America, a vendor's mistake left the bank screening against an SDN file that missed OFAC's latest changes for five weeks in 2023, and six payments involving designated entities went through (OFAC, Bank of America, October 2026; the clock from designation to restriction is in OFAC sanctions list updates).

A replay against the list versions of the time catches the first three; only a check on how quickly each list update was loaded catches the fourth. Ask for the load times too.

A list update loaded and its lookalike hits gathered: a scenario every replay needs

A replay is also the honest way to see any agent layer, ours included. We run Payment Sanctions Screening on a sample of a bank's own held wires, IAT and instant payments, against its own list versions and earlier decisions, before anything else is decided. Where automation should stop in live use is covered in real time payment screening: agents prepare, a person releases, and the product itself is on the Payment Sanctions Screening page.

Questions people ask

What is the purpose of OFAC interdiction software?

To find, among a bank's payments and customers, the few that may involve a sanctions target, and stop them for a person to review before the money moves. OFAC's FAQ 5 describes the next step: much of what screening stops turns out to be a false positive, and a person compares the list entry with the payment to decide which.

Does OFAC certify or approve interdiction software?

No. OFAC says the question of software is primarily one for the bank's regulator, and that the packages on the market vary considerably in cost and capabilities. It suggests asking peer banks what they use and whether it works for them; the bank remains responsible for the outcome.

How often should an interdiction filter be tested?

On a schedule set by risk, and whenever something material changes: a new list source, a threshold change, a new payment format such as ISO 20022, or a new vendor. The FFIEC asks banks to periodically reassess their filtering, and Wolfsberg calls for an independent, risk-based testing regime.

How long should a replay take?

The run itself is quick; the work is in assembling the set and reading the differences. Plan for the reading: every miss, and every case where the candidate disagreed with your analysts, should be reviewed by someone senior before the results are accepted.

Can a replay include payments that were blocked?

It should. Blocks and rejects are the decisions a candidate must reproduce, and the bank already keeps the messages and reports for 10 years under OFAC's recordkeeping rule. Run them in a test environment, never against live payments.

Is manual filtering acceptable instead of software?

For some banks, yes. The FFIEC says banks with lower OFAC risk and low volumes of transactions may decide to manually filter, and OFAC offers a free online search of its lists. A bank sending international wires daily will find it hard to show that manual filtering keeps pace.