Screening at onboarding is not screening at payment
Most firms I review have a customer screening engine and a payment screening engine, and assume that between them the job is done. The two screens ask different questions of different data at different moments, and the gap between them is where designated parties travel. This note is about what each one can and cannot see, and what to do when a payment fires a match you cannot resolve either way.
Two screens, two different questions
Customer screening asks: is this person or entity, as recorded in our records, a match to a listed party? It runs against structured fields you control — legal name, date of birth, registered number, address, nationality. You chose the format. You can enrich it. If the match is uncertain you can go back to the customer and ask.
Payment screening asks something narrower and messier: does anything in this message, as it arrived, resemble a listed party, a listed vessel, a listed country or a restricted goods term? It runs against fields you did not populate, written by someone in another institution, possibly truncated, possibly transliterated, possibly dumped into a free-text block because the originating system had nowhere else to put it.
Those are not the same exercise, and a firm running only one of them has a hole it can usually describe but rarely size. I have sat in reviews where the head of compliance said, with complete sincerity, "we screen every customer at onboarding and every year after" — and the firm had no screening on the beneficiary of outbound payments at all. Every counterparty their book paid was unscreened. Nobody had noticed, because no alert had ever been generated to notice.
Onboarding screening is a photograph, not a feed
The first failure mode is temporal. You screened a customer in January against the lists as they stood in January. Designations are added continuously. If your ongoing screening cadence is annual, there is a window of up to twelve months in which a customer can be designated and you will not know.
Payment screening partially covers this, because it runs against current lists at the moment of execution. That is a real control benefit and it is why I push back hard when someone proposes suppressing payment screening for "known, already-screened customers". The customer was known. The list has changed.
The second failure mode is scope. Customer screening covers parties in your customer record: the account holder, the directors you captured, the beneficial owners you identified. It does not cover the person they are paying, the intermediary bank in the chain, the vessel named in the payment reference, or the ultimate beneficiary behind a nested arrangement. Where a respondent bank's own customers move through your rails, that exposure sits outside your customer file entirely — the nested correspondent relationship is exactly the structure that defeats customer-level screening.
What the message carries, and what it loses
Payment screening is only as good as the data in the message, and payment messages lose information at every hop.
Field length limits truncate names. Transliteration from Cyrillic, Arabic or Chinese script produces variants that your fuzzy logic may or may not bridge. Conversion between message formats — a domestic scheme into a cross-border format, a legacy MT message into ISO 20022 — can drop address data or collapse structured fields into unstructured ones. The Wolfsberg Group has published extensively on payment transparency and the quality of originator and beneficiary information for precisely this reason; it is worth reading their material at the Wolfsberg Group alongside your own message specifications.
Then there is the free-text problem. Payment references, remittance information and "further credit to" instructions are where real-world detail hides. I have seen a designated entity's name appear nowhere in the beneficiary name field and perfectly clearly in field 70, because the payer wrote the invoice reference as the counterparty's trading name. A firm that screens only structured name fields will miss that every single time. A firm that screens free text will generate a lot of noise and catch it.
Noise is the price. I would rather tune a reference-field rule down than switch it off, and the discipline for doing that without destroying the control is the same discipline you would apply to tuning a monitoring rule: change one variable, measure what you lost, document the rationale.
Who is responsible for screening what
A cross-border payment can touch four or five institutions. Each one has its own obligations under its own regime, and the common error is assuming someone upstream has already done the work.
For a firm in the United Kingdom, financial sanctions obligations flow from the regulations administered by OFSI, and they attach to the person who holds or deals with the funds or economic resources. An intermediary bank processing a payment is dealing with those funds. The fact that the originating bank screened its customer does not transfer the duty. A United States nexus — dollar clearing, US persons, US-origin goods — brings OFAC requirements into the same transaction, and those are not identical in scope or effect. Name the regime before you reason about the duty. "Sanctions say we must freeze" is not an analysis.
Ownership adds another layer that customer screening handles poorly at payment speed. A beneficiary entity may not itself be designated while being controlled by someone who is; the mechanics of that, and why firms get it wrong, are set out in the note on the fifty per cent ownership rule.
When you cannot prove it either way
Case note
A UK payment institution onboarded a sole trader in April 2023. Name screening at onboarding returned no hits. In February 2025 the customer instructed a one-off outbound payment of £62,400 to a supplier in the UAE — their first international transfer, against a profile of domestic receipts averaging about £8,000 a month over twenty-two months. Payment screening fired a 91 per cent match between the originator name and an individual designated under the UK's Russia regulations in November 2024, nine months after onboarding and seven months before the firm's next scheduled annual rescreen.
The customer file held a name, a residential address in Greater Manchester, a mobile number and a passport image captured at onboarding. The list entry carried a name, a year of birth of 1979 and two transliteration variants. No date of birth on the list beyond the year. No place of birth. No passport number on either side that could be compared. The customer's passport showed a date of birth in 1979. The analyst's first draft disposition read "partial name match — clear false positive, no further action". It was returned.
What the firm actually did: placed an internal review hold on the payment, which was neither a freeze nor a rejection; requested the beneficiary invoice and the supplier relationship history; checked the passport's issuing country against the nationality on the list entry; and escalated to the MLRO within the four working hours the firm's own procedure allowed. The nationality on the passport differed from both nationalities on the list entry, and the issuing authority was verifiable. That discriminator — not the absence of data — supported the clearance. Elapsed time from alert to release: eleven working hours.
The point of that scenario is the returned draft. "No identifiers available to confirm, therefore false positive" inverts the logic. Missing data is not exculpatory evidence; it is missing data. An evidenced false positive means you found a discriminator that is inconsistent with the listed party — a verified nationality, a date of birth that cannot be reconciled, a corporate registration predating the entity's existence. An unresolved potential match means you looked and could not find one, and that is a different disposition with a different escalation path.
I am not going to rehearse the discriminator hierarchy here, because it already exists in the note on clearing a partial name match, which sets out what counts as a discriminator and how to write the clearance rationale so it survives a file review two years later. Read that one alongside this.
Three states that are not interchangeable
An internal review hold is a firm-level operational pause while you gather information. It is not a legal measure, it has no reporting consequence in itself, and it should have a defined maximum duration in your procedure, because an indefinite hold is a decision you have made by not making it.
Rejection returns the payment and ends your involvement, which may be the right commercial answer and is not the same as a freeze — rejecting does not report anything to anyone unless your regime requires it.
An asset freeze is a legal consequence of a confirmed match to a designated party, carries reporting duties to the relevant competent authority, and is not something an analyst decides alone at eleven at night.
Whether you tell the customer anything, and what you may lawfully say, depends on the regime and on whether a disclosure has been or will be made. That is a question for your MLRO and in some cases for counsel. It is not a default behaviour.
What adequate coverage looks like across the three moments
I assess screening coverage as three connected controls rather than one. At onboarding, you screen a customer record you control, against the lists of that day, with the ability to ask the customer questions. Ongoing, you rescreen the standing book whenever list changes land — and the gap between your cadence and real time is a risk you should have quantified in your business-wide risk assessment rather than discovered in a regulatory visit. At payment, you screen what the message actually contains, including the fields you would rather ignore.
The record matters as much as the screen. For every alert, I want to see what fired, what the matched list entry said, which discriminators were examined, which were unavailable, who decided, when, and on what basis. "False positive" on its own is not a record; it is a word. FATF standards and the expectations the FCA sets out for UK firms both turn on demonstrable judgement, and judgement that was never written down cannot be demonstrated.
One last thing I say to every new analyst. A screening hit is the output of a string comparison. It carries no suggestion that the person in front of you has done anything at all. Treat it as arithmetic you now have to resolve, write down honestly what you found and what you could not find, and escalate the ones that stay unresolved. That posture — curious, documented, unembarrassed about saying "I cannot clear this" — is worth more than any tuning parameter.
Takeaway: Customer screening tells you who your customer was when you looked; payment screening tells you what is in the message now, and a firm that cannot evidence both has a gap it has simply never generated an alert to see.
