CSSE · Certified Sanctions Screening Expert
How to Escalate and File a Sanctions Match Report
A practical, step-by-step guide from initial screening hit through L1 triage, L2 investigation and RFI, confirming identifiers, and filing the blocking or rejection report with the relevant authority within the required deadline.
Initial Hit: What the Screening System Actually Told You
A screening alert is a starting point, not a conclusion — it means the algorithm found a name or identifier sufficiently similar to a list entry to warrant review, at whatever match-confidence threshold the institution has configured. Before doing anything else, read exactly what fired: which field triggered the hit (ordering customer, beneficiary, free-text), which list and programme the entry belongs to, and the algorithm's own confidence/match type (exact, fuzzy, phonetic).
L1 Triage: Compare What You Actually Have
At L1, compare every identifier available on the transaction or customer record against the list entry — not just the name. Date of birth, nationality, passport/national ID, and address are all independent corroborating (or contradicting) data points. A name-only match with no other identifiers available is weaker evidence than it looks; a Blocking-list hit in particular should not be cleared at L1 on name similarity alone, regardless of how strong the corroboration looks, precisely because the consequence of wrongly clearing a true match is severe. Escalate anything that isn't a clean, well-corroborated false positive.
L2 Investigation: Close the Identifier Gaps
At L2, the job is to resolve whatever was still missing or unverified at L1. Send a Request for Information (RFI) to the ordering or originating institution asking specifically for the identifiers that would confirm or clear the match — date of birth, passport or national ID number, registered address — and document exactly what was asked and what came back. Three or more independent identifiers matching exactly is strong evidence of a true match; a pattern of deliberately altered or missing fields (see the Red Flags & Evasion Typology Reference) is itself evidence, not a reason to give the counterparty the benefit of the doubt.
Confirming Blocking vs. Sectoral Treatment
Once a true match is confirmed, determine which program applies before deciding what to do with the funds: a Blocking-list match (e.g. OFAC SDN, EU Consolidated, UN Security Council) generally requires freezing the party's property and interests and prohibiting virtually all dealings; a Sectoral-list match (e.g. OFAC SSI) restricts only the specified categories of dealing, so other, non-restricted dealings with that same party may remain permitted. Getting this distinction wrong either over-blocks (freezing funds with no legal basis) or under-blocks (failing an actual obligation) — confirm the specific programme and its scope, don't assume.
Blocking or Rejecting the Payment
For a confirmed Blocking-list match, the funds are typically blocked (frozen and segregated, not returned) or the payment rejected and returned, depending on the applicable sanctions authority's own rules for that scenario — this is not a judgment call to improvise; it follows the specific program's own treatment rules, which your compliance function should already have documented for each list your institution screens against.
Filing the Report Within the Deadline
File the required report with the relevant authority (e.g. OFAC, an EU member state's competent authority, HM Treasury's OFSI) within the mandated deadline — commonly a fixed number of business days from the blocking or rejection, though the exact window depends on the specific authority and program. Missing the filing deadline is itself a compliance failure independent of having correctly identified and blocked the match in the first place, so the deadline should be calendared the moment a match is confirmed, not left to be calculated later.
Documenting the Full Chain
A defensible sanctions file shows the full chain: the original alert, the L1 triage rationale, the L2 RFI (question asked and response received) and any enhanced due diligence findings, the blocking/sectoral determination, the treatment applied, and confirmation of the filing itself (date, authority, reference). A regulator or auditor reviewing the file after the fact should be able to follow the same reasoning path an investigator followed in real time, not just see a final "blocked and reported" conclusion with no supporting trail.
Frequently Asked Questions
- What if the identifiers are ambiguous — some match, some don't?
- Escalate rather than clear. A partial or mixed identifier picture on a Blocking-list hit should go to (or stay at) L2 for further RFI/EDD work rather than being cleared at L1 on the strength of the matching identifiers alone — the cost of wrongly clearing a true match is far higher than the cost of investigating a genuine false positive a little further.
- Who actually files the report — the analyst or a separate function?
- This varies by institution, but the escalation guide above describes the investigative path to a filing decision, not necessarily who presses "submit" — many institutions route the actual filing through a dedicated sanctions or MLRO function once L2/L3 has confirmed the match and the treatment. The deadline clock runs from the blocking/rejection event regardless of which internal team executes the filing.
- Does a Sectoral-list match need to be reported the same way as a Blocking-list match?
- The reporting obligation and its trigger depend on the specific program and the specific dealing restricted — a Sectoral match still needs to be correctly identified and, where the program requires it, reported, but the treatment (which dealings are actually prohibited) is narrower than a full Blocking-list freeze. Confirm the specific program's own rules rather than assuming Blocking-list treatment applies automatically.
This reference is part of Riskpro's Certified Sanctions Screening Expert (CSSE) programme.
See the CSSE course →