TL;DR: Payment screening compares the parties, banks, identifiers, locations, and free text inside a payment message with sanctions lists before value moves. A cleared customer file does not clear the wire. SWIFT, citing industry figures, reports that 5 to 10 percent of payments generate an alert and that 99 percent of those alerts are false positives, which is why the control has to be precise about fields and strict about what a person still has to hold.
The Screen Runs on the Payment, Not the Customer File
Payment screening is the check of a payment instruction against sanctions lists and location indicators, while the institution can still stop the funds. The Wolfsberg Group's sanctions screening guidance treats this as a different control from customer or name screening. Customer screening looks for listed people and entities at onboarding and through the life of the relationship. Payment screening looks for listed parties, banks, and places inside a movement of value.
A customer who cleared onboarding can still send a wire to a blocked beneficiary, route it through a sanctioned intermediary, or place an embargoed city in the payment details. Name screening never sees that message. Comparing one name with a list entry is its own discipline, covered in sanctions screening name matching.
The instruction may be a wire, an ACH payment, including international ACH, a SWIFT message, or an instant payment. Cross-border SWIFT traffic now uses ISO 20022, such as pacs.008. The object is the instruction, not the customer master file.
What the Message Actually Contains
Wolfsberg sets the inventory. The screen reads parties, banks and their codes, free text, and geography. Purpose text sat in SWIFT Field 70 and now sits in ISO 20022 remittance information. Trade payments add vessels and International Maritime Organization numbers. A security identifier matters when a sectoral program targets the instrument.
Wolfsberg notes that amounts, value dates, and payment references offer little sanctions mitigation through screening. They stay out of the list match.
Legacy MT messages pack a name, an account, and an address into one line. ISO 20022 splits them into tags, including BIC and Legal Entity Identifier fields that match exactly. SWIFT's discussion of ISO 20022 and financial crime controls shows the collisions: Cuba inside a beneficiary line that also holds a street, the Dubai company Qanawat against the Iranian city Qanavat, and Valencia in Spain against Valencia in Venezuela. Separate tags let a country code match exactly and a name match approximately.
SWIFT ended MT and ISO 20022 coexistence for cross-border payment instructions on 22 November 2025. The November 2026 CBPR+ release retires unstructured postal addresses on those messages. Fully structured or hybrid addresses remain, while camt.052, camt.053, and camt.054 may still carry an unstructured address. Converting a rich ISO 20022 instruction into MT can drop party data, and a filter that sees only the thinned message is screening a different payment.
Which Lists, and What a Hit Means
The list set follows the institution's obligations, not a single file. For U.S. persons that means OFAC's Specially Designated Nationals and Blocked Persons List and the non-SDN consolidated lists, including sectoral identifications. What a blocking entry requires, as distinct from a sectoral one, is covered in the OFAC SDN List. Institutions with correspondent exposure also screen UN and EU lists, plus any local list the license requires.
OFAC's FAQ on validating a list match says to start with which list fired. A weak alias may be excluded as a documented risk decision. An address match on its own is a weak basis for a block, because unrelated businesses can share a building. A name plus a date of birth, or an entity name plus a location, should not be cleared inside the filter.
Two exposures never appear as a name on a file. Under OFAC's 50 Percent Rule, an entity owned 50 percent or more by blocked persons is itself blocked even when its name is absent from the SDN List. Ownership analysis is what surfaces that exposure. A country program can prohibit a payment when nobody in the message is listed. FATF Recommendations 6 and 7, as amended through June 2026, require countries to freeze designated persons' funds without delay and to keep funds from being made available to them, so a list update has to reach the filter before the next release.
OFAC's 2019 Framework for OFAC Compliance Commitments names the filter failures behind enforcement actions: software not updated for SDN or sectoral changes, BICs of designated banks missing from the list load, and alternative spellings of prohibited places ignored.
Real Time Where the Payment Can Still Be Stopped
The check has to land while the institution can still refuse the payment. Wolfsberg places it before any commitment to execute, and again if party data changes before release. Real-time screening of cross-border payments is described there as common practice, because a hit is still actionable. A domestic payment between institutions that onboarded the customer under the same sanctions regime can be a weaker candidate for a second pass on every item. A dollar payment that will touch a U.S. correspondent is an OFAC question even when both customers are local.
OFAC's September 2022 guidance on instant payment systems leaves the design to each bank's risk: geography, customer and counterparty history, and the rail. Speed is not a reason to release an unreviewed payment, or to block every alert the bank cannot adjudicate. Exception processing pulls one payment out of the automated flow long enough to investigate. Without a way to request a missing identifier from the other bank, the choice is to release without the facts or to hold the queue.
Batch covers a different gap. After a designation lands, standing beneficiaries, templates, and the prior ACH file need a sweep against the new names. That sweep does not replace the pre-release check on the next cross-border wire. An ACH file screened before release is real time relative to settlement and batch relative to each item.
False Positives Are a Field Problem
SWIFT, citing industry figures, reports that 5 to 10 percent of payments generate an alert and that 99 percent of those alerts are false positives. The pause is a person deciding whether a city, a bank, or a beneficiary is the listed party.
Finansinspektionen, the Swedish financial supervisory authority, showed in its 2024 analysis of bank sanctions screening why a high detection rate and a full queue can both be true. Transaction screening identified, on average, 96.1 percent of list names spelled as published, with a median of 98.2 percent. When the spellings in the test were altered, average detection fell to 88.4 percent, with a median of 92.4 percent.
The extra alerts come from the message: a street named for a sanctioned city, a purpose line that names a place, a bank legal name that fuzzy-matches a listed individual, a truncated legacy name against a short alias. The message may carry no date of birth, country, or BIC, so the analyst requests them and the payment waits. That cycle is one reason screening alerts pile up.
SWIFT estimates that targeted screening of structured ISO 20022 data could reduce false positives by 25 to 30 percent, because a name is no longer scored against a vessel and a street is no longer scored against an embargoed city. The estimate assumes the tags are filled. What actually reduces false positives starts with a sample by field: which alerts a second identifier would have closed, and which had none.
What a Person Still Has to Hold
A similarity score does not close an alert. OFAC's match FAQ allows the payment to proceed when the similarities are few and the institution can reasonably determine the match is not valid, such as one shared name token with a conflicting date of birth and country.
Several patterns stay with a person:
- A close name match with a second identifier that agrees, such as a date of birth or a location.
- An exact BIC for a designated bank, or a structured country code for a comprehensively sanctioned jurisdiction.
- A sectoral alert where the message shows the party or the prohibited activity, but not both.
- A hit that cannot be disqualified because the message lacks the identifier that would separate the parties.
- A payment that may proceed only under a general license or a specific exemption.
- A beneficiary that may be blocked under the 50 Percent Rule even though the name is not on the list.
The note names the list, the field, the identifiers compared, and why the payment is blocked, rejected, or released. Releasing to protect a cutoff, and blocking every alert to avoid a decision, are the two outcomes OFAC's instant-payment guidance is written to prevent.
Where Sphinx Fits
Sphinx reviews payment screening alerts inside the systems analysts already use. Agents compare the field that fired with the list record and document the disposition. Across production deployments, Sphinx reports 87 percent fewer false positives and an 80 percent reduction in case review time. Matches that meet the hold criteria above stay with a person.
Frequently Asked Questions
What is the difference between payment screening and customer name screening?
Customer name screening compares the people and entities on a relationship with sanctions lists at onboarding and on a periodic cycle. Payment screening compares the parties, banks, identifiers, locations, and free text inside a specific payment before the funds move. A customer who passed onboarding can still send a payment that has to be stopped.
Which parts of a wire or SWIFT message should be screened?
Screen originator and beneficiary names and addresses, ultimate parties, intermediary banks, BICs, remittance text, and geography such as cities, countries, and ports. Amounts, value dates, and payment references do not identify a sanctioned party. Match ISO 20022 tags by type: fuzzy logic for names and free text, exact logic for BICs, Legal Entity Identifiers, and country codes.
Does every payment have to be screened in real time?
Cross-border payments are screened before release, because that is when a hit can still be stopped. Domestic payments under the same sanctions regime may go out on a risk-based schedule, including a batch screen of the file. A new designation still requires a sweep of templates and recent payments, and an instant rail needs a way to pull one payment out for review.
Why do payment screening alerts have such a high false-positive rate?
SWIFT, citing industry figures, says 5 to 10 percent of payments alert and that 99 percent of those alerts are false positives. Unstructured fields mix names with street and city text, so a place name collides with an embargo. SWIFT estimates that structured ISO 20022 data can cut that noise by 25 to 30 percent when the tags are filled.
When should a payment screening alert stay on human hold?
Hold the payment when a second identifier agrees with the list entry, when a BIC or country code is an exact sanctions hit, when the data needed to rule the hit out is missing, or when a license or an ownership question decides the outcome. A single shared name token with a conflicting date of birth and country can be cleared, and the comparison should be on the file.
.png)
