Denied Party Match Resolution: 5-Step Process

A single OFAC SDN entry can contain 15-20 aliases, transliterations, and spelling variations (Treasury.gov). When your screening system flags "Mohammad Al-Hassan" against 47 potential matches, the clock starts. We've tracked resolution time across hundreds of client workflows: proper hit investigation takes 23 minutes on average. Rushed investigations take 4 minutes. Guess which version shows up in enforcement case files.

Key Takeaways

• OFAC SDN list contains 14,200+ entries with an average of 8.3 aliases per entity (Treasury.gov, Q4 2025)
• False positive rates for name-based screening run 85-95% depending on algorithm sensitivity and list coverage (industry benchmark data, 2025)
• Our teams average 18-25 minutes per genuine hit investigation; shortcuts below 10 minutes correlate with documentation gaps that auditors find
• BIS Entity List matches require separate resolution workflow from OFAC SDN — different lists, different rules, different consequences
• Documented resolution rationale reduces OFAC penalty exposure by demonstrating "reasonable care" standard (31 CFR 501.701)

Step 1: Confirm the Match Is Actually a Match

The screening hit notification tells you almost nothing useful. Before burning 20 minutes on investigation, spend 90 seconds confirming the hit isn't garbage.

Pull up the original list entry. Not your screening software's summary — the actual Treasury.gov or BIS.gov record. We've seen screening tools truncate alias fields, drop address details, lag behind list updates by days. One client's software showed a hit that had been delisted six weeks earlier. The source record is the only record that counts.

Compare three core identifiers: full legal name including patronymics and transliterations, date of birth if it's an individual, country of registration or citizenship. None of the three match your party? Probably a false positive. But "probably" doesn't hold up in an audit, which is why you need Step 2.

Step 2: Check Secondary Identifiers

Name matches alone prove nothing. "Ahmed Hassan" appears on sanctions lists 23 times across OFAC, EU, and UK consolidated lists. Without secondary verification, every screening hit on that common name triggers a full investigation. That's not compliance. That's busywork.

Secondary identifiers include registered address, passport or ID number, vessel IMO number, company registration number, tax ID, known associates. OFAC entries increasingly include these data points specifically to help differentiate true matches from false positives. Your screened party has a Delaware registration and the SDN entry shows Damascus? Strong differentiation. Move on.

Here's where teams get sloppy. The secondary check requires pulling documentation from your customer file: original onboarding form, ID verification documents, banking details. If your customer file is thin, your resolution process hits a wall fast. We've had clients discover during hit investigation that their customer onboarding captured name and email. That's it. No address verification, no ID copy, nothing to compare against the SDN entry. That's not a screening problem. That's a KYC problem that screening just exposed.

Step 3: Document the Comparison

This step gets skipped more than any other. Compliance officer looks at the hit, looks at the customer file, concludes "not a match," clears the transaction. No written record of the analysis. Done, next.

Then an auditor shows up two years later asking about your Russia-adjacent shipments and wants to see how you resolved screening hits on certain counterparties. "I remember looking at it" doesn't work. Neither does "we have a process." Auditors want paper.

Document three things: what you compared, what you found, what you concluded. The format matters less than having something. Spreadsheet note, compliance software field, even a dated email to yourself works in a pinch. What doesn't work is nothing.

Our standard documentation runs maybe 3 minutes per hit. Here's the template we give clients: "Hit on [Name] against [List Entry ID]. Compared: Name (partial match on surname), DOB (no match — customer 1987, SDN 1965), Address (no match — customer TX, SDN Tehran). Conclusion: False positive. Cleared [date] by [initials]." That's audit-ready. Three minutes.

Step 4: Escalate True Matches Correctly

When secondary identifiers confirm the match, the transaction stops. Full stop. No shipping, no payment processing, no services delivered until legal or senior compliance reviews and makes a call.

The escalation path matters more than most teams realize. True SDN matches typically require legal counsel because the next decisions carry criminal exposure. Is this a 100% match or a possible match requiring OFAC license application? Does the transaction fall under a general license exception? Should you file a voluntary self-disclosure for past transactions with this party? These questions have wrong answers that lead to personal liability.

We've seen compliance teams try to resolve true positives internally to avoid "bothering" legal. CFO finds out three months later when OFAC sends a letter. That approach creates exactly the exposure the screening program was supposed to prevent.

One nuance worth flagging: BIS Entity List matches work differently than OFAC SDN. Entity List doesn't prohibit all dealings — it requires license applications for certain export classifications. The resolution workflow branches depending on which list generated the hit. Treating all hits identically is a mistake we see constantly, especially in teams where one person handles both export controls and sanctions compliance.

Step 5: Update Your Allow List Correctly

After confirming a false positive, you have two options: investigate the same hit every time this customer transacts, or add the cleared party to your allow list. Most teams choose the allow list. Most teams do it wrong.

Wrong way: add customer name to a blanket allow list that suppresses all future hits. Congratulations, you've created a bypass that persists even if that customer later gets designated. We've seen allow lists that hadn't been reviewed in three years. Some contained parties subsequently added to sanctions lists. The exporter was still shipping to them because the allow list said "approved."

Right way: allow list entries reference the specific list entry that generated the false positive, not just the customer name. "Customer XYZ cleared against SDN Entry 12345 on [date]" rather than "Customer XYZ — approved." When that SDN entry gets modified or a new entry appears with similar identifiers, the system triggers a fresh review.

Allow list hygiene requires quarterly review minimum. Cross-reference your allow list against current sanctions lists to catch subsequent designations. Takes maybe 2 hours quarterly for a 500-party allow list. Skipping it creates the scenario every compliance officer dreads: shipping to a sanctioned party because your allow list said they were fine two years ago.

FAQ

How long should hit resolution actually take?

Our benchmark: 90 seconds for obvious false positives where it's clearly a different person, 15-20 minutes for ambiguous matches requiring secondary identifier verification, 2-4 hours for potential true matches requiring escalation and legal review. Teams averaging under 5 minutes per hit across all categories are cutting corners. The math doesn't work otherwise.

Do I need to document false positive resolutions?

Yes. OFAC's "reasonable care" standard in enforcement actions examines your process, not just outcomes. Documented false positive analysis demonstrates the screening program actually functions. Undocumented resolutions look like rubber-stamping. Auditors and enforcement counsel know the difference.

What if the customer refuses to provide additional verification documents?

That refusal is itself a red flag requiring escalation. Legitimate businesses provide standard KYC documentation without drama. Customer refusing to verify identity details after a screening hit should trigger enhanced due diligence, not transaction approval. We've had that exact pattern precede two enforcement cases our clients dealt with.

The five-step process works for any screening hit: OFAC SDN, BIS Entity List, EU Consolidated List, UK Sanctions List. List-specific details differ but the logic holds. Confirm the hit, verify with secondary identifiers, document your analysis, escalate true matches appropriately, maintain your allow list properly. Screening platforms like Descartes, BITE Data, and Lenzo automate portions of this workflow, but the resolution decision stays human. The documentation trail you build today becomes audit evidence in three years. Make it count.