What is transaction screening, and why clean payments still get through

INTERPOL’s March 2026 Global Financial Fraud Threat Assessment estimates that global losses from financial fraud reached $442 billion in 2025 alone and that the figure is likely conservative given how much global fraud goes unreported.

Most of that money didn’t disappear in one dramatic heist. Instead, it moved in ordinary-looking payments, one wire or transfer at a time, through banks and payment firms that were checking those payments against sanctions lists and watchlists the whole way.

Transaction screening is that check, and the gap between running it and running it well is where a meaningful share of that $442 billion gets through.

When there’s no check at all: the IMG Academy case

Not every screening failure is a near-miss buried in a false-positive queue. Some are simpler than that, and these are the ones where no screening was running at all.

On 12 February 2026, the US Treasury’s Office of Foreign Assets Control announced a $1,720,000 settlement with IMG Academy, covering 89 apparent violations of counternarcotics sanctions. Over five consecutive years, the Florida school signed tuition agreements with two people on the US sanctions list, invoiced them by name, and accepted their payments.

No matching algorithm was defeated here, and no near-miss slipped past a tuned threshold. The school ran no sanctions screening on tuition payments at all, so the names on its invoices were never checked against any records.

It’s an extreme case, but it points to a question worth asking before any conversation about match accuracy: is every party in a payment even being sent to the engine in the first place? A system built to catch near-misses in spelling and transliteration is still no help if the name never gets checked to begin with.

What is transaction screening?

Transaction screening compares the names of the people involved in a transaction against sanctions lists and watchlists before the payment settles. The main piece of information used here is the payment instructions, which is the electronic message that moves the money and includes the name of the sender, receiver, and usually one or more banks in between.

Screening checks those names against the lists, and if a possible match is found, the payment can be put on hold.

The transaction screening meaning that matters in practice is narrower than most definitions admit. Screening does not ask whether a payment looks unusual for that customer, and it does not consider what the customer did last month. Screening asks one question. Is anyone named in this payment on a list we are required to act on?

That narrow focus makes transaction screening in AML both fast and fragile. A check against a fixed set of names in a fixed set of fields returns an answer almost immediately and sees nothing outside those names and fields.

How does the transaction screening process work?

The transaction screening process runs in three steps. Each step can return a clean result for a different reason, and only one of those reasons means the payment is genuinely clean.

• The lists a payment is checked against

A firm first identifies which sanctions regimes apply to it, adds records of politically exposed persons and any internal watchlists, then sets how often that data refreshes. Sanctions authorities add names on no fixed schedule, so a payment cleared against last night’s data can involve someone designated, meaning added to a list, this morning.

• How names in the payment get matched

The engine reads the payment instruction, pulls out the party names, and checks them against the list data. Exact spelling matching would be useless on its own, because in real life, names arrive misspelt, shortened, converted from other alphabets, and cut short by intermediary systems. Engines therefore allow for near-misses and sound-alike spellings, which is also why they raise so many false alarms.

Deciding which of those alarms is real is the harder half. In Shufti’s Voice of Customer research across more than 600 organisations, 11% said they cannot reliably tell a true match from a false one, and the reasons given were common names, list entries matching irrelevant records, and missing primary and secondary exposure labels. Loosening or tightening the match logic does not touch any of that, because the missing input is information about the person rather than the spelling of the name.

• What happens when a payment is flagged

A possible match suspends the payment and sends it to an analyst, who either clears it as a false alarm or escalates it. Time pressure bites hardest here, because instant payment systems are built to settle in seconds, while the review is a human judgement that has to be written down and defended later.

Transaction screening vs transaction monitoring in AML

The two terms often get used as if they mean the same thing. The two are separate controls answering separate questions, and the difference decides which one to examine when something goes wrong.

Neither replaces the other. Screening will not spot a customer splitting a large deposit into smaller ones to stay under a reporting threshold, a tactic known as structuring. AML Transaction Monitoring will not stop a single transfer to a sanctioned company before the money leaves. For the longer comparison, see transaction screening and monitoring side by side, and for the wider control set, sanctions screening.

Where transaction screening usually fails

Vendors compete on match accuracy because accuracy is the one part of this process that can be measured cleanly, but the failures that end up in enforcement actions rarely begin with a bad match. They begin earlier, with a party nobody thought to screen, or later, with an alert an analyst was never given enough to justify.

Parties that never reach the screening engine

An engine can only check the parties a firm actually sends it, and there are several that routinely never get sent. A third party paying a customer’s bill, a sponsor funding an account, an agent bank sitting in the middle of a payment chain, or the institution collecting the money at the far end, all can touch a payment without ever appearing on the list of names the firm screens. Usually that isn’t because anyone decided to leave them out, but because a different team owns the relationship and nobody ever settled whose job it was.

IMG Academy is the clearest version of this. The sanctioned names sat on agreements the school had signed and on invoices the school itself sent out, and because nobody ever treated them as names that needed checking, the engine was never asked the question in the first place.

Which is why the more useful thing to ask a compliance team is not how accurate the matching is, but which parties touch our payments and never reach the engine at all.

Payment fields the engine cannot read

Even when a party does reach the engine, the engine can still only work with what the message actually contains. Cross-border payment messages have long allowed an address to be written as free text, so a counterparty’s address often arrives as a single unbroken line with no separate field for the town or the country, while the sanctions list it is being compared against keeps those details in properly separated fields. The comparison is unreliable as a result, and where the engine cannot read a field at all, it simply returns no match.

That is the part worth sitting with, because a field the engine could not read comes back looking exactly like a genuinely clear name. On screen, no match and a clean payment are indistinguishable.

Alerts that arrive without context

The third failure happens after the hit, once the payment is already sitting in a queue. An alert carrying a name, a score and nothing else leaves the analyst to rebuild the background by hand, working out who this counterparty is, what the firm already knows about them, and why the payment is being made. Under real-time pressure, some of that reconstruction quietly doesn’t happen, so the written reason for releasing the payment ends up thinner than the decision behind it deserved.

That gap matters more than it used to, because supervisors increasingly want to know why a payment was released, not simply whether a check was run.

All three failures come back to the same underlying disadvantage. Customer screening deals with someone you onboarded yourself, whose documents you hold and whose profile you built over time, whereas transaction screening has to reach a counterparty you have never dealt with, using nothing more than whatever the payment message happens to say about them.

What changes for payment data on 14 November 2026

Swift is removing free-text postal addresses from cross-border payment messages. From 14 November 2026, town and country must appear in their own dedicated fields for all agents and parties in CBPR+ payment messages, the message standard used for cross-border payments and reporting. A message that still carries an address as unstructured free text may be rejected or delayed.

Swift’s own stated purpose for the change is payment transparency. The screening consequence follows from that, and most readiness programmes miss it. Treated as a formatting job for the payments team, the deadline is administrative. Read properly, it raises the minimum quality of the counterparty data that feeds every screening engine.

Swift has said it cannot build a fallback for firms that are not ready, because address data has to be captured where the payment starts rather than repaired along the way. And around 65 market infrastructures do not yet have plans to handle structured or hybrid addresses from November 2026, so a payment beginning on a domestic system that still accepts free text can fail once it crosses into CBPR+ checks. Shufti has covered the migration itself in a separate ISO 20022 structured address guide.

How Shufti handles incomplete transaction data

Most engines treat a field they cannot read as a field containing nothing. A payment with an unreadable counterparty block then returns the same clean result as a payment with a genuinely clean counterparty, and the compliance team ends up defending a decision the system never really made.

Shufti’s transaction monitoring marks that situation as not assessable rather than scoring it as low risk. Where a required field cannot be checked, the gap is recorded against the transaction. It remains visible to the analyst, the money laundering reporting officer, and anyone auditing the file months later. The benefit shows up at review, when the reviewer can see exactly which checks ran and which ones could not. Missing data stops looking like low risk.