AML Screening / 3 min read
Watchlist Screening vs OFAC Screening
OFAC screening checks names against US Treasury sanctions lists. Watchlist screening adds UN, EU, UK, PEP, and other lists. When you need each one.
Search “OFAC screening API,” ship a string compare against the SDN file, and you will still fail the first review that asks about PEPs, UN listings, or a local restricted-party file. OFAC is one sanctions family. Watchlist screening is the job: take an identity you already collected and ask whether it appears on any list your policy subscribed to, then put possible matches in front of a person.
OFAC screening checks the U.S. sanctions lists. Broader watchlist screening adds other sanctions sources, PEP records, and adverse-media context. Define these source families clearly so engineering and compliance build the same workflow.
What you are actually buying
Naiza screens 1,100+ global sanctions, PEP, and watchlist sources in one workflow. The AML product page explains screening coverage, structured results, investigation cases, and full transaction monitoring.
Naiza returns AUTO_CLEAR, REVIEW, or CONFIRMED with source details and match evidence. Investigators compare identity fields, document outcomes, and connect screening results to cases and SAR reporting workflows.
REVIEW volume from fuzzy names and transliteration is expected. Arabic and Latin forms of the same name will not string-equal. Missing vowels, swapped given and family names, and corporate suffixes will all create candidates. If your success metric is zero reviews, you will either miss hits or you will train the matcher until it is timid. Staff the queue. Do not page the company for AUTO_CLEAR.
How I wire the case
Store the screening id. Store your customer externalId next to it. When a reviewer opens the case they should see the input name, date of birth if you have it, nationality, aliases, and the list entries that fired. Then they confirm or clear. If you cannot join an overnight list update back to the same customer, you do not have ongoing monitoring. You have a one-shot onboarding check that goes stale.
That join is why I fight product teams who mint a new customer id on every KYC retry. The legal name can change after a document correction. The externalId should not. Overnight hits have to land on the same case as the original screen, or your investigators will open a second file and miss the first note.
Counterparties and entities need the same habit. A payout to a new company is a screening event, not a comment in the payment ticket. Use a stable counterparty id. If you only screen the sender, you will clear a customer and still pay a listed name on the other side.
Introduce review and enforcement in stages
Route potential matches to REVIEW during the pilot and compare the supplied identity fields. Use the results to tune sensitivity, then apply holds and escalation to named outcomes. The AML pilot guide explains the rollout sequence.
Do not treat a UN listing, a PEP, and an OFAC SDN entry as the same severity in the case title. They have different legal meanings and different next steps. The matcher can share a pipeline. The case note should name the source.
If you are choosing when to run the check, onboarding is the synchronous moment. The existing book is a batch or event-driven re-screen when lists move. Onboarding versus ongoing AML is the architecture split. OFAC versus “watchlist” is the coverage split. Teams that collapse both splits into “we call OFAC at signup” spend the next incident rebuilding both.
I tell reviewers the same sentence I tell engineers: a possible match is a question. A confirmed match is a decision. OFAC is one of the lists that can raise the question. It is not the name of the control.