One Constellation
Sanctions Screening

Payment Screening: How Sanctions Checks on Payments Work

Customer screening tells you who you are doing business with. Payment screening tells you where each payment is going, who else is involved and whether you are allowed to process it — before the money moves. This guide explains how it works, what it checks, and how ISO 20022 and FATF's revised Recommendation 16 are changing it.

Published: October 2026 Category: Sanctions Screening Read time: ~10 minutes
Quick Answer
Payment screening (also called transaction screening) checks the parties, banks, countries and free-text fields in a payment message against sanctions lists before the payment is executed, so that a prohibited payment can be held, rejected or blocked rather than discovered afterwards. It is different from customer screening, which checks your own customers at onboarding and periodically. Payment screening has to run on every payment, often in seconds, which makes false-positive management the central operational problem. Two changes are reshaping it: the move to ISO 20022 structured payment messages (cross-border coexistence on Swift ended on 22 November 2025), and FATF's revised Recommendation 16 (June 2025), which requires richer, structured originator and beneficiary information on payments, to be implemented by the end of 2030.

Sanctions laws generally prohibit making funds available to designated persons, directly or indirectly. A bank can screen its customers perfectly and still breach sanctions by processing a payment to a designated person, through a sanctioned bank, or for goods shipped to an embargoed region. Payment screening is the control that catches those cases.

It sits alongside — not instead of — sanctions list screening of customers and transaction monitoring, which looks for suspicious patterns after the fact.

Payment Screening vs Customer Screening

Customer screeningPayment screening
What is screenedYour customers, their beneficial owners and connected partiesEvery party and institution named in a payment, plus countries and free text
WhenAt onboarding, on list updates and periodicallyOn every payment, before execution
Speed requiredMinutes to hoursSeconds — near-instant for real-time payment schemes
Outcome of a true matchDecline or exit the relationship; freeze assets where requiredHold, reject or block the specific payment; report where required
Main difficultyName variants and data qualityVolume, speed and unstructured message data

The two are complementary. Customer screening cannot see the counterparty on the other side of a wire; payment screening cannot tell you whether your own customer has just been designated.

What a Payment Screening System Checks

A screening engine parses the payment message and compares each relevant field against the applicable lists — typically OFAC, UN, EU, UK and the local regulator's lists, such as MAS in Singapore:

  • Originator and beneficiary — names and addresses of the ordering and receiving customers.
  • Financial institutions — ordering, intermediary and beneficiary banks, usually by BIC as well as name.
  • Countries and cities — to catch embargoed jurisdictions and sanctioned regions, including in address lines.
  • Free-text fields — remittance information and payment details, where vessel names, ports, goods descriptions or third-party names can appear.
  • Ultimate parties — the ultimate debtor or creditor where the message identifies them.

Field awareness matters. A city name matching a sanctioned region is significant in an address field and meaningless in a company name — engines that screen the whole message as one block of text generate far more false positives.

Hold, Release, Reject or Block

When the engine produces a potential match, the payment stops and an analyst reviews it. There are four outcomes:

  • Release — the match is a false positive; the payment proceeds. The reasoning must be recorded.
  • Request information — the payment stays held while the firm asks the ordering bank or customer for clarification.
  • Reject — the payment is refused and returned, where processing it would breach sanctions but the funds do not need to be frozen.
  • Block / freeze — the funds are frozen where the law requires it, for example where a designated person has an interest in them.

Reporting obligations follow. In the US, for example, OFAC requires blocked property and rejected transactions to be reported within 10 business days. Every decision, including releases, needs an audit trail that shows who decided, when and why.

ISO 20022 and Payment Screening

ISO 20022 replaces the legacy Swift MT format with richer, structured messages. On 22 November 2025 the coexistence period for cross-border payments on Swift ended, so payment instructions between institutions on Swift now use ISO 20022.

For screening, structured data is a significant improvement — names, street, town and country arrive in separate fields instead of free-text lines — which allows more precise, field-aware matching. It also brings more data to screen and new failure modes: information truncated when converted from older formats, and fields that are populated inconsistently by different senders. Screening rules tuned for MT messages need re-testing against ISO 20022 traffic rather than assuming like-for-like behaviour.

FATF's Revised Recommendation 16

In June 2025 FATF adopted a revised Recommendation 16, renamed "Payment Transparency". The revision extends the standard beyond traditional wire transfers to payments and value transfers more broadly, and standardises the information that must travel with cross-border payments above USD/EUR 1,000 — including the originator's name, address or other identifying details, and beneficiary details — in structured form. FATF expects implementation by the end of 2030.

For payment screening, the effect is better inputs: more complete and better structured party data should mean fewer unresolvable alerts and fewer payments held for information requests. Firms should plan their screening upgrades alongside their ISO 20022 and R.16 data work rather than separately.

Reducing False Positives in Payment Screening

Because every payment is screened, a small false-positive rate creates large alert volumes. Effective programmes use:

  • Field-aware matching, applying different rules to names, addresses, countries and free text.
  • Calibrated fuzzy-matching thresholds, tested against known variants, transliterations and list samples.
  • Secondary identifiers — date of birth, nationality, BIC or registration numbers — to discount matches automatically.
  • Controlled good-guy lists for recurring confirmed false positives, with expiry dates and periodic review.
  • List scoping — screening against the lists that actually apply to the firm, not every list available.

Our guide to reducing false positives covers tuning methodology in more depth.

What Regulators Expect

  • Coverage — every payment type and channel is screened, including instant payments, and the lists used match the firm's sanctions exposure.
  • Timely list updates — new designations are live in the screening engine quickly, with evidence of when each update was applied.
  • Documented tuning and testing — matching thresholds are justified, tested and periodically re-validated.
  • Decision quality — releases are explained, escalations are timely, and blocking and reporting obligations are met.
  • Governance — management information on alert volumes, backlogs and true-match rates reaches senior management.

Correspondent banks add their own expectations; see our guide to correspondent banking due diligence.

Frequently Asked Questions

What is payment screening?

Payment screening checks the parties, banks, countries and free-text details in a payment against sanctions lists before the payment is executed, so a prohibited payment can be held, rejected or blocked.

What is the difference between payment screening and transaction monitoring?

Payment screening checks each payment against sanctions lists before it is processed. Transaction monitoring analyses patterns of activity — usually after the fact — to detect suspicious behaviour such as structuring or layering.

What is the difference between payment screening and customer screening?

Customer screening checks your own customers and their owners at onboarding and periodically. Payment screening checks every payment, including counterparties and banks you have no relationship with.

Does ISO 20022 change payment screening?

Yes. ISO 20022 messages carry structured party data in separate fields, which enables more precise matching, but screening rules built for legacy MT messages need re-testing against the new formats.

What does FATF Recommendation 16 require?

The June 2025 revision, now titled Payment Transparency, requires standardised and structured originator and beneficiary information to travel with cross-border payments above USD/EUR 1,000, with implementation expected by the end of 2030.

Screen Payments in Real Time, With Fewer False Positives

One Constellation screens every customer, and the counterparties on every transaction, in real time against OFAC, UN, EU, UK HMT, MAS and other sanctions lists — with a full audit trail for every decision.

← Sanctions List Screening Sanctions Evasion Red Flags → All Articles
Scroll to Top