Topic archive
Plain-language learning briefs that route you to the key ideas, operational questions, and practical context for this part of the payment ecosystem.
Latest first
Sanctions are legal restrictions on dealing with listed people, entities, and places. Screening is the control that enforces them, checking every customer and payment against official lists before money is allowed to move.
Several authorities issue sanctions: the United Nations, the United States, the European Union, and the United Kingdom among them. Their lists overlap but are not identical, so a bank must decide which regimes its business obliges it to apply.
A designation usually forbids two things: freezing the funds and economic resources of a listed party, and making no funds available to them, directly or indirectly. Narrower sectoral restrictions limit only specific activities rather than freezing everything.
Sanctions screening is a list check with an immediate stop. Anti-money-laundering monitoring looks for suspicious patterns after the fact, and fraud detection protects against theft in real time. The three share data but differ in purpose, timing, and outcome.
The duty to freeze is absolute, but how a bank calibrates its screening, which lists, how sensitive the matching, how often it re-screens, is a set of documented, defensible risk decisions proportionate to the bank's exposure.
A single sanctions list record holds a primary name, aliases, dates and places of birth, nationalities, and identifiers, each tied to a programme tag. This article explains how every field drives a screening match and a defensible review.
Strong secondary identifiers, such as dates of birth, passport numbers, and places, let a screening system confirm or clear a party with confidence. This article explains how good data cuts false positives and what weak data costs.
Authorities publish sanctions lists and change them over time; vendors and feeds carry those additions and removals to screening systems. This article explains the delivery path and why loading updates promptly matters operationally.
Screening vendors merge many official and commercial sources into one combined list. This article explains how aggregation works and why keeping each record's provenance, meaning which authority and which list it came from, is essential for defensible decisions.
Two sanctions controls guard different populations. Customer screening checks the people and entities a bank onboards; transaction screening checks every party named in a payment message in flight. Both are needed because neither control sees what the other sees.
The stages a payment or customer record passes through in a screening engine: normalising the input, generating candidate matches, scoring them against a threshold, disposing of each alert as cleared or escalated, and recording every step for later reconstruction.
How fuzzy matching catches names that resemble a sanctions-list entry without being spelled identically — handling transliteration, spelling variants, missing words, and word order — and why that reach is bought at the price of innocent lookalikes.
A name similarity only opens a question. Dates of birth, nationalities, and document numbers are the evidence that closes it, strengthening a genuine hit or supporting the release of an innocent namesake, always on the record.
Transaction screening reads the whole payment message, including debtor, creditor, their agents, and free-text remittance, at a point where the payment can still be stopped. A hit parks the payment in a hold queue for a reviewer to decide.
A screening platform connects list management, a matching engine, hold queues, and case-management tools inside the payment path. Its design answers hard questions about latency and availability, because a filter that silently stops checking is the dangerous failure.
A screening alert flags a payment or customer whose name or identifiers resemble a sanctions-list entry. This article explains how an analyst weighs evidence to clear a false positive or escalate a likely match, and why each decision is recorded.
Screening governance is the framework of policies, roles, approvals, and controls around a sanctions programme. This article explains how ownership and documented decisions let an institution defend its configuration choices to auditors and supervisors.
A screening system must catch true sanctions matches without burying analysts in false alerts. This article explains how synthetic test cases and careful threshold tuning balance those aims, and why each change is documented and re-tested.
Payment transparency means complete, unaltered originator and beneficiary information must accompany a payment so every institution can screen it. Wire stripping — removing or altering that party data — defeats screening, and transparency controls exist to detect and prevent it.
Sanctions evasion is attempted through front companies, transhipment, dual-use goods, ownership webs, and obscured party data. This defensive article describes the red flags and detection methods that let controls surface these patterns for review.
A screening product manages several distinct kinds of list — official sanctions, politically exposed persons, adverse media, internal watchlists, allow lists, geography, institution, and regulatory-request lists. Each list has a different purpose and drives matching and disposition differently.
An end-to-end view of the capabilities leading sanctions screening products share — list management, a matching engine, real-time and batch screening, hold queues, alert and case management, disposition, tuning, and audit.
Swift offers a set of hosted compliance services, including sanctions and name screening, transaction screening, and analytics, letting smaller institutions run these controls through a shared utility rather than building everything in-house.