Sanctions screening that stops at vendor onboarding

The most common failure is screening a party once, at setup, and never again. Lists change and vendor records change, but payments keep flowing to names nobody has rechecked. It surfaces through a bank rejection or an audit sample. The fix is screening on every change and again before release.

How it starts

Most screening programmes are built around onboarding. A new supplier or customer is entered and checked against the restricted party lists. If clean, the record is approved, and from then on it is treated as trusted.

The trouble is that both sides of the match keep moving. Governments add names, sometimes with little notice. Meanwhile the vendor record drifts. A new remit-to address appears. Bank details are swapped for an account in another country. An ownership change happens that nobody in procurement hears about. None of these edits sends the record back through screening, because the trigger was only ever wired to creation.

Payment teams rarely see this as their problem. Their job is to match the invoice to the order and the receipt, route it for approval and get it paid on time. Once a vendor is in the master file, the payment run assumes someone upstream has already done the sanctions work. Foreign payments make it worse. The currency conversion and the beneficiary bank are often set at the point of payment, which is exactly where no check sits.

A quieter version starts with alert fatigue. Fuzzy matching throws up many near misses on common names. Reviewers learn that almost all of them are false. Over time they clear alerts in bulk, or someone adds a broad allow rule to stop the noise. The genuine hit then sails through with the rest.

How it gets spotted

Rarely by the screening tool itself. The usual signal comes from outside. A correspondent bank holds or returns a wire and asks for information about the beneficiary. A freight forwarder refuses a shipment. An internal auditor pulls a sample of paid vendors, runs them against the current list, and finds a match that was clean at onboarding.

There are earlier signs for anyone willing to look. Vendor master change logs show bank and address edits with no matching screening record. The screening system reports show a burst of activity when vendors are created and almost nothing afterward. Alert queues are cleared suspiciously fast, with identical disposition notes. Payment holds for sanctions reasons are almost never seen in the accounts payable exception queue, which in a business with foreign suppliers is itself a warning.

Fixing it

Start by rescreening the whole active population against the current lists. That gives a clean baseline and shows how large the exposure really is. Any true match goes to compliance and legal before anything else moves; payments to that party stop while it is assessed.

Then change the triggers. Screening should fire whenever the list provider publishes an update, run against every active party, not just new ones. It should also fire on any edit to name, address, bank account, country or ownership fields in the vendor or customer master. Those edits should not become effective until the check is clear.

Add a check at payment release. Before payment transactions are generated, the beneficiary name, bank and country on the actual payment file are compared to the lists. A hit places the payment on hold through the same route used for payments that fail validation, so it lands with someone who can resolve it and is visible in the exception reports. For foreign payments, screen after the beneficiary bank is known, not before.

Tune the matching instead of muting it. Use secondary identifiers such as date of birth, registration number or country to cut false positives. Remove blanket allow rules. Require a reason on every cleared alert, and have a second reviewer sample those dispositions. Fold sanctions holds into the regular payment audit so that cleared and released items are tested along with everything else.

Finally, give someone ownership of the list feed. When the provider changes format or the connection fails, screening silently runs against an old list. A monitor that alerts on a missed update closes that gap.

Questions to ask the people who run it

• When a vendor's bank details change, what happens between the request and the first payment to the new account?
• Which list version is the screening tool using right now, and how would anyone know if it stopped updating?
• Are there vendors or customers that skip screening, such as one-time payees, employees paid as suppliers, or grant recipients?
• When an alert appears, what do reviewers actually check before clearing it?
• Have any allow rules or exclusions been added to reduce alert volume, and who approved them?
• Does the payment file sent to the bank get screened, or only the master record behind it?
• When a bank returns a payment for sanctions reasons, who hears about it, and does the vendor record get flagged?
• If a party became listed today, which payments already in the run would still go out?

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.