Screening Alert Adjudication Amir Fadavi

Screening Alert Adjudication

This skill adjudicates a single screening hit — a name that an upstream screening system flagged as a possible match against a sanctions list, PEP list, adverse-media source, or similar watchlist — and reaches one of three conclusions:

• True positive (TP) — the screened party is the listed party
• False positive (FP) — the screened party is not the listed party
• Escalate — evidence is insufficient to deterministically conclude either way; hand off to a human analyst with the full evidence record

Why this skill exists

Screening systems generate enormous volumes of low-quality alerts. Analysts spend their time clearing alerts that should never have fired (wrong entity type, common name with no overlap on identifiers, partial-name matches that ignore naming convention). A deterministic, criteria-driven adjudication layer can clear the obvious false positives and confirm the obvious true positives, leaving humans to focus on the genuinely ambiguous cases.

The skill is designed around two non-negotiable properties:

1. Determinism. Given identical evidence, the skill reaches an identical conclusion. The skill never weighs probabilities, never says "this looks like" or "probably is." A rule either fires or it doesn't.
2. Conservatism. Escalation is the safe default. No rule fires unless every one of its preconditions is satisfied. Better to escalate a clear case than to wrongly clear an ambiguous one.

How the work is organized

Adjudication runs through tiers. Each tier escalates token spend; earlier tiers exit as soon as they can.

• Tier 0 — Parse and normalize both names; classify scripts, languages, naming conventions; extract anchor components, aliases, and identifiers. No determinations yet. See references/tier-0-parsing.md.
• Tier 1 — Hard false-positive triggers using only what's in the alert. Cheap, no web access. Only FP rules fire here; TP is never reached at Tier 1. See references/tier-1-rules.md.
• Tier 2 — Structured identifier corroboration using whatever's in the alert and list entry. Both TP and FP rules available. Still no web access. See references/tier-2-rules.md.
• Tier 3 — Targeted external research using web search and fetching. Source-language aware, source-ranked, capped at 8 page retrievals per case. See references/tier-3-research.md.

If no determination is reached by the end of an applicable tier, the skill escalates with the full evidence record.

What the skill needs to start

Required from the user or upstream system:

• The screened name (the name being checked — usually a customer, transaction party, beneficial owner, or similar)
• The matched name from the list entry

Useful if provided, optional otherwise:

• The name of the list (e.g., "OFAC SDN List", "EU Consolidated Financial Sanctions List", "UK OFSI Consolidated List", "Dow Jones PEP"). The skill doesn't branch on list name operationally — the matching question is the same across all lists — but the list name is captured in the audit record and informs the analyst's downstream disposition.
• Entity type on the screened side (individual / entity / vessel)
• Any secondary identifiers (DOB, POB, nationality, ID numbers, addresses)
• The upstream system's match score
• The list version or snapshot date (for audit binding)
• The mode (interactive vs. batch)

Default to interactive mode when a human is at the keyboard. In interactive mode, ask once for any of the following that aren't present and would materially help:

• Entity type on the screened side, if not inferable
• Any secondary identifiers the analyst has access to but didn't supply

In batch mode (system feed, no human present), proceed with whatever is provided. Don't ask. If essential context is missing and the rules can't conclude, the skill escalates — that's the correct outcome.

Inferring entity type when not provided

Read the list entry first. Most watchlist entries carry an explicit type field (individual / entity / vessel / aircraft). Use that.

For the screened side: ask in interactive mode. In batch mode, attempt inference from the name structure but flag the inference as low-confidence. The type-mismatch FP rule (FP-1) requires high-confidence types on both sides — it never fires on inferred screened types.

The core question the skill answers

Across every list type and every rule, the underlying question is the same: is the screened name the same party as the listed party? List type affects the consequences of the answer, not the question itself. The same matching engine applies whether the list is a sanctions list, a PEP list, or an adverse-media source.

That said, list type affects the threshold for action:

• For strict-liability lists (OFAC SDN, EU sanctions, UN sanctions): TP requires affirmative evidence, not just absence of contradiction. Default toward escalation when ambiguous.
• For adverse media: source recency and quality enter the assessment. A 12-year-old tabloid mention is not equivalent to a current Reuters report on a recent conviction. But the identity-matching question is unchanged.
• For PEP lists: the skill's job ends at identity match. Whether to maintain the relationship is a risk decision for the institution, not for this skill.

Working with names across scripts and naming conventions

A screening hit often involves names from different cultures, scripts, and naming conventions. Standard fuzzy matchers handle this badly — they treat "Jose Andrea" as matching "Jose Andrea Coronado" by string overlap and ignore that Coronado is the anchor surname in Hispanic convention.

The skill parses both names into structural components first. Anchor components (the parts that genuinely identify the person) drive matching; non-anchor components are corroborating context. The naming-convention reference (references/naming-conventions.md) defines anchor and non-anchor components per convention: Hispanic, Portuguese, Arabic, Russian, East Asian, Indonesian/Burmese, Western default.

When the script is non-Latin or the name is a transliteration from a non-Latin source, the skill is aware that the same source-language name can produce multiple Latin spellings. See references/transliteration-variants.md for documented variant patterns. When Tier 3 web research runs, source-language queries are part of the search ladder.

Output requirements

Every adjudication produces a single record in two views, generated together from the same underlying state:

1. Structured JSON — machine-readable, used for system ingestion, QC sampling, cross-case querying
2. Human-readable narrative — fixed-section, walks through each tier's reasoning in the form "Determined X based on Y, then Z"

The full schema and narrative format are in references/output-schema.md. Both must be produced on every adjudication, regardless of outcome.

The narrative never characterizes its own confidence beyond what the rules produced. There is no "this appears to be" or "likely false positive" language. A rule either fired or it didn't.

For escalations, the record includes a gaps_for_human field listing the specific information that would have allowed determination. The skill does not make a recommendation toward TP or FP on escalations — the evidence package is presented neutrally so the human draws their own conclusion.