Sanctions Screening / Learning brief
Screening the payment message
Your notes
In simple terms / 01
What this means in plain language
Transaction screening reads the whole payment message, including debtor, creditor, their agents, and free-text remittance, at a point where the payment can still be stopped. A hit parks the payment in a hold queue for a reviewer to decide.
Transaction screening checks a payment while it is still moving, before the bank completes it. The filter reads every place a name could appear: the debtor (the payer) and creditor (the payee) with their addresses, the banks acting as their agents, the countries involved, and the free-text spaces where a sender writes remittance information or a payment purpose. It runs at the moment the payment engine processes the instruction, because a check after the money has settled can only report a problem, not prevent it. When a field resembles a sanctions-list entry closely enough, the payment does not continue. It parks in a hold queue, and a trained reviewer compares the flagged party with the list entry and records a decision, either release as a false positive or escalate as a possible true match. How the message is structured decides how precisely the filter can read each field.
Complete lesson / 02
Understand the full idea, step by step
When a parcel crosses a border, customs does not weigh only the box — it reads the sender, the recipient, the addresses, and the description of what is inside, because a prohibited item can hide in any of those lines. Transaction screening reads a payment message the same way, for the same reason: a listed name can appear in almost any part of it.
Transaction screening
Transaction screening reads the whole payment message at the moment the payment engine processes the instruction — while the payment can still be stopped. It checks the debtor (the payer) and creditor (the payee) with their addresses, the intermediary and agent banks that route the payment, the countries involved, and the free-text spaces where a sender can write almost anything. Amounts and dates are read past: they carry no name to screen. A check performed after the money has settled can only report a breach, not prevent one — timing is as much a part of the control as coverage.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
In this structured ISO 20022 message each party sits in its own labelled field: Dbtr (debtor) and Cdtr (creditor) names, their agents in DbtrAgt and CdtrAgt, and free text in RmtInf. The filter can apply a name test to a name field and a country test to a country code. IntrBkSttlmAmt and IntrBkSttlmDt carry no name, so the filter reads past them. This message travels bank to bank — the customer never sees it.
Free text is where the noise lives
Free-text fields are where reviewers earn their keep. A remittance line is unstructured, so the filter must treat every word in it as a possible name — and ordinary language collides constantly with short list entries. Place names, ship names, and common words trip the filter. These hits are noisy, but the field cannot be skipped: a sanctions target named only in a payment reference is still a sanctions target, and missing it would be a real breach. Position in the chain changes the difficulty too — an intermediary like Meridian holds an alert with the least context and often has to ask another bank for information before it can decide.
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
The older line-oriented format tells a harder story for the filter. In field :50K: (the ordering customer) the name, street, and city are packed into free-form lines with no label saying which is which — so a hit is harder to judge than in the structured message above. This is why message structure is itself part of the control, not a cosmetic detail.
| Line-oriented MT103 | Structured pacs.008 (ISO 20022) | |
|---|---|---|
| Party data | Name and address blended into free-form lines | Each element in its own labelled field |
| Filter precision | Cannot always tell which word is a name | Field-aware: a name test on a name, a country test on a code |
| Effect on false positives | More noise from address text | Measurably fewer, where senders populate the fields |
WHAT IF — A message is truncated or loses its structure as it is translated between formats
What happens: The filter quietly sees less than the sender actually wrote — an unmapped or dropped field is an unscreened field, a coverage gap rather than a visible error.
How it is handled: Institutions actively watch upstream handling for this. Which fields of which message types are screened is a documented risk decision with an owner, and migration periods — such as a rail moving to ISO 20022 under CBPR+ — are exactly when every field mapping must be rebuilt and retested.
STRICTLY SPEAKING
Strictly speaking, the structured format only helps where senders actually populate the labelled fields instead of pasting unstructured text into them, so real usage varies by community. And underpinning all of it is a defensive obligation, not a technique: a payment service provider should not omit or alter debtor or creditor information in a way that would defeat another party's screening. Complete, correctly placed party data is what makes every downstream filter able to do its job — the topic of the transparency lesson ahead.
FOR NOW, REMEMBER
- Transaction screening reads the whole message — debtor, creditor, their addresses, agent banks, countries, and free text — because a listed name can hide anywhere; amounts and dates carry no name.
- Screening runs while the payment can still be stopped; a check after settlement can only report a breach.
- Free-text remittance is the noisiest field but cannot be skipped, and an intermediary screens with the least context of anyone.
- Message structure is part of the control: labelled ISO 20022 fields let the filter test the right field, where the older format blends name and address.
TRY IT YOURSELF
An operations team suggests moving sanctions screening to a nightly batch that runs after payments have settled, to keep the daytime payment path faster. Why is this the wrong design for sanctions?
You have seen what gets screened and when. The next lesson steps back to the machine around it: where screening sits in the payment path, and how it holds up under a strict clock.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Screening reads the whole message, meaning debtor, creditor, their agent banks, countries, and free-text remittance, because a listed name can sit in any field.
- 02
It runs while the payment can still be stopped; a check after settlement can only report, not prevent.
- 03
A hit does not fail the payment silently; it parks it in a hold queue for a reviewer to release or escalate on the record.
Practical use cases / 04
Where you would use this
A payments operations reviewer works a hold queue, comparing each flagged party against the list entry and clearing or escalating before the rail's cut-off time.
An intermediary bank screens traffic where neither the debtor nor the creditor is its customer, and requests information from another bank when it lacks context to close an alert.
A screening configuration team maps every field of each message type to a screening attribute and retests those mappings whenever a rail migrates format, so no field goes unscreened.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Northwind Bank, processes an outbound cross-border payment of USD 62,400.00 from its customer Acme Textiles Ltd to a supplier, Delta Fabrics LLC. The structured party fields are clean, but the free-text remittance line reads 'Order 5567 via Castellan Trading'. The screening filter matches Castellan Trading against a fictional list entry, CASTELLAN TRADING CO, on invented Programme VESTA, at 0.91 against a 0.85 threshold. The payment parks in the hold queue rather than settling. A reviewer sees that the message names a third party in the reference, cannot resolve it from the message alone, and requests details from the sending bank. Because the payment involves a possible listed party, it stays held past its intended value date until the reviewer records a disposition, the control working exactly as designed.
Evidence & review / 07
Evidence & review
Transaction (payment-message) screening across MT and ISO 20022 formats; field mappings and scope are institution- and rail-specific.
What this brief simplifies: Uses two fictional sample messages to contrast blended and labelled fields. Real screening scope is a documented mapping per message type.
Sources for this brief3
- Market practice
Wolfsberg Group Payment Transparency Standards ↗ — The Wolfsberg Group
The 2023 standards replace the 2017 version and are supplemented by separate Wolfsberg guidance on roles and responsibilities in payment chains.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group)
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- 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.