Screening Systems: Sanctions, PEP & Adverse-Media + False-Positive Tuning *(OUTLINE + BULLET BODY)*

Your screening system flags a wire to "Mohammed Ali." Is that the sanctioned arms dealer on the list — or one of the millions of ordinary people who share that name? Set your filter too loose and you bury your analysts in thousands of false alarms. Set it too tight and you miss the one match that lands your bank a strict-liability OFAC penalty. Screening is a tuning problem with legal consequences on both sides. By the end of this lecture, you'll understand what these systems screen against, how fuzzy matching works, and how to tune the dial without falling off either edge.

- Screening checks customers, counterparties, and transactions against **lists of prohibited or high-risk parties** — at **onboarding** (names) and in **real time on payments** (wire/transaction screening). - It is a **legal obligation, not a best practice**: OFAC sanctions carry **strict liability** (a violation can occur without knowledge or intent), so missing a true match has direct regulatory consequences. - Two distinct jobs: **name/customer screening** (is this party on a list?) and **transaction/payment screening** (does any party or field in this payment message hit a list?).

- **Sanctions lists** — the highest-stakes lists. OFAC's **Specially Designated Nationals and Blocked Persons (SDN) List**, OFAC's **Consolidated Sanctions List**, plus **UN, EU, and UK (OFSI)** lists. A hit can require **blocking** (freeze and report) or **rejecting** the transaction. - **PEP lists** — identify politically exposed persons (and their family/close associates) to trigger **EDD**, not prohibition. PEP status is a **risk flag**, not a block. - **Adverse media / negative news** — searches news and public records for links to financial crime, fraud, corruption, trafficking, etc. Used to inform risk rating and EDD. **Less structured and noisier** than sanctions/PEP lists, with more ambiguity. - **Internal / other lists** — 314(a) requests, prior SAR subjects, exit lists, and law-enforcement requests can also feed screening.

- **Exact (deterministic) matching** fails in the real world because of **transliteration** (Arabic, Cyrillic, Chinese names rendered many ways), **spelling variants, nicknames, word order, typos, missing data, and deliberate obfuscation** by bad actors. - **Fuzzy (probabilistic) matching** scores how *similar* a name is to a list entry and flags anything above a **match threshold**. Common techniques: **phonetic algorithms** (Soundex, Metaphone — match by sound), **edit distance** (Levenshtein — count character changes), and **n-gram/token comparison**. - Good systems also match on **secondary identifiers** — date of birth, nationality, address, document number — to *confirm or de-prioritize* a name hit, sharply cutting noise.

- **False positive** — the system flags a match that **isn't** the listed party (your customer just shares a name). High cost in **analyst time and customer friction**, but caught and cleared. - **False negative** — the system **fails to flag** a true match. This is the **dangerous** error: the prohibited party slips through, creating direct **sanctions-violation and regulatory** exposure. - The trade-off lives in the **threshold**: **lower** the match threshold → more sensitivity → more **false positives**; **raise** it → fewer alerts but more risk of **false negatives**. You cannot minimize both at once — you choose where to sit, and **regulators expect you to err toward catching true matches.** - The volume reality: **most screening alerts are false positives** (often the vast majority), which is exactly why tuning and efficient disposition matter operationally.

- **Threshold tuning** = adjusting match sensitivity, scoring, and rules to balance detection against alert volume — and it must be **governed and documented** (who approved the change, what the impact was). Tuning is a **model-risk activity**; loosening a filter without analysis can create undetected false negatives. - **Testing & validation:** screening filters should be tested with **known-match test data** (synthetic "should hit" names) to confirm the system actually catches what it must — and tuning effects measured **before** going live. - **Watchlist hygiene / list management:** lists change constantly. OFAC updates the SDN List **frequently and with no fixed schedule**, so screening must use **current lists** and re-screen the customer base when lists change. Stale lists = blind spots. - **Good data in, good screening out:** screening is only as good as the **data quality** of customer records and the list source — missing DOBs, garbled names, and poor parsing degrade every match. (Data quality is a recurring theme across Domain 4.) - **Sanctions vs. PEP/adverse-media disposition differ:** a confirmed sanctions hit drives **block/reject + report**; a confirmed PEP or adverse-media hit drives **EDD and risk-rating**, not prohibition. Don't conflate the actions.

So screening is three lists and one dial. The lists: sanctions, where a true hit means block or reject and there's strict liability if you miss it; PEPs, where a hit means enhanced due diligence; and adverse media, the noisy one that informs risk. The mechanism is fuzzy matching — phonetic and edit-distance scoring against a threshold — because exact matching can't survive transliteration, typos, and deliberate evasion. And the dial is the trade-off you can never escape: lower the threshold and drown in false positives, raise it and risk the false negative that gets through. Tune deliberately, test with known matches, keep your lists current, and feed the system clean data. Next, we turn from screening *names* to watching *behavior* — transaction-monitoring technology: rules, scenarios, thresholds, and the model validation that keeps them honest.