Sanctions Screening Basics for Payments

Sanctions screening is one of the oldest and most consequential controls in financial crime prevention. Its purpose is simple to state and hard to execute: make sure you are not processing a payment for, or on behalf of, a person or entity that is subject to sanctions. Getting it wrong carries serious legal and reputational consequences, and yet the mechanics, matching messy real-world names against imperfect lists, are genuinely difficult. This post covers the basics that payments builders and risk readers need to understand.

What sanctions screening is

Sanctions are restrictions imposed by governments and international bodies against specific individuals, entities, jurisdictions, or activities. Screening is the process of checking the parties and details involved in a payment, or the parties in your customer base, against the relevant sanctions lists to ensure you do not deal with a restricted target.

There are two broad moments where screening happens:

• Customer screening, performed when you onboard a customer and periodically thereafter, checking them against sanctions and related lists.
• Transaction screening, performed on payments in flight, checking parties and, on some rails, payment-message fields against the lists before the payment is processed.

Both matter. A customer can be sanctioned after onboarding, and a payment can involve counterparties who are not your customers at all.

The lists

Screening depends on reference data published by authorities. Several jurisdictions maintain consolidated sanctions lists, and many publish them in open, machine-readable formats so that firms can ingest them programmatically. Which lists apply to you depends on where you operate, the currencies you handle, and the jurisdictions your payments touch. A firm may need to screen against several lists at once.

Alongside strict sanctions lists, screening programmes often incorporate related signals such as politically-exposed-person status and adverse media. These are not sanctions in themselves, but they feed a broader risk picture. It is important to keep the categories distinct: a sanctions hit is a hard legal matter, whereas PEP or adverse-media flags inform risk-based decisions.

The matching problem

If names were clean and unique, screening would be trivial. They are not. The core technical challenge is matching a name in your data against a name on a list when the two may differ in spelling, transliteration, word order, or completeness.

Real-world complications include:

• Transliteration, where a name originally written in another script has several valid Latin spellings.
• Aliases and variations, including nicknames, abbreviations, and reordered name parts.
• Common names, where a legitimate customer happens to share a name with a listed individual.
• Incomplete data, where a payment message carries only part of a name or lacks distinguishing details like date of birth.

To cope, screening systems use fuzzy-matching techniques rather than exact string comparison, scoring how closely a name resembles a list entry. The threshold you set governs a fundamental trade-off.

False positives and tuning

Set the matching threshold too loose and you generate an overwhelming number of false positives, alerts where an innocent customer resembles a listed name. Set it too tight and you risk missing a genuine match, a false negative, which is the outcome you most need to avoid. Because a missed true match is so serious, screening tends to err toward sensitivity, which means false positives are an inherent and ongoing operational cost.

Managing this is a permanent discipline. Teams tune thresholds, maintain good-quality data, keep an audit trail of decisions, and use secondary details such as date of birth to discount false hits quickly. Whitelisting previously cleared matches, carefully and with governance, helps keep the queue manageable without weakening the control.

Where screening fits

Sanctions screening is a name- and list-based control, which makes it different from behavioural monitoring. Screening asks who is involved; behavioural monitoring asks whether the pattern of activity looks suspicious. A complete financial-crime programme needs both.

In practice, screening sits alongside real-time transaction monitoring in the payment flow. A payment might pass a sanctions check on the parties involved while still being flagged by a monitoring typology for a suspicious pattern, or vice versa. Open real-time monitoring platforms are designed to complement screening in exactly this way. Tazama, for example, is an open-source real-time fraud and AML monitoring platform built for high volumes; it focuses on behavioural typologies and pairs naturally with list-based sanctions screening. At KibiPay we combine sanctions screening with Tazama-based monitoring across our rails, so that both the identity question and the behaviour question are answered on every payment.

Screening tells you who you are dealing with; monitoring tells you what they are doing. You need both answers on every payment.

Practical advice for builders

A few principles keep a screening programme healthy. Ingest the lists that actually apply to your operations and keep them current, since lists change frequently. Invest in data quality, because clean input reduces both false positives and misses. Treat matching thresholds as tunable and review them with real outcomes. Keep a clear audit trail so every decision can be explained. And remember that screening is a legal control with little tolerance for missed true matches, which shapes every trade-off you make.

Takeaway: sanctions screening checks the parties and details in a payment against restricted lists, and the real work is in matching messy names accurately while managing an unavoidable stream of false positives. Treat it as a distinct, list-based control that works best alongside behavioural transaction monitoring, and give it the data quality and governance the stakes demand.