How Sanctions List Works
A sanctions list operates as a continuously maintained legal instrument: authorities designate a party, publish the entry, and financial businesses are immediately obligated to prevent that party from accessing the financial system. The process involves several coordinated steps across government bodies, data vendors, and compliance systems inside every payment business. Understanding the full lifecycle helps merchants and developers build screening workflows that are both legally compliant and operationally practical.
Sanctions screening is the operational process that consumes sanctions list data — the list is the database, screening is the act of querying it.
List Compilation and Designation
A sanctioning authority — such as a national treasury, a UN committee, or a regional body — investigates a party and issues a formal designation order. The order specifies the legal name, aliases, date of birth, nationality, identification numbers, and the sanction program under which the party is designated. This compiled record becomes a new entry on the list.
Publication and Distribution
The authority publishes the updated list file, typically as a structured XML, CSV, or JSON feed available via official portals. Data providers and compliance vendors download these files — sometimes within minutes of publication — and normalize the data across multiple list sources into a unified screening database that businesses can query.
System Integration
Payment platforms, acquirers, PSPs, and merchants integrate sanctions list data via API calls to a third-party screening vendor or by ingesting raw list files directly. The integration must be capable of consuming list updates in near-real time and triggering re-screening of existing customer records when new designations appear.
Customer and Transaction Screening
At account creation, transaction initiation, and periodically in batch, the system compares customer names, entity names, and associated attributes against the consolidated list database. Screening engines apply fuzzy matching algorithms to account for spelling variations, transliterations, and alternative name orderings that are common across different jurisdictions and scripts.
Match Adjudication
When the screening engine surfaces a potential match, it generates an alert that pauses the transaction or flags the account for review. A compliance analyst — or an AI-assisted triage tool — evaluates corroborating attributes: date of birth, nationality, address, and identification numbers. The analyst documents the finding and either confirms a true match or clears the alert as a false positive.
Blocking, Reporting, and Recordkeeping
Confirmed true matches trigger immediate blocking of the transaction or freezing of the account. Depending on jurisdiction, businesses must file a report with the relevant authority — OFAC requires a blocked transaction report within 10 business days and an annual accounting of all blocked property. All adjudication decisions, supporting evidence, and disposition actions must be retained for a minimum of five years.
Why Sanctions List Matters
The financial stakes attached to sanctions non-compliance are among the highest in the entire payments compliance landscape. Regulators treat sanctions differently from most other compliance obligations — they carry strict liability, meaning a business that unknowingly processes a payment to a sanctioned entity is still fully exposed to penalty. This makes proactive list screening not just a compliance checkbox but a core risk management priority for any payment business.
The scale of enforcement underscores the point. OFAC collected over $1.3 billion in civil monetary penalties in 2022 alone, a figure driven by a small number of large settlements but reflecting dozens of enforcement actions across payment companies, banks, and crypto exchanges. The SDN list contained more than 12,500 entries as of early 2024, spanning individuals, vessels, aircraft, entities, and digital currency addresses — a scope far beyond what any manual review process can track reliably.
Beyond OFAC, the global regulatory environment is intensifying. The EU sanctions regime expanded significantly following geopolitical events in 2022–2024, and the number of active global sanctions programs has more than tripled over the past two decades, according to research from the Atlantic Council. For any payment business operating cross-border, exposure to multiple overlapping list regimes is the baseline reality.
Sanctions violations also generate cascading secondary risks. A public enforcement action can trigger correspondent bank de-risking, card network audits, and investor scrutiny that materially impairs a business's ability to operate — outcomes that dwarf the monetary penalty itself.
Anti-money laundering programs and sanctions programs are distinct legal frameworks, but they share infrastructure: both rely on customer identity data, transaction monitoring, and alert-based workflows to catch illicit activity.
Strict Liability Standard
Unlike most regulatory frameworks, OFAC does not require proof of intent to impose civil penalties. A business that processed a transaction with a sanctioned party — even unknowingly — can be held fully liable. Voluntary self-disclosure and a strong compliance program are the primary mitigating factors regulators consider when determining penalty amounts.
Sanctions List vs. PEP List
Sanctions lists and Politically Exposed Person (PEP) lists are both essential compliance databases, but they serve different legal purposes, carry different obligations, and require different operational responses. Conflating the two is a common compliance error that leads to either over-blocking legitimate customers or under-screening genuinely high-risk parties.
A politically exposed person is someone who holds or has held a prominent public function — a senator, a senior government official, a central bank governor. Being a PEP is not illegal. PEP screening triggers enhanced due diligence, not automatic blocking.
| Dimension | Sanctions List | PEP List |
|---|---|---|
| Legal basis | Statutory designation by government authority | Risk-based AML guidance (FATF, local regulators) |
| Obligation on match | Block transaction / freeze assets (mandatory) | Enhanced due diligence (risk-based) |
| Strict liability | Yes — intent irrelevant for civil penalties | No — proportionality applies |
| Who is listed | Designated individuals, entities, vessels, countries | Current and former public officials, family, associates |
| List authority | OFAC, UN, EU, HM Treasury, others | Commercial vendors compile from public sources |
| Update frequency | Near-real-time (multiple times daily) | Periodic (weekly to monthly typical) |
| False positive risk | High — common names, transliteration issues | Very high — millions of PEPs globally |
| Penalty for non-compliance | Civil and criminal fines, imprisonment | Regulatory censure, AML fines |
Both databases must be queried at onboarding and monitored on an ongoing basis, but the downstream actions and legal exposures are meaningfully different.
Types of Sanctions List
Multiple distinct sanctions lists coexist across jurisdictions, and a globally active payment business must screen against all lists relevant to its operational footprint. Using a single list is insufficient and creates regulatory exposure in every jurisdiction where additional lists apply.
OFAC Specially Designated Nationals (SDN) List — The most widely referenced list globally. Any US person or entity using US financial infrastructure (which includes virtually all card-based payments) must comply. The SDN list contains individuals, companies, vessels, and aircraft across dozens of sanction programs including counter-terrorism, counter-narcotics, and country-specific programs.
OFAC Non-SDN Lists — OFAC also maintains sector-specific lists including the Sectoral Sanctions Identifications (SSI) list, the Foreign Sanctions Evaders (FSE) list, and the Non-SDN Palestinian Legislative Council list. These impose narrower restrictions than a full asset block but still require screening.
UN Security Council Consolidated List — Maintained by the UN's 1267/1989/2253 ISIL and Al-Qaida Sanctions Committee and other subsidiary bodies. All UN member states are required to implement these designations under international law.
EU Consolidated Financial Sanctions List — Published by the European Commission, this list incorporates UN designations plus EU-autonomous designations. EU-incorporated entities and any business transacting in euros must comply.
HM Treasury (UK) Financial Sanctions Targets — Maintained by the Office of Financial Sanctions Implementation (OFSI) post-Brexit. The UK retains UN designations and has issued autonomous designations diverging from the EU list in some programs.
Domestic Lists — Many countries maintain their own sanctions lists. Canada (OSFI), Australia (DFAT), Japan (METI/MoFA), and Switzerland (SECO) each publish lists that apply to businesses operating in or transacting through their jurisdictions.
Best Practices
Operationalizing sanctions list compliance requires coordinated effort across business, compliance, and engineering functions. The requirements differ depending on whether you are managing the business relationship with a payment provider or building the technical screening infrastructure itself.
For Merchants
Screen at every customer touchpoint — onboarding, profile updates, and significant transaction thresholds — not just at account creation. A customer who was clean at signup may be designated months later. Establish a schedule for re-screening the full customer database whenever a significant list update is published, and document that schedule in your compliance program.
Work with your KYC provider to ensure that identity attributes collected during onboarding — full legal name, date of birth, nationality, government ID numbers — are stored in a format that can be passed to a sanctions screening engine. Thin identity data degrades matching accuracy and increases false positive rates.
Maintain a written sanctions compliance policy and designate a responsible owner. Regulators weigh the existence of a formal compliance program heavily when determining whether to pursue enforcement and what penalty level to apply.
For Developers
Integrate a dedicated sanctions screening API rather than building list-matching logic in-house. List normalization, fuzzy matching, transliteration handling, and real-time update propagation are complex problems with significant legal consequences if misconfigured. Vendors such as Comply Advantage, Refinitiv World-Check, and Dow Jones Risk & Compliance specialize in this infrastructure.
Design your screening integration as a synchronous blocking step in the transaction authorization flow — not an asynchronous post-processing check. A transaction that completes before a match is adjudicated has already violated sanctions law, even if you subsequently reverse it.
Implement a dead-letter queue and alerting for any screening API failures. A payment flow that silently bypasses sanctions screening due to an API timeout is a compliance gap that OFAC treats the same as no screening at all. Fail closed: if screening is unavailable, hold the transaction.
Common Mistakes
Sanctions compliance fails in predictable ways. These errors appear repeatedly in OFAC enforcement actions and regulatory examination findings across acquirers, PSPs, and ecommerce platforms.
Screening only at onboarding. Many businesses configure screening for the customer creation event and then never re-screen. A customer designated six months after account creation continues to transact undetected. Ongoing transaction monitoring and periodic database re-screening are required components of an adequate compliance program.
Relying on a single list. Screening only against the OFAC SDN list while ignoring UN, EU, and HM Treasury lists is a common gap for businesses with cross-border operations. Each jurisdiction's list contains designations not found on others, and the regulatory obligation attaches to every jurisdiction in which a business operates or transacts.
Ignoring beneficial ownership. Sanctioned parties often structure transactions through entities they control rather than appearing as the named payer. Screening only the direct customer while ignoring the entity's beneficial ownership chain — particularly for B2B transactions — allows evasion that OFAC consistently penalizes.
Treating all fuzzy matches as false positives. High match thresholds reduce operational friction but also reduce screening effectiveness. Setting name similarity thresholds too loosely to minimize alert volume is itself a compliance program deficiency. Regulators expect documented evidence that match thresholds were calibrated thoughtfully, not tuned to minimize analyst workload.
Failing to screen digital asset addresses. OFAC has designated cryptocurrency wallet addresses under multiple sanctions programs, and those addresses appear on the SDN list. Crypto-enabled payment businesses that do not screen wallet addresses against OFAC's digital currency address designations are exposed to the same strict liability as fiat processors.
Sanctions List and Tagada
Tagada's payment orchestration layer sits at the intersection of multiple payment providers, acquirers, and rails — a position that makes sanctions list integration both strategically important and architecturally complex. Rather than duplicating screening logic across each connected processor, merchants can centralize their sanctions screening posture at the orchestration layer.
Centralize Screening at the Orchestration Layer
When routing transactions through Tagada across multiple acquirers, implement your sanctions screening API call as a pre-routing step in the orchestration logic. This ensures every transaction — regardless of which downstream processor handles it — passes through a single, auditable screening checkpoint. It eliminates the risk of a screened-clean transaction being re-routed to a processor that does not independently screen, and consolidates your compliance audit trail in one place.
Tagada's routing rules can also be configured to hard-block any transaction that returns an unresolved screening alert, preventing authorization attempts from reaching downstream processors while the alert is pending adjudication. This fail-closed behavior is the correct default posture under OFAC's strict liability standard.