Watchlists

In short

Watchlists are registries of people and entities that an organization screens its customers against, before onboarding them and periodically afterward.

They are not a single registry, and they do not all have the same effect. Some lists produce a positive result that blocks operating, and some produce a positive result that only requires closer scrutiny. Confusing them is the most common operational mistake in this part of the process.

And the screening does not decide anything on its own: it produces matches that an analyst has to resolve.

What categories exist and what consequence each one has

The three categories that show up in any onboarding process in the region work differently.

• International sanctions — designations issued by multilateral bodies or by national authorities with extraterritorial reach, restricting business with certain people and entities. This is the category with the harshest consequence: a confirmed match normally blocks the relationship, and under several regimes requires reporting.
• National lists — registries issued by local, judicial, tax, or sector-specific authorities in each country. Their effect depends on the regulation that creates them: some restrict, others only require documenting a decision.
• [Politically exposed persons](/glosario/pep) — the registry of those who hold or held relevant public office, along with their family members and close associates. Strictly speaking, this is not a watchlist, although it gets screened in the same step: a match does not restrict anything, it triggers enhanced due diligence.

There is a fourth source that gets checked alongside the previous ones and is not a list: adverse media, which covers news reports and judicial records about the person. It has no authoritative issuer or defined format, which is why any finding gets documented as input to a decision rather than as the result of a control.

Which specific lists an organization must screen against is not a vendor's decision: it is determined by the regulation that binds it and the geographic scope of its operation. This page does not enumerate them on purpose, because designations change, and an outdated roster on a public page is worse than none at all.

A match is not an identification

This is the part that separates a process that works from one that produces wasted effort.

The screening is done, in most cases, against a name and a date of birth. Names repeat, get transliterated differently depending on the source alphabet, get abbreviated, and pick up typos. The result is that most matches a screening produces correspond to people other than the one on the list.

Three practical consequences follow from that.

• A match opens a case, it does not close it — the screening result is an alert that an analyst has to resolve by comparing additional attributes until it is ruled out or confirmed.
• The resolution gets documented — both the dismissal and the confirmation. A false positive resolved without a record is indistinguishable, on inspection, from an alert that was ignored.
• Setting the matching threshold is a risk decision — a strict matching criterion reduces noise and lets variants of the same name slip through. A loose one catches everything and overloads the team until the team stops looking.

That last point is what turns screening into a calibration problem rather than a coverage problem. An organization that screens against many lists with a poorly calibrated threshold is worse off than one that screens against fewer and resolves them well.

Screening does not happen just once

A list-screening control run only at onboarding covers a single snapshot, and reality is a movie.

Designations get added, modified, and lifted continuously, and a person's status changes independently of their relationship with the organization. A customer onboarded with no matches can get designated the following year, or take on a public role that makes them a PEP.

That is why the control has two distinct moments.

• At onboarding — before establishing the relationship, as a condition for onboarding.
• Across the existing portfolio — periodically and whenever the lists get a relevant update, across all active customers.

The second is the one organizations implement late, and the one an inspection scrutinizes most closely, because that is where it shows whether the control is an onboarding requirement or a living process.

Which identity gets screened

This is where the control's structural limitation shows up, and it does not get solved by screening against more lists.

The screening runs against the data the person declared. If that data belongs to an identity that was not properly verified, a clean result means nothing: someone using another person's document, or an identity built from combined data, passes the filter with no matches because the name it gets screened against is not really theirs.

Put the other way: watchlist screening inherits the quality of the identity verification that comes before it. It is a control about who the person is, and it only works if that "who" was established with evidence.

That is why order matters. Establish the identity first, screen it second.