Screening payment messages
Payments are screened in flight: party fields, agent identifiers, and free text — and how the message is structured decides how well that works.
IN ONE LINE
An everyday analogy: the parcel gate reads labels, and labels come in two kinds.
A well-designed label has separate printed boxes — sender here, receiver there, contents note in its own field — so the checker knows exactly what each word is.
A messy label is one scrawled paragraph mixing names, addresses, and remarks, so the checker must treat every word as potentially a name.
Payment messages are the labels.
Older formats and free-text fields are the scrawled paragraph: everything must be checked, and a street name can look like a listed person.
Structured formats are the printed boxes: the checker can apply the right test to the right field.
Both must be screened — but one produces far more confident answers.
WHAT IT ACTUALLY IS
Transaction screening reads the whole message: originator and beneficiary names and addresses, intermediary and agent identifiers, countries, and the free-text spaces — remittance information and payment purpose — where any name might appear.
It runs at a point where the payment can still be stopped, typically as the payment engine processes the instruction, because a check after settlement can only report, not prevent.
Message format shapes precision.
An MT103 carries parties in line-oriented text fields where name, street, and city blur together; a pacs.008 provides structured elements so a name is labelled as a name and a country as a country.
The screening engine maps each message type's fields to screening attributes, and that mapping is part of the control — an unmapped field is an unscreened field.
HOW IT WORKS
Free text is where practitioners earn their pay.
Remittance lines produce the noisiest hits — geographic terms, ship names, ordinary words that collide with short list names — yet they cannot be skipped, because a listed party mentioned only in the payment reference is still a listed party, and the linked free-text scenario shows exactly that.
Role matters too: an intermediary bank screens traffic where neither party is its customer, so it decides holds with the least context and often must query another bank for information before it can dispose of an alert.
Holds have operational physics: a held payment sits in a queue while cut-offs approach, so escalation paths and staffing follow the clock.
And upstream data handling — truncation or lost structure in translation between formats — quietly shrinks what the filter can see.
THE WORDS
- Screening scope
- The decision about which message fields are actually screened — the boundary that determines what a filter can possibly catch.
READ FIRST
CONNECTED TO
SOURCES
- Wolfsberg Group Sanctions Screening Guidance — The Wolfsberg Group
- Wolfsberg Group Payment Transparency Standards — The Wolfsberg Group
- Payments Signal editorial teaching models — Payments Signal
Derived from Screening payment messages. Every claim on this card is sourced on that page.