Sanctions Screening Procedure Template

What is the Sanctions Screening Procedure?

Sanctions screening isn't optional. Under OFAC regulations, EU Regulation No 2580/2001, and comparable national frameworks, regulated institutions must screen customers, transactions, and counterparties against designated-party lists before processing activity. OFAC's sanctions compliance program guidance is explicit: a written, management-approved compliance procedure is one of five essential components of any adequate sanctions program. Institutions without documented procedures have faced nine-figure civil monetary penalties, regardless of whether their actual screening caught violations.

This template is a complete, written Sanctions Screening Procedure in Word format. It documents how your institution identifies which lists to screen against (OFAC SDN, Sectoral Sanctions Identifications, UN Security Council consolidated list, EU consolidated list, UK OFSI, and any jurisdiction-specific additions), at what frequency screening runs, and exactly what happens when a potential match appears.

FATF Recommendation 1's risk-based approach requires institutions to calibrate controls proportionate to their actual risk exposure. The screening procedure is where that calibration is recorded and justified. Without a documented procedure, examiners can't assess whether your program is deliberate or accidental.

The template also addresses recordkeeping obligations under FATF Recommendation 11: every screening hit, investigation, and disposition needs a traceable record. Good sanctions screening practice sits at the intersection of customer onboarding, transaction processing, and ongoing monitoring. This procedure covers all three.

Who needs the Sanctions Screening Procedure?

The MLRO or BSA officer owns this procedure. They're responsible for ensuring it's accurate, current, and formally approved by senior management. Compliance analysts use it daily as a reference when investigating potential matches. The model-risk team or internal audit function reviews it annually, or whenever the screening engine changes. External examiners from OFAC, FinCEN, the FCA, or national equivalents will request it on day one of any examination.

The trigger moments matter too. You reach for this template when building a new sanctions screening program from scratch, when an examiner's findings have identified procedure gaps, or when your institution onboards a new data provider and the existing documentation no longer reflects the actual lists or thresholds in use.

It's also the right tool for annual procedure reviews, which most internal audit frameworks require. If your institution is expanding into a new product line, such as crypto, trade finance, or correspondent banking, your existing procedure probably doesn't address the new risk surface. A structured template accelerates the rewrite significantly.

Smaller community banks and credit unions that can't justify a dedicated sanctions specialist need this too. A written procedure is what turns a reasonable screening effort into a documented, defensible program. Compliance consultants working across multiple clients use it as a baseline that gets adapted to each institution's specific obligations and risk profile.

What's inside the Sanctions Screening Procedure

The document is organized into nine sections:

1. Purpose and Scope The regulatory obligations the procedure is designed to fulfill (OFAC, EU, UN, OFSI, domestic additions), and the business lines, customer segments, and transaction types it covers. Examiners read this first.

2. Sanctions List Inventory A table of every list screened, the list provider or source URL, the update frequency (real-time, daily, or weekly), and the individual accountable for confirming updates are applied. Standard entries include: OFAC SDN, Sectoral Sanctions Identifications (SSI), UN Security Council consolidated list, EU consolidated list, UK OFSI consolidated list, and any jurisdiction-specific additions.

3. Screening Triggers When screening runs: new customer onboarding, periodic re-screening of existing customers, batch rescreening triggered by list updates, and ad hoc screening for specific transaction events. This section also addresses wire transfer screening obligations under FATF Recommendation 16, which requires originator and beneficiary data to accompany transfers and be screened at each processing point.

4. Alert Investigation Workflow The step-by-step process for handling a match, from initial alert triage through false-positive dismissal, escalation to compliance management, and referral to legal if a true match is confirmed. Each stage has a defined documentation requirement.

5. Escalation Matrix Named roles and decision authorities. Who clears a low-confidence fuzzy match, who approves a true-match determination, who notifies senior management, and who contacts regulators or law enforcement when required.

6. Recordkeeping Requirements Retention periods for screening records, match decisions, and supporting evidence, cross-referenced to FATF Recommendation 11 and applicable domestic rules. Five years from transaction date or account closure is the standard minimum in most jurisdictions.

7. Roles and Responsibilities A RACI-style summary: who runs screening, who reviews alerts, who owns the list inventory, who trains staff, and who signs off on annual procedure review.

8. Quality Assurance and Testing How the institution verifies screening is working correctly, including test-file injections with known sanctions entries, threshold-sensitivity reviews, and back-testing records.

9. Procedure Governance Version control, approval chain, review frequency, and the change-management process triggered when the screening engine or list inventory changes.

How to use the Sanctions Screening Procedure

Work through the document section by section in this order:

1. Confirm your regulatory scope. Before filling in any field, identify every sanctions regime your institution is subject to. A US bank with EU operations may carry OFAC, EU, and UK OFSI obligations simultaneously. List them all in Section 1. Don't assume the template's defaults apply to your situation.

2. Build your list inventory. Populate Section 2's table with every list your screening tool actually queries. If you're unsure, ask your vendor. The inventory must reflect reality. If a list isn't in your screening engine, don't claim it in the procedure.

3. Document your screening triggers. Section 3 is where institutions most often leave gaps. Screening at onboarding is standard. Screening on list updates (which happen multiple times a week for OFAC) is mandatory but frequently undocumented. Write the actual trigger, who runs it, and how it's logged. For customer due diligence workflows, this connects directly to your CDD refresh cycle.

4. Map escalation to real roles. Generic labels ("senior compliance officer") aren't enough if your institution is small. The escalation matrix in Section 5 should map to actual job titles. Update it when personnel change.

5. Get legal review and formal approval. This is a legal document once signed. Have counsel confirm the regulatory citations are current. Obtain written approval from your MLRO, CCO, or equivalent senior officer. Document the approval with a date and signature.

6. Distribute and train. Send the approved procedure to every team that runs screening or handles alerts. Document that training occurred. This is what continuous exam readiness looks like in practice: you can show the examiner the approval date, the distribution list, and the training records.

7. Set your next review date. Record it in Section 9. Most examiners expect annual review at minimum. If your screening vendor or any major list changes before that date, review immediately. Calendar it now, before this document is filed away.

Common mistakes to avoid

Screening only at onboarding. List updates happen continuously. OFAC adds and removes entries multiple times a week. An institution that screens only at account opening will miss a customer who becomes a designated party six months later. The procedure must document batch rescreening on every list update. That process must actually run.

Fuzzy-match thresholds with no documented rationale. Every screening engine uses name-matching algorithms with configurable sensitivity thresholds. A threshold set too high generates floods of false positives. Too low, and real matches are missed. Whatever threshold you've set, document why in Section 8. An examiner who finds a threshold with no written justification will treat it as an unexplained control gap.

Omitting beneficial owners and counterparties. Screening the account holder isn't enough. The procedure must explicitly address ultimate beneficial owners (UBOs), authorized signatories, transaction counterparties, and correspondent banks. PEP screening obligations under FATF Recommendation 12 run in parallel: a sanctioned individual is often also a politically exposed person.

No documentation trail for false-positive dismissals. Dismissing an alert without a written record is as problematic as missing a true match. Examiners want to see that a human reviewed the alert, applied a rational decision framework, and documented the outcome. The procedure must describe what that record looks like and where it's stored.

Procedure not updated after vendor or list changes. When an institution switches screening providers or adds a new sanctions list, the procedure is usually the last thing updated. Build a mandatory procedure review into any vendor-change or list-change process. An outdated procedure that describes a defunct system produces immediate findings in any examination.

How FluxForce automates this

The Sanctions Screening Procedure Template documents a process that FluxForce's AI agents run in real time. Nova Sentinel performs continuous sanctions and PEP screening against live list updates automatically, so your team doesn't manually trigger batch rescreens. Alert investigation workflows run with evidence attached to every decision. If a true match reaches escalation, it follows the path your documented procedure defines. Regulatory compliance automation means the procedure you write becomes the operational logic the system executes. Book a demo to see how it works.