sanctions-screening-qa

name	sanctions-screening-qa
description	Quality-reviews a sanctions screening program against named regulatory frames: list-management governance, customer and transaction screening configuration, match-logic and fuzzy-threshold tuning, list-update timeliness, alert disposition documentation, false-positive rationale, escalation paths, 50 Percent Rule and sectoral-sanctions handling, and cyber-evasion exposure. Reads each sampled alert disposition for documented rationale, decision-maker independence, and 50%-rule assessment; produces a second-line QA memo with material findings, evidence-needed items, and recommended decision checkpoints with named owners. Does not approve list configuration, tune match logic, file blocking or rejection reports, close alerts, or make match-or-no-match decisions. Best for: - Periodic sample QA over customer-screening and transaction-screening alert dispositions within a defined review window. - Pre-validation review of screening configuration evidence to scope the next validation cycle. - Pre-exam readiness review of sanctions program documentation against the OFAC Framework five components and the FFIEC OFAC section. - Targeted review after a list-update event (new SDN designations, new sectoral programs, FSE designation changes, virtual-currency-adjacent designations). - Targeted review of sanctions-evasion exposure via cyber and tech (virtual currency, ransomware, mixers, identity manipulation). Not the right tool when: - The work is a sanctions program risk assessment as a whole (this skill reviews QA evidence; the program risk assessment is a different artifact). - The work is AML transaction-monitoring review (use `aml-model-monitoring`; sanctions is real-time list-match, not behavioral). - The work is screening-engine model validation, threshold calibration, or BTL testing (use `aml-model-monitoring`; this skill cross-references but does not redo). - The work is customer beneficial-ownership documentation (use `cdd-risk-review`; the screening QA cross-references for 50 Percent Rule aggregation reads). - The decision being asked for is whether to release, block, reject, or report a transaction or relationship. The skill produces QA artifacts; the sanctions officer (and the firm's escalation chain) decides.
argument-hint	[program scope: list set, screening rails, review window, sample basis; or pointer to sanctions program scope]

Sanctions screening QA

A sanctions screening QA memo is what second-line produces so the sanctions officer, the BSA officer, the head of financial-crime QA, and the audit / examiner audience can see whether the institution's sanctions program holds up against the OFAC Framework five components and the FFIEC OFAC section. The work is reading the program evidence component by component, walking a sample of alert dispositions alert by alert, naming gaps in list management, screening configuration, disposition documentation, 50 Percent Rule handling, sectoral handling, list-event response, and cyber-evasion exposure, and recommending where the program goes next: tighten a control, add a decision checkpoint, refer a tuning question to model monitoring, escalate to the sanctions officer. The skill stops at the recommendation.

The reviewer does not approve list configuration, tune match logic, file blocking or rejection reports, close alerts, or make match-or-no-match decisions on any specific alert. OFAC determinations are regulated acts reserved to the sanctions officer and the firm's escalation chain. The skill produces QA findings that route to the named decisionmaker.

This skill produces a Word memo (rendered via the docx skill in the document-skills plugin) plus a structured record (schemas/sanctions-alert.schema.json). Where the alert sample is large enough to warrant a separate workbook, the alert-by-alert disposition table renders to an Excel workbook (rendered via the xlsx skill) and the memo carries the surrounding analysis.

Ask first

Before drafting, get plain answers to a few things. Most reviews answer them quickly; if not, default and flag.

• What is the institution and which OFAC programs scope the review. A bank's correspondent and trade-finance activity reads against different programs than a fintech's stablecoin on-ramp. A broker-dealer's restricted-securities-list compliance reads as a transaction-level prohibition on the security, not a customer-screen. A covered-product life insurer's beneficiary-at-claim screening lifecycle reads differently from the bank's customer-rescreen cycle. Load the matching references/sector-overlays/<sector>.md from the scope.
• What kind of QA review is this. Periodic sample QA over a window, pre-validation scoping, exam readiness, list-event response review, or cyber-evasion targeted review. The review type drives sample selection, depth, and which sections of the artifact carry weight. A list-event review is shallow on the alert sample and deep on response timing and cross-rail consistency; a periodic sample QA is the reverse.
• Who reads the memo. A sanctions officer reads for material defensibility issues and program-level patterns. A QA team reads for criterion-by-criterion calibration. A BSA officer reads for governance signal and committee escalation. An examiner-response file reads formal and full source-traced. Audience drives tone and depth.
• What is in the program evidence the QA reads. The list-management runbook and audit log against OFAC publication dates; the screening-engine configuration export; the fuzzy-threshold calibration memo; the alert-disposition workpapers (sample); the 50 Percent Rule methodology document; the sectoral-handling logic documentation; the list-update event response artifacts; the cyber-overlay assessment artifact (when the scope flags cyber); the sanctions-officer sign-off log. If parts of the file are missing, that is itself a finding. Draft against what is there and flag the missing parts in material_gaps; do not block.

When the scope record is supplied, the skill consumes it for institution type, primary regulator, sector overlay, cross-cutting overlays (cyber loads when flagged), persona, and source posture. Otherwise it asks the practitioner the few facts it needs, and source posture sets what the memo can assert at high confidence and what carries [evidence needed].

How the QA memo gets built

The memo has the same spine across review types. A senior QA reviewer fills it in roughly in the order the program evidence presents itself, not in a lockstep sequence. Two parts of the order are load-bearing and explicitly sequenced:

1. Confirm the operative OFAC programs and the sector overlay before reading the evidence. A bank-flavoured read on a covered-product life insurer's beneficiary-at-claim file is wrong; a fintech-rail read on a regional bank's trade-finance file is wrong; a customer-screen read on a restricted-securities-list obligation is wrong. Load the sector overlay first; do not retrofit the frame to the evidence.
2. Set the OFAC publication date as the benchmark before reading list-update timeliness. The OFAC publication date is the operative anchor for response-timing measurement. Reading timeliness against the institution's internal publication date measures the wrong thing and produces a "0-hour lag" finding that has no evidentiary value.

Beyond those two anchors the work is judgement-led. The senior QA reviewer walks the program in this shape, alert by alert where the artifact is alert-by-alert.

The sanctions risk posture summary captures the list set in use (OFAC SDN, OFAC SSI, OFAC FSE, OFAC NS-PLC, other OFAC programs; non-OFAC: UN, EU, UK OFSI, jurisdictional), the jurisdictions and corridors in scope, the product / customer / counterparty population that drives the program's risk concentration, and the recent OFAC enforcement themes the program reads against (pattern reference; no name-drop unless the institution is a public defendant in a finalized consent order). List citations carry a date-as-of every time they appear; OFAC lists move and an undated citation cannot be relied on.

The list management governance read captures the list sources, the documented update cadence, the last verified update date, the delta-vs-full reconciliation evidence, the feed-mapping completeness, and the lag against OFAC publication. Feed-mapping completeness is read as a discrete control, not inferred from response time; a system that does not ingest a designation type (e.g., the SDN List's Digital Currency Address identifier records) is silent on that designation type, not slow. Delta-vs-full reconciliation is a separate read from delta cadence; a program can be fast on deltas and still drop designations between full re-scan cycles.

The screening configuration read captures customer screening (onboarding, rescreen cycle, event-driven rescreen), transaction screening rails (wire, ACH, card, faster-payments, trade-finance message, securities settlement, beneficiary-at-claim, other), match-logic summary (algorithm class, vendor identity), fuzzy-threshold setting and basis (BTL testing, vendor recommendation, calibration analysis), and exclusion-list governance. An undocumented exclusion list (no owner, no refresh cadence, no re-review evidence) is a material exclusion_list_governance finding. A fuzzy threshold inherited from the vendor without institution-specific calibration is a fuzzy_threshold_calibration finding. Vendor model risk on the screening engine sits in aml-model-monitoring; the QA cross-references and does not redo.

The alert disposition QA is the alert-by-alert work and the heart of a periodic sample QA. Each sampled alert carries an alert ID, alert date, rail, list source, vendor match score and threshold crossed, disposition (false_positive_closed, true_match_blocked, true_match_rejected, true_match_reported, escalated_pending, released_with_rationale), FP-rationale category from the documented taxonomy (name-only-match, dob-mismatch, geography-mismatch, identifier-mismatch, role-mismatch, common-name, prior-cleared-counterparty, generic-or-boilerplate, other), decision-maker role (independence from the relationship owner is a structural control), evidence pointer, and 50-percent-rule-assessed status (yes / no / not_applicable / unknown). Generic-or-boilerplate FP rationale ("reviewed, not a match"; "false positive") is itself a fp_rationale_documentation finding; without a rationale taxonomy, tuning evidence is impossible. The QA reads each alert's documentation; it does not re-decide match-or-no-match. Where the alert sample is large, this section renders to an Excel workbook via the xlsx skill while the surrounding memo renders to Word.

The 50 Percent Rule and sectoral sanctions handling read captures whether the program has a documented aggregation methodology at program level (signed by the sanctions officer), how it handles multi-owner aggregation, chain ownership, indirect ownership, and beneficial-ownership conflicts, what evidence basis the program uses for ownership reads (corporate registry, BO certification, commercial database, vendor analytics; database-only reads on offshore structures are a known gap), and how edge cases route (sanctions counsel, OFAC FAQ reference, OFAC licensing route). Sectoral-program handling is read distinct from SDN; a program that collapses SSI hits into SDN-style blocking has missed the directive-specific limb (debt / equity tenor restrictions, prohibited service categories, restricted-securities handling).

The list-update event reviews capture the material list-update events in the window (new SDN designations, new sectoral programs, FSE designation changes, jurisdiction-program shifts, virtual-currency-adjacent designations), the institution's response evidence (full re-scan, delta processing, customer-base sweep, payment-rail re-scan), the response timing measured against OFAC publication date, and the cross-rail consistency check evidence. Where the designation set includes virtual-currency-adjacent records, a designation-type cyber-overlay assessment is a standing list-event step, not optional.

The cyber-evasion exposure read loads the cross-cutting cyber overlay (references/cross-cutting/cyber.md) when the scope flags cyber. The overlay is sanctions-evasion-specific, not generic cyber controls (NYDFS Part 500 program-level and SEC cyber 8-K disclosure sit elsewhere in the repo and are not duplicated here). The typologies the overlay reads for are anchored in OFAC and FinCEN public material: ransomware payments to OFAC-listed groups; virtual-currency obfuscation through mixers, peel chains, and chain-hopping; cyber-enabled identity manipulation defeating name-and-DOB matching; deepfake / synthetic-identity at onboarding screening; BIN sponsorship and prepaid-card abuse; decentralized finance and bridge exposure. Address-level screening capability (the SDN List carries Digital Currency Address identifier records) is read discretely from name-level screening.

The material findings are tagged to a named criterion (list_update_timeliness, feed_mapping_completeness, delta_vs_full_reconciliation, match_logic_documentation, fuzzy_threshold_calibration, exclusion_list_governance, fp_rationale_documentation, fp_rationale_taxonomy, decision_maker_independence, escalation_path_evidence, fifty_percent_rule_methodology, fifty_percent_rule_evidence_basis, ssi_distinct_handling, directive_specific_logic, list_event_response_timing, cross_rail_consistency, cyber_evasion_exposure_assessment, virtual_currency_controls, ransomware_advisory_alignment, cyber_identity_controls, vendor_model_risk_coverage, training_evidence, sanctions_officer_signoff, other), mapped to the OFAC Framework component or FFIEC OFAC section the criterion bears on (management commitment, risk assessment, internal controls, testing and auditing, training, ffiec_ofac_section, other), assigned a severity (material, moderate, minor, observation), and pointed at evidence in the file. The criterion is named, not implied.

The material gaps list each gap with the criterion it bears on and a clear "what was not in the file" statement. Each gap stays [evidence needed] until resolved by the relationship owner, the sanctions function, or the BSA program.

The recommended decision checkpoints and recommendation name the recommendation (no_further_action, evidence_request_to_first_line, tuning_review_via_aml_model_monitoring, list_management_remediation, fifty_percent_rule_methodology_remediation, training_feedback, process_change_recommendation, escalate_to_sanctions_officer, other) and the checkpoints to add or tighten. Each recommended checkpoint carries a name, the criterion it serves, the named owner (sanctions officer, BSA officer, sanctions counsel, model-risk reviewer), and the condition that holds it open (what state must change before sign-off). A recommendation that proposes a specific match-or-no-match decision, a release, a block, a rejection, or a filing of a blocking or rejection report is not within scope; the QA frames the issue as a routing recommendation to the named decisionmaker.

The source trace and confidence records every material claim in the memo, its source (program evidence, sector overlay, source-anchors file, firm overlay where present), the date-as-of for OFAC list citations, and a confidence label. Vendor analytics outputs (blockchain-analytics, fuzzy-match scoring, fraud-decision) are vendor outputs and carry lower confidence than primary system-of-record extracts; do not collapse them. Vendor-diligence on these vendors sits in third-party-operational-resilience/vendor-diligence; the QA cross-references.

Depth flexes with review type and audience. A periodic sample QA reads tighter with patterns rolled up across alerts; a pre-exam readiness pass reads long and formal; a list-event review goes deep on response timing and cross-rail consistency; a cyber-evasion targeted review goes deep on the cross-cutting overlay and address-level screening capability.

Sector and cross-cutting overlays

The sector overlay set is loaded from the scope or the institution type and drives the rail population, the screening-responsibility allocation read (especially in payments-fintech sponsor-bank arrangements), the restricted-securities-list handling read (capital markets), and the beneficiary-at-claim lifecycle read (insurance). Banking carries wire / ACH / trade-finance / correspondent-banking nested-relationship reads. Payments-fintech carries the sponsor-bank vs MSB allocation, the per-rail real-time / faster-payments operating-window reads, and the crypto on-ramp / off-ramp screening exposure. Capital markets carries restricted-securities transaction-level prohibitions and settlement-chain screening. Insurance carries beneficiary-at-claim, producer, reinsurance counterparty, and the covered-vs-non-covered scoping (the OFAC obligation extends beyond the BSA covered-product scope). Load only the overlays the engagement implicates; gold-plating across sectors adds noise.

The cross-cutting cyber overlay loads when the scope flags cyber, when the program touches virtual-currency activity, when the institution has incident-response payment paths, or when the list-event review includes virtual-currency-adjacent designations. The overlay is sanctions-evasion-specific. Conduct, climate, and privacy cross-cutting overlays are not in scope for this skill.

Pointers

• references/source-anchors.md — citations and excerpts for the named anchors (OFAC Framework May 2, 2019; OFAC 50 Percent Rule guidance August 13, 2014; OFAC SDN, SSI, FSE and other lists; OFAC General Licenses and FAQs; 31 CFR Chapter V; FFIEC OFAC section; joint interagency Revised Guidance on Model Risk Management at OCC Bulletin 2026-13 / FRB SR 26-2 / FDIC FIL-15-2026 (April 17, 2026), which superseded SR 11-7 and SR 21-8 for screening-engine model-risk treatment; OCC/FRB/FDIC joint statements).
• references/sector-overlays/banking.md, payments-fintech.md, capital-markets.md, insurance.md — sector-specific reads loaded per scope.
• references/cross-cutting/cyber.md — sanctions-evasion-via-tech overlay loaded when cyber is flagged or when the program touches virtual currency, ransomware-payment paths, or cyber-enabled identity exposure.
• references/firm-overlay.md — firm policy, sanctions-officer escalation chain, exclusion-list register, vendor inventory, named systems and owners (consumed when present).
• templates/default-output.md — memo template with the alert-by-alert disposition table.
• schemas/sanctions-alert.schema.json — structured-output contract; cross-skill-consumable record for case-management or QA roll-up.
• examples/payments-fintech-enforcement-pattern.md, list-event-review-regional-bank.md — public-source-derived scenarios.
• TROUBLESHOOTING.md — recurring defects in sanctions program evidence and in QA memos written against them.

The plugin-level shared references (references/source-map.md, references/policy-control-library.md, references/review-gates.md) sit at the plugin root and are consulted alongside the skill-level files.

Output

The deliverable is a Word memo per templates/default-output.md, rendered via the docx skill. Where the alert-disposition sample is large enough to warrant a separate workbook (typically a periodic sample QA covering more than a handful of alerts), the alert-by-alert table renders to an Excel workbook via the xlsx skill, and the memo references it. The structured record per schemas/sanctions-alert.schema.json emits alongside.

The sanctions officer (with the BSA officer in the chain, and sanctions counsel where the program structure routes through counsel) reviews the memo and decides on the recommendations. The memo is the input, not the decision.

Downstream consumers: a sample-level QA roll-up reads the structured record across program reviews for pattern detection, recurring-finding rates, and training-feedback themes. The board / audit-committee BSA-and-sanctions reporting cycle pulls aggregated findings as a governance signal. aml-model-monitoring consumes any finding tagged to match-logic, threshold calibration, or BTL testing (which is its scope, not this skill's). cdd-risk-review consumes any finding tagged to beneficial-ownership evidence underpinning a 50 Percent Rule aggregation read. sar-decision-qa reads the screening-disposition record as context when a sanctions-adjacent alert escalates to a SAR. The schema is the cross-skill contract; additive changes only, never silent renames. Breaking changes ship as a versioned migration with consumers told in advance.