Real-Time Sanctions and Watchlist Screening Alongside Fraud Scoring

Not a fraud score

A fraud score is a probability. Sanctions screening is a binary compliance check against a government list — a name or entity match, not a risk estimate. Blending the two into one combined number hides a compliance decision inside a probabilistic score, which is exactly the wrong place to hide it — a sanctions match needs its own clear yes-or-no record, not a contribution to a blended risk figure.

How it runs alongside, architecturally

The practical answer is a separate check running in the same synchronous decision path as the fraud score, for latency reasons, but producing its own distinct outcome with its own audit trail. Typically this means fuzzy name and entity matching against the current list — catching transliteration differences and typos, not just exact matches — with any match above a similarity threshold routed to human review rather than auto-blocked, because a wrongful block on a common name has its own real cost.

Why false positives matter here too

An overly aggressive sanctions screen on common names blocks a meaningful number of legitimate customers — the same false-positive-cost tradeoff that shapes the threshold-setting decisions in fraud scoring generally, applied to a different check with a different failure mode. Tuning match sensitivity is a real design decision, not a "set it strict and forget it" default.

The audit trail requirement

A sanctions-match decision needs its own reconstructable record: who was screened, against which version of which list, what specifically matched, and what a reviewer decided. This is the same event-log discipline our fraud-scoring project uses for fraud decisions, applied to a compliance check that regulators expect to be able to audit as a distinct decision, not folded into a general "we scored the transaction" log entry.

Keeping the list current

Sanctions lists update, sometimes with urgency. Screening has to run against the current version at transaction time, and — separately — existing customers need to be re-screened against list updates on a scheduled basis, not just checked once at onboarding. This is a distinct, ongoing job, not a side effect of screening new transactions — a customer who screened clean at onboarding two years ago isn't necessarily clean against today's list, which is why the re-screening job has to run on its own schedule rather than only at the moment of a new transaction.

A worked example

A transaction triggers a fuzzy match against a sanctions list — the recipient's name is a close but not exact match to a listed entity, a common enough occurrence with transliterated names. Rather than auto-blocking, the system routes it to a compliance reviewer with the match details: which list, which entry, the similarity score, and the recipient's own transaction history. The reviewer confirms it's a different person with a similar name and clears it within minutes — a false positive resolved without blocking a legitimate customer, and logged with the same rigor as if the match had been confirmed.

Where this stops being right

• This is general architecture guidance, not a compliance program. Specific sanctions and AML obligations vary by jurisdiction and business type — confirm requirements with counsel and your compliance function.
• Low cross-border or international exposure — a purely domestic business may have a much lighter sanctions-screening obligation.
• List provider and matching-engine choice matters a lot in practice — this article covers the architecture pattern, not vendor selection.

FAQ

Should sanctions screening feed into the fraud score? No — keep it a separate, deterministic decision with its own audit trail. Blending it into a probabilistic score obscures a compliance decision that needs to stand on its own.

Why does match sensitivity matter for sanctions screening? Because overly aggressive fuzzy matching on common names produces real false positives that block legitimate customers — the threshold is a genuine design tradeoff, not a "stricter is always safer" default.

Is onboarding screening enough, or does it need to be ongoing? Both — new transactions need real-time screening against the current list, and existing customers need periodic re-screening as lists update, as a separate scheduled process.

ISTRALLEN builds compliance-aware fraud-scoring architectures with sanctions screening as a distinct, auditable check — see AI for Fintech.