Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

OFAC SDN list screening

sdn-list-screeningDomain: trade-sanctionsType: mixed

Description

A working OFAC SDN screening program matches every customer, beneficial owner, and counterparty against the Specially Designated Nationals and Blocked Persons list at onboarding, on transaction, and on each list update, and blocks transactions and freezes property when a confirmed match is found. The list itself identifies individuals, entities, vessels, and aircraft whose property is blocked and with whom US persons are generally prohibited from transacting; the 50% Rule extends the prohibition to entities owned 50% or more in aggregate by SDNs, which means beneficial-ownership data is part of the screening input, not an optional augmentation. OFAC publishes updates multiple times per week, and the operational discipline assumes daily list refresh as a baseline. The operational difficulty is in the matching itself. Names on the list often appear in transliterated form, with aliases, partial dates of birth, and sometimes only a country and a role. The screening engine has to handle fuzzy matches against transliterated and partially-specified records without producing a review queue so large the team cannot work it. The standard posture runs graduated fuzzy-match thresholds tied to the data quality of the input, a documented false-positive review process with reviewer notes attached to each disposition, and a blocking procedure that freezes funds and files the OFAC blocking report within the statutory window when a confirmed match is found. The OFAC license file (where a transaction otherwise prohibited is conducted under a specific or general license) sits alongside the screening log as the second half of the audit trail. The failure modes are symmetric. Underscreening exposes the operator to OFAC civil penalties, criminal liability in egregious cases, and a public enforcement announcement that compounds the reputational cost. Overscreening is itself a customer-experience problem that has drawn enforcement attention in fair-banking contexts: a screening configuration that systematically blocks customers from particular national-origin or naming-convention cohorts has been treated as a discrimination signal, regardless of whether any specific block was a true positive. Evidence formats that hold up include the per-customer SDN screening log with disposition notes, the blocked-property reports filed with OFAC, and the OFAC license file showing the authorization basis for any otherwise-prohibited transaction. The country-sanctions rollup screening (DFAT, Canadian Autonomous Sanctions, METI, MAS TFS, SECO) runs in parallel for operators with cross-border exposure, typically through the same aggregator service.

Applicability

Applies when: markets include US.

How predicates are evaluated

Required by (2 regulations)

  • US OFAC

    31 CFR Part 501 — SDN List + Sectoral Sanctions Identifications + Foreign Sanctions Evaders + Non-SDN Iranian Sanctions; updated multiple times per week; the 50% Rule extends sanctions to entities owned 50%+ in aggregate by SDNs.

    31 CFR Part 501

    Source →

  • Other Sanctions

    Consolidated multilateral screening — the SDN-equivalent on each national framework (DFAT Consolidated List, Canadian Autonomous Sanctions List, METI Notices, MAS TFS lists, SECO Sanctions Search) consumed via aggregator services.

    Consolidated multilateral screening

    Source →

Fulfilled by (3)

  • comply-advantage · full · medium effort · $$
  • ofac-search · full · low effort · $
  • In-house build · high effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • OFAC SDN screening logs
  • blocked-property reports
  • OFAC license file

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn