Sanctions Screening / Learning brief
Customer screening versus transaction screening
Your notes
In simple terms / 01
What this means in plain language
Two sanctions controls guard different populations. Customer screening checks the people and entities a bank onboards; transaction screening checks every party named in a payment message in flight. Both are needed because neither control sees what the other sees.
A bank runs sanctions screening in two places, and they answer different questions. Customer screening compares the people and organisations the bank onboards — their names, owners, and connected parties — against sanctions lists when an account opens, when that data changes, and each time the lists are updated. Transaction screening compares the names inside a payment message while the payment is still moving, so an instruction involving a listed party can be stopped before it settles. The two controls see different populations. Customer screening only reaches parties the bank has a relationship with; transaction screening sees every name in every message, including third parties the bank will never onboard. In a chain of correspondent banks, an intermediary that never met either party may be the only institution positioned to notice a listed name at all. That is why a bank needs both, not one.
Complete lesson / 02
Understand the full idea, step by step
At an airport, two different checks guard against the same risk. Passport control examines who you are when you enter the country; the gate agent checks the name on every boarding pass as you fly. Neither replaces the other, because they watch different moments and different people. Sanctions screening splits the same way — into a check on who a bank onboards and a check on every party in a payment.
Two checks against the same lists
Sanctions screening is one obligation carried out by two controls in different places on different data. Customer screening — sometimes called name screening — compares the bank's own reference data (customer names, beneficial owners, directors, connected parties) against the lists. It runs at onboarding, whenever that reference data changes, and whenever the lists themselves change, so a newly designated party is caught even if the relationship is years old. Transaction screening compares the parties named inside a payment message — originator, beneficiary, and any agent or intermediary — while the payment is still in flight. The shared purpose is to stop a bank dealing with, or moving value for, a listed party.
Rescreening on list change — re-checking existing customers when the lists move
Rescreening on list change is the customer-side control that re-runs the existing customer base against a list whenever that list is updated. It exists because a customer who was clean when onboarded can be designated later — so screening once at account opening is not enough. When a list changes, the bank can rescreen its entire base or screen only the delta of changed entries; when a customer's own data changes, that change should itself trigger a fresh screen.
You may be wondering: if a firm screens its customers, why screen payments at all?
Because the two populations do not contain each other. Customer screening can see beneficial owners and connected parties that never appear in any payment message. Transaction screening can see third-party traffic — an originator or beneficiary at another institution — that flows through an account without ever becoming a customer. Neither view holds the other. A bank that screened only its customers would be blind to the counterparties in its payments; one that screened only payments would be blind to the connected parties behind its own customers.
| Customer screening | Transaction screening | |
|---|---|---|
| Population watched | The bank's customers and connected parties | Parties named in each payment |
| When it runs | At onboarding, on data change, on list change | While the payment is in flight |
| Data quality | Owned and improvable by the bank | Arrives from elsewhere, on a clock |
| Can also see | Beneficial owners not in any message | Third-party traffic that never onboards |
Different data, different confidence
The two controls behave differently because their data does. Customer data is structured, owned by the bank, and improvable: if a birthdate is missing or a name is garbled, the bank can request the correct value, fix the record, and screen it again before an account opens — customer due diligence feeds exactly this. Payment data arrives from elsewhere and on a clock. It may be truncated, abbreviated, or crammed into free-text fields, and the receiving bank usually cannot correct it, only decide on it. That is why customer-screening decisions tend to be more confident, while transaction alerts are more time-pressured.
WHAT IF — The same innocent namesake alerts on every recurring payment
What happens: A legitimate counterparty who happens to share a listed name generates the same transaction alert over and over, consuming review time.
How it is handled: The repeat alert can be suppressed for efficiency, but only under governed rules with a review date and a named owner — because yesterday's innocent namesake can become tomorrow's designation. Every decision — what is screened, against which list version, and how an alert was resolved — is logged so the outcome can be reconstructed later. The framing stays defensive: holds and alerts are the system doing its job, not failures to be minimised away.
COMMON CONFUSION
“Screening the customer at onboarding covers the sanctions risk, so payment screening is duplication.”
Onboarding screening only covers who the bank knew, at one moment, on the bank's own data. It cannot see the beneficiary at another bank in tomorrow's payment, and it does not, by itself, catch a customer designated after onboarding — that is what rescreening on list change and transaction screening are for. The two controls overlap in purpose but not in coverage.
STRICTLY SPEAKING
Strictly speaking, real institutions differ on whether one engine serves both controls or each has its own, and on exactly which attributes and connected parties are in scope. But the coverage logic is identical everywhere: the population a bank knows and the population whose payments it carries must both be watched, and each firm documents its own scope decisions.
FOR NOW, REMEMBER
- Customer screening watches the bank's own parties; transaction screening watches the parties in each payment.
- Customer screening runs at onboarding, on data change, and on list change; transaction screening runs while a payment is in flight.
- Customer data is owned and improvable; payment data arrives from elsewhere on a clock and usually cannot be corrected.
- Both are needed because neither population contains the other — and scope, versions, and dispositions are all logged.
TRY IT YOURSELF
Bank Alfa screened Asha Traders thoroughly at onboarding two years ago. Today Asha Traders sends a payment to a new overseas beneficiary who was added to a sanctions list last month. Which control is positioned to catch this, and why?
You have now seen both screening controls and the lists and product behind them. The topic behind this lesson adds the depth: how a list entry is built, and how its fields drive every match a firm must defend.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Customer screening checks who a bank banks; transaction screening checks what it moves.
- 02
The two controls cover different populations, so one cannot replace the other.
- 03
An intermediary bank may be the only party able to spot a listed name in a payment it merely passes on.
Practical use cases / 04
Where you would use this
A financial-crime analyst screens a new customer and its beneficial owners at onboarding, then rescreens the whole customer base when a list changes.
A payments operations reviewer works a held payment that transaction screening flagged, comparing the alerted name with the list entry before releasing or escalating it.
A compliance manager documents which customer attributes and which message fields each control screens, so coverage gaps can be found and closed.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Harbor Reach Bank, onboards a new customer, Delta Freight Limited, and customer screening compares the company name and its two named directors against the sanctions lists before the account opens — a calm check it can repeat whenever the lists change. Three weeks later a EUR 48,250.00 payment passes through the same bank acting only as an intermediary. Neither the sender nor the beneficiary is a customer, yet the beneficiary field matches a fictional listed entity, Meridian Ore Holdings, and transaction screening holds the payment within 8 seconds of the message arriving, before it can be passed downstream. Customer screening never saw those parties; only transaction screening did. The hold is the control working as designed, and a reviewer then compares the details and records a decision.
Evidence & review / 07
Evidence & review
Sanctions screening controls generally, across jurisdictions. Not legal advice; the precise scope of each control depends on a firm's regulators and risk assessment.
What this brief simplifies: Contrasts the two controls at a conceptual level and omits engine-specific configuration; whether one or two engines are used is firm-specific.
Sources for this brief4
- Market practice
Wolfsberg Group Sanctions Screening Guidance ↗ — The Wolfsberg Group · Customer and transaction screening coverage
Wolfsberg guidance is industry market practice, not law; institutions vary in how they apply it.
- Official requirement
The FATF Recommendations: International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation ↗ — Financial Action Task Force · Customer due diligence and ongoing monitoring
Adopted in 2012 and updated regularly since; the June 2025 FATF plenary agreed revisions to Recommendation 16 on payment transparency. Consult the live consolidated text for the current wording.
- Market practice
Wolfsberg Group Payment Transparency Standards ↗ — The Wolfsberg Group · Party information in payment messages
The 2023 standards replace the 2017 version and are supplemented by separate Wolfsberg guidance on roles and responsibilities in payment chains.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.