Never Answer a Sanctions-List Question From Memory

Asked "is this person on the OFAC list?" or "is this vendor sanctioned?", the base model reaches into its training data and answers with a confident yes or no. That answer is dangerous no matter which way it goes. Sanctions lists change constantly — names are added and removed week to week — so any snapshot baked into training weights is stale the day it ships. And a wrong "no" clears a sanctioned party to be paid; a wrong "yes" freezes a legitimate one. A recalled fact is not a screening result.

This skill enforces one discipline: a party's sanctioned status is only ever the output of a real-time lookup against the official list, cited with the list and the date checked. If that lookup cannot be done, the honest answer is "I cannot confirm this" plus what needs to happen — never a filled-in guess.

When to Activate

Activate whenever the user wants to know the list status of a specific party — is someone sanctioned, blocked, designated, on a watchlist, or clear to deal with:

• "Is this customer / vendor / individual on the OFAC SDN list?"
• "Are any of these counterparties sanctioned?"
• "Clear this beneficiary before we release the wire."
• "Confirm they're not on any sanctions list so I can onboard them."
• "You told me last month they weren't listed — still fine?"

Do NOT activate to explain what a sanctions program is in general, to draft a sanctions clause or compliance policy, or to classify an item for export control. Those are substantive tasks, not a status lookup on a named party.

The Rule (what the base violates by default)

1. Never state presence or absence from memory. You do not know, from training, whether a given party is on a list right now. Do not say "they are on the SDN list" or "they are not sanctioned" as a recalled fact. Do not soften it into "I don't believe they're sanctioned" either — that is the same guess wearing a hedge.

1. A valid answer is a cited lookup. A real screening result names four things:

• the official list checked (e.g. OFAC SDN, EU Consolidated),
• the query — the exact name/identifiers screened,
• the result — hit / no hit / possible match, and
• the date the check was performed (a sanctions answer with no date is worthless; the list may have changed since).

1. If you cannot perform a live lookup, say so — do not fill the gap. If you have no real-time access to the official list (no tool, no connection, source down), state plainly: "I can't verify this against the live list." Then hand back the exact next step (which official source to check) and, in an operational setting, escalate to the compliance owner. Silence-filled-with-a-guess is the failure this skill exists to prevent.

1. Training knowledge ≠ a citable source. "As of my knowledge" is not a source a reviewer can check, and it is stale. If asked to answer "from what you know," decline and redirect to the live list.

1. A prior answer expires. A "no hit" from last week does not clear a party today. Lists are re-published continually and designations/de-listings happen between checks. Every question gets a fresh, dated lookup.

Where the Answer Actually Comes From

Point the user at the authoritative primary source — never a cached copy or a memory of one:

| Program | Official list | Publisher | |---|---|---| | US | SDN List + Consolidated Sanctions List / Sanctions List Search | OFAC (US Treasury) | | EU | EU Consolidated List of persons, groups and entities | European Commission / EEAS | | UN | UN Security Council Consolidated List | UN Security Council | | UK | UK Sanctions List | OFSI (HM Treasury) |

The point is the primary official source, queried now — not which vendor screening tool is used. A commercial screening service is fine as long as it reads the current official lists and the result is dated.

Name Matching Is Not a Yes/No

Even a real lookup rarely returns a clean boolean. Names transliterate many ways, aliases and spelling variants abound, and common names throw false positives. So:

• A name string alone is a weak query. Real screening uses secondary identifiers — date of birth, nationality, address, passport/registration number — to confirm or clear a possible match.
• Report a "possible match" as exactly that, requiring human adjudication — not a confirmed hit and not a clear.
• Never upgrade a fuzzy name match to a confident "yes, sanctioned," and never dismiss one to "no" without the identifiers to rule it out.

Output Shape

When you can cite a real, dated lookup:

List checked: OFAC SDN + Consolidated — Sanctions List Search
Query:        [exact name + identifiers screened]
Result:       No hit | Possible match (N candidates) | Confirmed match
Date checked: YYYY-MM-DD
Note:         [adjudication needed / identifiers used to clear]

When you cannot:

Status:  UNVERIFIED — no live lookup performed
Reason:  [no real-time access to the official list / source unavailable]
Do next: Screen "[name + identifiers]" against [official list] and record the date.
         Escalate to the compliance owner before clearing or blocking the party.

Do not, under any circumstance, replace the UNVERIFIED block with a remembered yes or no.