Insight
How does sanctions screening work?
In short
Sanctions screening is the process of comparing the names of customers, beneficial owners and counterparties against lists of people, companies, vessels and organisations that governments and international bodies have designated, and then deciding whether each match is real. It runs at onboarding, whenever a list changes, and before payments.
The hard part is not the comparison but what surrounds it: getting the lists right, matching names that are spelled or transliterated differently, clearing the false positives quickly, and keeping evidence that every hit was looked at by a person.
Which lists are screened
The baseline for any institution is the UN Security Council Consolidated List, which Zambia gives effect to under the Anti-Terrorism and Non-Proliferation Act. Most institutions also screen the US OFAC Specially Designated Nationals list, the EU consolidated list and the UK OFSI list, because correspondent banks and international counterparties expect it. Domestic lists, such as the FIC's politically exposed persons list, are added on top.
Aggregated datasets such as OpenSanctions collect these public lists into one feed with consistent identifiers, which simplifies keeping local copies current. Whatever the source, the institution remains responsible for knowing which lists it screens and how fresh they are.
Exact, fuzzy and transliterated matching
A name rarely arrives spelled exactly as it appears on a list. Screening engines therefore combine exact matching on identifiers such as passport numbers and dates of birth with fuzzy matching on names, which tolerates typos, swapped name order and missing middle names. Names originating in Arabic, Cyrillic or Chinese scripts can be transliterated several ways, so engines expand aliases across scripts before comparing.
Each technique widens the net and increases the number of hits that turn out to be innocent. Tuning the match threshold is a policy decision: too tight and real matches slip through, too loose and analysts drown in review work. The false-positives insight covers the trade-offs.
Secondary identifiers
A name match on its own is weak evidence. Good practice compares secondary identifiers, such as date of birth, nationality, identification numbers and entity type, before escalating. A person named on a list who was born in a different decade to your customer is almost certainly a different person, and recording that reasoning is what closes the alert.
Review and the four-eyes rule
Every potential match goes to a reviewer who marks it as a true match, a false positive or something needing more information. Many institutions require a second reviewer (the maker-checker or four-eyes rule) before a hit is cleared or a customer is exited, because both decisions carry consequences. A whitelist of confirmed false positives stops the same innocent customer being re-reviewed every time the list is refreshed.
Rescreening
Lists change daily. An institution that screened a customer at onboarding in one year has no assurance about that customer today unless it rescreens. Batch rescreening of the whole customer base after each list update, plus screening at the point of payment, closes that gap.
- Onboarding: screen the applicant and any beneficial owners.
- List update: rescreen the customer base against the delta.
- Payment: screen the counterparty before funds move.
- Periodic review: rescreen alongside the KYC refresh.
Evidence
A supervisor or auditor will ask what you screened, against which list version, what came back and who cleared it. Screening logs, list version stamps and reviewer decisions should be kept together and be tamper-evident. Some institutions also capture a screenshot of the screening result at the time of decision so the evidence does not depend on the list still being available later.
How ERMAML handles this
ERMAML, the Ontech Risk & Compliance Suite, keeps a local watchlist synchronised from the UN, OpenSanctions and FIC sources, matches with fuzzy and transliteration expansion through Elasticsearch, filters by entity type, routes hits through a four-eyes false-match review with a reusable whitelist, and captures evidence-grade screenshots of each screening result. See sanctions screening for the module.
Frequently asked questions
What is the difference between sanctions screening and PEP screening?
Sanctions screening checks for people and entities that are legally designated, where a match usually means the relationship must be frozen or refused. PEP screening checks for politically exposed persons, who are not prohibited but carry higher corruption risk and require enhanced due diligence. Both are usually run in the same pass.
How often should customers be rescreened?
Whenever the lists you screen against change, which in practice means daily batch rescreening against the list delta, plus screening at onboarding and before payments. The interval is a policy decision the institution should document and be able to defend to its supervisor.
What is a false positive in screening?
A hit where the screened name resembles a listed name but the person or entity is not the same. False positives are normal; what matters is that each one is reviewed, the reasoning is recorded, and confirmed false positives are whitelisted so they are not reviewed again unnecessarily.
Which sanctions lists apply in Zambia?
The UN Security Council Consolidated List is given effect under Zambian law. Institutions commonly also screen OFAC, EU and UK lists because of correspondent-banking expectations, and the FIC's domestic PEP list. Confirm current expectations with the FIC and your sector regulator.
Sources
See ERMAML on your own data
Request a demo with Ontech Solutions in Lusaka and see sanctions screening, KYC, transaction monitoring, goAML reporting and the risk register working together in one platform.