OFAC false positive procedures when the list entry has changed

OFAC false positive procedures set how a bank clears a screening hit that turns out not to be the listed person, and, just as important, when it may rely on that decision again. The second part is where procedures fail. A hit closed last month can be suppressed, linked or closed on the same reason this month only if neither the list entry nor the customer has changed in between, because a false positive is a judgement about two sets of identifiers at a moment in time, not a permanent truth about a name. OFAC keeps no history of earlier entry versions in its search tool, so the bank has to keep it. Botminds' Sanctions Alert Review reuses an earlier closure only when the entry version is identical, and reopens the hit, with the reason that no longer holds, when it is not.

The worked example is a fictional sample, Norrell Federal Credit Union, as its hits run through the solution. The enforcement details come from OFAC and OFSI, quoted from their own notices.

…released automatically due to an “alert suppression rule,” a screening function used by Bank of America that automatically “suppressed” alerts in certain circumstances—for example, if an alert was based on the exact same criteria as an alert that a Bank of America analyst manually dispositioned as a false positive in the past.

OFAC, settlement with Bank of America, N.A., October 13, 2026

What OFAC false positive procedures must cover

A false positive procedure has to cover two decisions, not one: how a hit is cleared the first time, and when that clearance may be reused. OFAC's guidance covers the first in detail. FAQ 5 asks for a comparison of every detail in the full list entry and a record of the information relied on, and it says OFAC will not confirm the answer (OFAC FAQ 5). The method is set out step by step in what to do with an OFAC hit.

The second decision is mostly left to the bank, and every program makes it, explicitly or not. A screening system that suppresses repeat alerts, a "good guy" list of cleared customers, an analyst who recognizes a name from last week and closes it with the same note: all three reuse a past judgement. The procedure question is what that judgement was about, and therefore when it expires.

Can I auto-close an OFAC hit I cleared before?

You can, but only on a rule that proves nothing has changed since the first clearance, and only if the rule is documented, supervised and tested. No OFAC regulation forbids suppression. What failed in Bank of America's case was suppression on "the exact same criteria" as an earlier false-positive decision, which is a test of the alert, not of the entry or the customer behind it.

The release is specific about the consequences. After Russia's February 2022 invasion of Ukraine, the bank's payment routing directory included banks OFAC had just blocked. Payments through them went out for three reasons: the filter had not yet been updated, analysts cleared some as false positives in error, and others "were released automatically due to an 'alert suppression rule'". In all, the bank processed 403 transactions totaling $14,340,100 via 35 blocked banks. OFAC settled for $11,662,930, counted against the bank that it had already received several cautionary letters for much the same conduct, and drew the lesson for every program:

…decisions concerning sanctions screening alert parameters and rules should be risk-based, adequately supervised, and subject to audit and testing in order to prevent errors from compounding.

OFAC, Bank of America, compliance considerations

"Errors compounding" is the precise risk of reuse. One wrong closure is one error. A suppression rule built on that closure repeats the error every time the same criteria come round, silently, with no analyst in the loop to notice that the counterparty's status has changed.

What happens when the SDN entry changes after you cleared it

When an SDN entry changes, the details your earlier false-positive decision rested on may no longer be true, and the decision should be treated as void until the hit is compared again. OFAC amends entries routinely: it adds dates of birth, places of birth, aliases, addresses and ID numbers as it learns them. A closure that rested on "the entry gives no date of birth" or "the entry's only address is in another country" is a closure about a version of the entry that no longer exists.

OFAC will not keep that version for you. Its Sanctions List Search "does not contain historical information", and "targets that have been updated only appear with their most up to date entry information" (OFAC FAQ 467). OFAC does publish an archive of changes to the SDN list and archived delta files through its Sanctions List Service. But an analyst looking at an old closure next to today's entry cannot see, from the search tool, what the entry said on the day the closure was made, unless the bank stored it.

The UK has a recent example of what duplicate logic can do. In its September 2025 disclosure on Vanquis Bank, OFSI recorded that in 2024 "a separate risk event was identified in the automated screening system. This event resulted in a number of alerts being falsely closed as duplicates." The bank pulled staff from its first-line team to re-review them, and when a new designation came, the potential match alert waited eight days for review while the designated person withdrew cash (OFSI, Vanquis Bank Limited, 2025). The duplicate errors did not themselves let the designated person through; the cost of cleaning them up did.

Good guy lists, whitelists and suppression: what Wolfsberg allows

The Wolfsberg Group's 2019 sanctions screening guidance treats suppression as a legitimate, risk-based design choice that must be governed. It lists among the decisions a bank may make: "Suppression - use of suppression rules or 'Good Guys' lists to manage common false positive alerts requiring unnecessary manual review." It also describes whitelisting as "rules for automatically eliminating potential hits caused by the interaction of certain list terms and frequently encountered data, for example, customer names which have already been confirmed as false positives" (Wolfsberg Guidance on Sanctions Screening, 2019).

The same guidance attaches two conditions that matter here. "A governance framework should contain the documented rationale for risk based decisions, such as those made in support of the creation of screening rules and threshold settings." And, of internal lists, "Regular reviews of entries are helpful to ensure intelligence does not become stale or outdated." A good-guy list is an internal list of past judgements. Its entries go stale the moment the sanctions list they were judged against changes.

A validity test for reusing a false-positive closure

A false-positive closure stays valid while four things hold: the list entry is the same version it was decided against, the customer's identifiers are the same, the identifiers that disqualified the match still disagree, and the closure itself has not been reopened or overruled. If any fails, the hit goes back to a person. Time alone does not expire a closure, but it is a reason to check the other four.

Test 1 is the one most systems skip, because most screening systems store the alert and the decision but not the entry as it read. Applying it needs only two things: an entry version or fingerprint captured with every closure, and a comparison of that version against the current one before any reuse. Test 3 is the one that catches the case where the old reason was an absence. "Entry lists no date of birth" is a valid reason only until OFAC adds one.

One reopened closure, worked through

On September 3, an analyst at the sample credit union, Keisha Monroe, closed a hit on member Samir Haddad against SDN entry 48807, because version 2 of the entry had no date of birth. The closure rested on an absence: nothing on that version of the entry could tie the name to him. On October 21, OFAC's update amended the entry to version 3, adding a birth year of 1984, a place of birth, Beirut, and an alias. Samir was born on March 3, 1984, in Beirut.

That evening's re-screen raised a new hit on the same member and the same entry. A rule that matched on "the exact same criteria" would have linked it to the September closure and moved on. Instead, the next morning, the solution's duplicate guard compared versions, found 2 against 3, and reopened the hit with the old reason shown and struck: "entry lists no date of birth" no longer holds. Compared again, 3 of 5 identifiers matched, and the hit went to the OFAC Officer as a potential match.

The duplicate guard in Sanctions Alert Review: 7 hits reopened because their entry changed, 54 linked

What a false-positive rationale should contain

A false-positive rationale should name the list entry and its version, every identifier compared on both sides, which ones conflict and which were missing, and who decided. That is what lets a later reviewer apply the validity test without redoing the work. A rationale that says only "not a match" or "different DOB" can neither be checked nor safely reused.

A closure in Sanctions Alert Review: reason codes, an editable rationale, and the entry version kept

The difference shows up on the day the entry changes. With the typed reason, nobody can tell whether "no match on DOB" meant a different date or no date at all, and the safe answer is to redo every closure against that entry by hand. With the structured one, the system can tell which closures relied on a missing value and reopen only those. That is also why how fast a bank applies OFAC list updates matters to false positives as much as to new designations: every amendment is a chance for an old closure to expire.

How long is a false-positive decision valid?

No OFAC rule sets a period. A false-positive decision is valid for as long as the list entry and the customer it compared are unchanged, which may be years for a stable entry and one evening for an entry OFAC amends. Some programs also set a review interval, re-checking long-standing good-guy entries on a schedule, which is the Wolfsberg point about internal lists going stale.

The practical design is to make expiry event-driven rather than calendar-driven. Each OFAC update names the entries it added, amended or removed. A bank that keeps the version each closure was decided against can expire exactly the closures that relied on a changed entry, the same evening, rather than waiting for an annual review or the next alert. To see that in the product, start from Sanctions Alert Review.

Questions people ask

What is a good guy list in sanctions screening?

A good-guy list, or whitelist, is a bank's own list of customers or terms already confirmed as false positives, used to suppress repeat alerts. The Wolfsberg Group's 2019 guidance treats it as a legitimate risk-based decision if its rationale is documented and its entries are reviewed so they do not go stale.

Is alert suppression allowed in sanctions screening?

No OFAC rule forbids it, but OFAC's 2026 settlement with Bank of America shows the risk: a rule that suppressed alerts matching an earlier false-positive decision on "the exact same criteria" let payments through blocked banks. OFAC expects alert rules to be risk-based, supervised, audited and tested.

Does OFAC keep old versions of SDN entries?

Not in its search tool. OFAC's FAQ 467 says Sanctions List Search has no historical information and shows updated entries only in their latest form. OFAC publishes an archive of list changes and delta files, but a bank that wants to know what an entry said on the day it cleared a hit should store that version itself.

Should a changed customer address reopen a cleared hit?

It should trigger a fresh comparison of the changed field. If the earlier closure relied on the address conflicting with the entry, and the new address no longer conflicts, the closure no longer holds and the hit should go back to an analyst.

Can a linked duplicate be closed automatically?

Only by a rule your program has documented and tested, and only on an identical entry version and identical customer identifiers. In the sample credit union's settings, the duplicate guard links such hits but an analyst still confirms each one, and confirmed duplicates stay in the QA sample.