How is sanctions screening different from transaction monitoring, and what happens when a payment hits a name on a list?

Different obligation, different engineering

Transaction monitoring looks for behaviour that suggests laundering and produces suspicion, which a human evaluates and may report. It is risk-based by design: you tune it, you accept that it misses things, and the standard you are held to is whether your programme was reasonable.

Sanctions are not that. A sanctions measure prohibits dealing with a designated person or entity, and there is no risk appetite to calibrate against — processing a prohibited payment is a breach whether or not you meant to, and in many regimes strict liability applies. That single difference drives every engineering decision that follows. Screening runs before the money moves rather than after, it blocks rather than alerts, it is real-time on the payment path rather than batch, and "we sampled" is not an available answer. Monitoring is a detective control you tune for recall; screening is a preventive control you cannot knowingly bypass for latency.

Two populations, and neither one is optional

Party screening covers who you have a relationship with: customers, their beneficial owners and controllers, directors, signatories, guarantors, and related parties. It runs at onboarding and then again every time either side of the comparison changes — a new list version, or a change to the customer record. The re-screen on list change is the part that is easy to under-build, because a designation added today makes an existing, previously clean customer a prohibited one, and the obligation attaches from the moment the measure takes effect rather than from your next batch.

Message screening covers payments and trade transactions in flight: the debtor and creditor, their agents, the intermediaries in the chain, addresses, countries, and the free-text fields where a vessel name, a goods description or a purpose statement can carry the only reference to a designated party. Screening structured party fields and ignoring the unstructured ones is a well-known gap, which is one reason the richer structured data in modern payment formats is a compliance improvement and not just an integration cost.

Which lists apply is a question with a jurisdictional answer rather than a single one. Multinational measures, regional measures and each country's own designations may all be in scope, and the perimeter widens with your activity: clearing in a given currency, using an institution in a given country, or having a group entity there can each bring another authority's list into scope regardless of where the customer sits. Screening lists are also not all sanctions — politically exposed person data and adverse media inform risk assessment and do not prohibit anything, and conflating them produces a control that blocks payments it has no authority to block.

List ingestion is itself a control

The lists are published and revised by their issuing authorities on their own schedules, and getting the current version into your engine promptly is an auditable obligation. Three properties matter and are routinely missing.

Every version is retained, so you can demonstrate what your engine knew at the moment a payment was screened. Without this, defending a past decision is impossible, because the list you can display today is not the list the payment was screened against. Every ingest is monitored for completeness and for plausibility, since a truncated file that loads cleanly is the most dangerous failure available to you — the control reports healthy and screens against half a list. And every load is followed by a re-screen of the existing customer base against the delta, with the results reaching an investigator rather than a log.

Why name matching is hard, and where it is not the answer

You are comparing a string somebody typed to a designation that may have originated in a different script. Arabic, Cyrillic, Chinese and many other names have no single canonical romanisation, so the same person appears with several spellings, all legitimate. Name order varies by culture and forms often force a given-name-then-surname structure onto names that do not have that shape. Patronymics, honorifics, particles, hyphenation and initials all vary. Dates of birth are frequently partial or absent on a designation, and common names generate enormous numbers of coincidental matches.

So matching is deliberately fuzzy — edit distance, phonetic encoding, token-level comparison, transliteration tables, and secondary discriminators such as date of birth, nationality and address used to score rather than to filter — and the consequence is a high volume of hits that are not matches. That volume is expected and the response is not to loosen the algorithm. It is to invest in the adjudication side: present the investigator with the full list entry, every identifier on it, and the customer or payment context side by side, so a decision takes seconds.

Adjudicated false positives are recorded so the same hit does not stop the next payment, but the record must be keyed to the specific customer or party record, the specific list entry, and the version of that entry. When the authority amends the entry — adds an alias, adds a date of birth, changes the spelling — the earlier discount is no longer evidence about the amended entry and must be re-evaluated. A permanent, unversioned whitelist is how a genuine match eventually walks through a control that once looked at it and was right.

Name matching also cannot find the case that matters most. An entity may be prohibited because it is owned or controlled by a designated person without appearing on any list itself. Detecting that needs ownership and control data, aggregation rules for holdings across several designated owners, and a view of the corporate structure — a data problem, not a string problem. The thresholds and the aggregation treatment differ between regimes, which is exactly why the answer is to hold the ownership graph and apply the applicable rule rather than to rely on the list containing every affected entity.

What you do with a hit

The payment stops. It does not continue while somebody looks into it, and it is not released because a service level is at risk. Where the rail imposes a timeout measured in seconds, the resolution is to screen earlier — pre-screen stored beneficiaries, screen at instruction rather than at release — and to let the payment fail the scheme's timing rather than pass unscreened.

An investigator then compares the hit against the full designation. Most are discounted with a recorded rationale. Where it is a true match, the outcome depends on the measure and the jurisdiction, and the two outcomes are genuinely different. Rejecting means you refuse to execute and return the funds to where they came from. Freezing or blocking means you must not return them either: the funds are held, typically in a segregated position, no dealing is permitted, and the holding is reported to the relevant authority and then reported again periodically for as long as it lasts. Getting this the wrong way round is a breach in both directions — returning funds you were obliged to freeze puts them back in a designated party's reach, and freezing funds you were only obliged to reject deprives an innocent party of their money.

Alongside that sits a communication constraint that catches candidates out. Many regimes restrict disclosing that a report has been made or that an investigation is under way, so what the customer is told is prescribed rather than a service decision, and the customer-facing systems must be built so that a well-meaning agent cannot explain the real reason. Licences and derogations are the other side of it: authorities can permit specific payments — basic living expenses, legal fees, pre-existing contracts — and the permission is a legal instrument you hold and evidence, not a discretion your team exercises.

Monitoring asks whether behaviour looks suspicious; sanctions asks whether you are permitted to move this money at all. Once you see it as a prohibition, the awkward parts stop being awkward: you screen before the money moves, you version the lists so a past decision is defensible, and you never release a hit because the clock is running.