screening-alert-adjudication

name

screening-alert-adjudication

description

Adjudicates whether a hit generated by sanctions, PEP, or adverse-media screening is a true positive, false positive, or requires human escalation. Use whenever a user presents a screening alert, a name match against a watchlist (OFAC SDN, EU consolidated list, UK OFSI, UN list, PEP list, adverse media hit, etc.), or asks to clear a screening hit / reduce false positives / determine whether a flagged name is actually the listed party. Use even when the user describes the task casually — "is this person actually on the sanctions list", "did we get a real match", "clear this alert", "I have a hit on X" — these are all screening-adjudication tasks. Produces a deterministic determination with full audit trail (structured JSON + human-readable narrative). Designed for use by compliance analysts and screening systems.

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.

The adjudication procedure

Follow this sequence on every alert. Don't skip tiers and don't reorder them — the determinism guarantee depends on the order.

Step 1: Read the alert

Capture every field from the input. Note what's missing. In interactive mode, ask once for material gaps.

Step 2: Run Tier 0

Parse both names and the listed-entry context per references/tier-0-parsing.md. Produce the parse record. If parse confidence is low for either name, note it — this disables structural-mismatch FP rules in Tier 1 for that pair.

Step 3: Run Tier 1

Evaluate each Tier 1 rule (FP-1, FP-2, FP-3) per references/tier-1-rules.md. If any rule fires, produce the FP determination and stop. If none fires, proceed.

Step 4: Run Tier 2

Evaluate each Tier 2 rule (TP-1, TP-2, Escalate-2, FP-5, FP-6) per references/tier-2-rules.md. Log soft signals (gender, geography, partial-DOB mismatch where the hard rule didn't fire) but do not let them drive determinations. If a rule fires, produce the determination and stop. If none fires, evaluate whether Tier 3 has a realistic research path.

Step 5: Decide whether to enter Tier 3

Per the gating in references/tier-3-research.md, Tier 3 runs only if at least one of these is true:

• A unique-enough identifier exists on at least one side to anchor a web query
• A specific verifiable claim in the list entry can be confirmed or contradicted via primary sources
• A transliteration ambiguity from Tier 0 is the only obstacle

If none of these holds, escalate without Tier 3. Don't burn tokens on research that can't conclude.

Step 6: Run Tier 3 (if entered)

Work through the four-rung language ladder. Stop as soon as TP-3 or FP-7 fires, or when the 8-fetch retrieval cap is reached. Snapshot every retrieval that contributes to the determination.

Step 7: Produce the output record

JSON + narrative, per references/output-schema.md. Include every tier's evaluation, every rule that was checked and whether it fired, every retrieval if Tier 3 ran, and the final classification.

Common failure modes to watch for

• Treating absence of contradiction as confirmation. No matter how much circumstantial alignment exists, TP rules require affirmative evidence. Don't escalate to TP because nothing disproved it.
• Over-trusting low-confidence parses. If Tier 0 couldn't confidently parse a name's structure, the structural-mismatch FP rules don't apply to that pair. Skip them silently, don't force them.
• Letting soft signals drive determinations. Gender mismatch, geographic mismatch, partial-DOB mismatch — these are logged for the audit trail. They never independently produce TP or FP.
• Skipping the language ladder. When a name is Persian, Arabic, Chinese, Russian, or any other non-Latin-script origin, Latin-script-only search is almost always insufficient. Run Rung 1 in the source language.
• Burning the retrieval cap on noise. Cheap targeted queries first. If Rung 1 returns nothing of Rank A or B, move up the ladder rather than re-searching variants of the same poor query.

A note on what this skill does not do

• Sectoral ownership analysis (OFAC 50% rule and equivalents). Out of scope. If the listed party is being matched on an ownership-chain basis, the skill flags it for human review.
• Adverse-media conduct assessment. The skill confirms whether the screened party is the party in the media item. It does not assess whether the conduct described is relevant risk for the institution.
• PEP risk grading. Same logic — identity match yes, risk disposition no.
• Score tuning feedback to upstream screening. Adjudication records can feed score tuning later, but that's a separate analysis built on aggregated records.

Reference files

• references/tier-0-parsing.md — How to parse names and classify naming conventions
• references/tier-1-rules.md — Hard FP rules (FP-1, FP-2, FP-3)
• references/tier-2-rules.md — Structured corroboration rules (TP-1, TP-2, Escalate-2, FP-5, FP-6)
• references/tier-3-research.md — Web research procedure, language ladder, source ranking, TP-3, FP-7
• references/naming-conventions.md — Anchor and non-anchor components by naming convention
• references/transliteration-variants.md — Documented variant patterns for cross-script name handling
• references/place-name-equivalences.md — Cities and countries with multiple names (Leningrad/St. Petersburg, Bombay/Mumbai, Persia/Iran, etc.) for POB and address comparison
• references/output-schema.md — JSON schema and narrative format

Read the tier reference for the tier you're currently executing. Read the supporting references (naming conventions, transliteration variants) when Tier 0 or Tier 3 needs them. You don't need to read everything up front — the SKILL.md tells you which file to consult when.