What Sanctions Screening Software Gets Wrong

A few years ago, a TIME reporter sent someone $1 through PayPal. The payment note contained two words: “Cuba Libre.”

PayPal immediately restricted the account and placed the transaction under review. TIME reported that PayPal blocked transactions containing the word “Cuba.”

The phrase itself had a much simpler explanation. Cuba Libre is the name of a cocktail.

This case captures a common challenge in sanctions screening software. It can recognize a potentially relevant word very quickly. Understanding what that word actually refers to takes more context.

The same challenge appears during customer onboarding.

A customer may share a name with a sanctioned person. Yet their age, nationality, location, and other identifiers may point elsewhere.

Finding a similarity is only the start of screening. Risk teams still need evidence showing whether that similarity matters.

Here are four common problems that explain why.

The cocktail problem: when the system sees a word, not its meaning

The “Cuba Libre” example starts with a genuine match. The word “Cuba” was present in the transaction note.

The screening control therefore had something real to detect. The difficulty comes after detection.

A word can describe a country or organization. It can also appear inside a product name, business name, address, or conversation. The surrounding context changes what that word means.

This creates a difficult balance for compliance teams. Screening rules need enough sensitivity to catch relevant exposure. Narrow rules could allow important cases to pass unnoticed.

Yet very broad rules create their own workload. Analysts may spend time reviewing matches with little connection to actual sanctions risk.

The same issue appears beyond payment descriptions.

An employer name may contain a geographic term. A news article can mention a sanctioned country without connecting the customer to it.

The useful question therefore goes beyond: Did the system find the term?

Risk teams also need to know why it appeared. They need to understand which person or entity it describes.

That requires contextual analysis around the original match.

A keyword can trigger the first review. Context helps determine where that review should go next.

The namesake problem: when the right name belongs to the wrong person

Consider an applicant named Omar Haddad.

During onboarding, a screening system finds the same name on a sanctions list. That similarity deserves attention.

Now the analyst looks deeper. The applicant was born in 1997. The listed person was born decades earlier. Their countries also differ. So do other available identity details.

The original alert was still useful. It identified something the compliance team needed to check.

However, a matching name alone does not establish identity.

This becomes especially important with common names. The same full name may belong to many unrelated people across several countries.

Partial matches can increase that number further. That is why modern screening relies on all the available identifiers. These can include:

• date of birth
• nationality
• country and location
• address
• known aliases
• other identity information

RiskSeal follows this approach within its watchlist screening process.

A check starts with basic identifiers listed in the application. But then our model brings 450+ alternative digital signals into the analysis. The system then compares all that information with relevant watchlists.

This turns name screening into a broader identity-matching task. The name creates the question. Additional identity data helps risk teams answer it.

The transliteration problem: when one person appears under several names

Names become more complicated when they cross languages and alphabets.

Take a familiar example: Muhammad, Mohammed, and Мохаммед.

Those spellings can refer to different people or represent different transliterations of the same name.

Now imagine screening across dozens of jurisdictions. A name may originate in Arabic, Cyrillic, or another script. Different databases can convert it into Latin characters differently.

The problem can then appear in two directions.

First, software may miss a relevant person. The sanctioned record uses one spelling while the applicant uses another.

Second, software may generate duplicate noise. Several spellings of one identity can appear as separate potential matches.

Simple string comparison struggles with this problem.

Screening systems need to account for language, alphabet, spelling variation, aliases, and transliteration patterns. They also need records structured around entities rather than disconnected text strings.

RiskSeal addresses this through entity normalization and deduplicated watchlist data. Its screening supports 65+ languages and multiple transliterations.

This matters because spelling and identity are different things. Different spellings may still describe one person. An identical spelling may describe several unrelated people.

The déjà vu problem: when the same false positive keeps returning

Now imagine an analyst has already reviewed a potential match. The names look similar. The dates of birth do not.

Several other identifiers also conflict. The analyst documents the case and clears the customer.

Later, the watchlist updates. The same similarity appears again.

Without previous case context, the next investigation may begin from zero. Someone has to reopen the information and repeat the same comparison.

For busy compliance teams, this creates unnecessary work.

Every alert requires attention because the consequences of missing a genuine match can be serious. Repeated investigations also consume time that could go toward more meaningful cases.

A good workflow therefore needs memory. Analysts should be able to see whether a match appeared before. They also need access to the reasoning behind the earlier decision.

That does not mean permanently ignoring a previous false positive.

The underlying record may have changed. New customer information could appear. A previously irrelevant case may become important later.

The useful approach keeps previous decisions available while checking for new information.

RiskSeal includes case management tools for this purpose. Teams can review results, assign cases, set priorities, escalate findings, and log decisions.

That creates an audit trail behind each investigation. It also gives the next analyst more than a familiar-looking alert.

Better sanctions screening starts with better match resolution

These four problems share the same pattern.

Software finds a potential connection. The next step determines how useful that connection becomes.

For compliance teams, this creates a practical sequence:

• turn a keyword into context
• turn a name into an identity
• turn a spelling into a normalized entity
• turn an alert into a documented case

This matters because ambiguous matches will always exist.

Two unrelated people can share a lot of details. The same person can appear under several spellings. A relevant keyword can appear in an irrelevant context.

Screening therefore needs to help teams separate weak similarities from stronger identity overlap.

That becomes even more important at scale. Lenders, neobanks, BNPL providers, and other fintechs may screen large customer volumes.

Each unnecessary investigation adds friction to an already demanding compliance workflow.

In my experience studying how financial risk products are built, reducing that friction requires better evidence around each alert.

The goal is to help analysts reach defensible conclusions with less repetitive work.

How RiskSeal adds context to watchlist screening

RiskSeal cannot make ambiguous names disappear. Its role is to give teams more information around the possible match.

The RiskSeal Watchlist and Adverse Media Screening API checks customers against sanctions lists, PEP databases, criminal registries, and adverse media sources.

Its sanctions coverage includes OFAC, UN, EU, HMT, and other records. RiskSeal currently checks against more than 1,700 global sanctions lists.

The underlying database refreshes every 30 minutes. Around 50,000 new records are added monthly.

Coverage alone does not solve the matching problem. The data also needs structure.

RiskSeal cleans and deduplicates records using entity normalization. Screening runs across 65+ languages and supports multiple transliterations.

This gives risk teams more ways to evaluate identity overlap.

The screening process also extends beyond sanctions.

RiskSeal covers PEPs and associated persons, financial crime links, regulatory actions, criminal investigations, and adverse media. Its adverse media monitoring covers more than 235,000 sources.

Each risk signal links back to its source. That gives analysts supporting information during review. It also improves traceability when a decision needs explanation later.

The final part is workflow. We provide built-in case management that lets teams review and escalate alerts. They can assign cases and keep a record of decisions.

The value does not stop at finding another possible match. Teams need enough context to understand that match and document what happens next.

A match should start the investigation

The $1 “Cuba Libre” transaction contained a real keyword. What the keyword could not explain alone was its meaning.

Customer screening faces the same limitation. A matching name deserves attention. So does a different transliteration or a new watchlist record.

Each one gives the risk team a lead. Context, identity resolution, and investigation history help determine what that lead actually represents.

Compliance teams already operate under significant regulatory pressure. Screening technology should help them focus that attention where it matters most.

Finding potential matches protects against missed risk. Understanding those matches helps teams make better decisions.

‍