## TL;DR
A name only OFAC hit on a common name is a potential match, not a confirmed match, and it should trigger disambiguation, not an automatic permanent block. Compare the full identifiers you hold, date of birth, address, government id, country, against the listing details; true listings carry identifiers your common name payee will not share. Route potential matches to a trained reviewer with a documented decision trail, release the false positives with the rationale recorded, and tune fuzzy matching with compliance approval so transliteration variants are caught without blocking every similar name.

```text
ofac screening false positive on common name blocking payouts
```

## Use this when
- Payouts are held for payees whose only match is a common first and last name.
- Reviewers release the same false positive names repeatedly with no learning loop.
- Your screening tool offers no identifier comparison on the match screen.

## Not for this skill when
- Identifiers match beyond the name. Treat it as a potential true match, freeze, and follow your escalation and reporting procedure.
- Screening found nothing at all after a list update failure. That is the stale list problem, a different failure.

## Steps
1. Open a blocked case and lay the payee identifiers beside the listing identifiers: date of birth, addresses, id numbers, and listed aliases. Verify: the case shows which identifiers match and which conflict.
2. Adopt a written disambiguation standard with compliance: which identifier conflicts clear a match, and which combinations still escalate. Verify: the standard is signed off and stored with your screening procedure.
3. Work the current backlog case by case under that standard, recording the decision rationale on each release or escalation. Verify: every held payout has a documented screening decision.
4. Configure your screening tool to score matches using available identifiers and to surface them on the review screen, with compliance approving any threshold change. Verify: new matches arrive with identifier comparison visible to the reviewer.
5. Add released false positives to a reviewed and approved internal allowlist with expiry dates, so the same cleared payee is not reblocked every cycle while still being rescreened against list changes. Verify: a previously cleared payee passes with the clearance noted, and the entry expires on schedule for re review.

## Variant phrasings
### ofac name match false positive payout held
Payout phrasing.
### sanctions screening common name how to clear
Clearance phrasing.
### potential ofac match vs true match review
Review standards phrasing.

Compatibility: OFAC and global sanctions screening tools including Sift, ComplyAdvantage, Dow Jones, and in house list matching. Procedures must align with your BSA and AML compliance program and OFAC guidance.

## Why it happens
Sanctions lists are name centric and many entries carry thin identifiers, while payment populations are full of common names. A screener configured to block on name similarity alone converts a review obligation into an automatic punishment for having a common name, and without identifier comparison tooling, reviewers cannot clear matches efficiently even when they want to.

## Edge cases / pitfalls
- Never let business pressure create a release shortcut. Every release needs the identifier rationale a regulator can read later.
- Aliases and transliterations cut both ways: aggressive fuzzy matching floods review, weak matching misses true variants. Compliance owns that dial.
- Rescreen the whole payee base on list updates, including previously cleared names. A clearance is against a list version, not forever.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y9bDOAvkfoiiD_4qMAZG1A