How sanctioned party screening is set up in finance and ERP systems

Sanctioned party screening usually runs as a check inside the ERP or in a trade compliance tool connected to it. Partner records are screened when they are created or edited. Orders and payments are screened again before release. Anything resembling a listed name is blocked until a named reviewer clears it.

Where the check sits

Most organisations do not build screening logic themselves. They license list content from a data provider and run it through one of two setups. Some use a screening engine built into the ERP. Others use a separate compliance application that the ERP calls through an interface. The second setup is common where several ERPs feed one compliance team. It is also common where the business wants one audit trail across sales, purchasing and treasury.

Whichever setup is chosen, the ERP remains the place where the block is enforced. The screening tool decides whether something looks risky. The ERP is what stops the delivery, the purchase order or the payment run.

What gets screened, and when

The master data check is the foundation. Customers, suppliers, banks, employees paid through payroll and one-time vendors are all candidates. A good configuration triggers a fresh check whenever a name, address or country field changes, not only at creation.

Transaction screening adds a second layer. Sales orders and deliveries are typical trigger points. So are purchase orders and outgoing payments. On the payment side, the check usually fires when the payment proposal is built. It fires again before the file goes to the bank. Foreign payments deserve particular care, because the beneficiary bank and any intermediary bank can be the sanctioned element even when the supplier is clean.

There is also periodic rescreening. Lists change constantly. A supplier who was clean last quarter may be listed today. Batch jobs rerun the whole partner base against updated lists, often overnight, and raise new alerts for anything that now matches.

How matches are scored

Screening engines rarely look for exact matches. They use fuzzy logic to catch spelling variants, transliterations, reordered names and abbreviations. Each comparison returns a score. A threshold decides what becomes an alert.

Setting that threshold is a judgement call. Too strict and genuine hits slip through. Too loose and reviewers drown in false positives, start clearing alerts on autopilot and miss the real one. Most teams also maintain a good guy list, sometimes called an allow list. It records partners already reviewed and cleared, so the same false match does not reappear every night. That list needs its own controls, because an entry on it silences future alerts.

Blocks, holds and release

When a possible match is raised, the ERP places a block. On master data this usually prevents any posting to the partner. On documents it stops the specific order, delivery or invoice. In accounts payable, the effect resembles any other failed validation: the payment request is held and excluded from the run until it is resolved.

Release should require a decision recorded in the system, with a reason and the reviewer's identity. Confirmed matches go to legal or compliance for escalation and, where required, reporting to the authorities. Cleared items return to normal processing. The segregation that matters here is between the person who can create or edit a vendor and the person who can release a screening block. In smaller teams those roles are often held by the same person without anyone noticing.

Keeping lists and data current

List updates are normally automated through the content provider. Someone still has to confirm each update actually loaded. A failed feed fails silently. Screening keeps running against an old list and nothing looks wrong.

Data quality limits everything. Partner names stuffed into address fields, missing countries and free-text one-time vendors all weaken matching. Many screening problems turn out to be master data problems.

Who owns what

Ownership is often split. IT owns the interface and batch jobs. The vendor master team owns data entry. Compliance owns thresholds, list selection and decisions on true matches. Finance owns the payment holds and how long items may sit before escalation. Unclear ownership between these groups is the most common reason alerts age without action.

Questions to ask the people who run it

• Which lists are switched on, and who decided that? When was the choice last reviewed?
• Is screening triggered on every change to a partner record, or only when the record is created?
• Do one-time vendors and manual payments go through the same check as regular suppliers?
• Are beneficiary banks and intermediary banks screened, or only the payee name?
• What happens to the payment run when an alert is open? Is the item held, or does someone release it to meet a deadline?
• Who can add a partner to the allow list, and does anyone review those entries?
• How would anyone know if last night's list update failed?
• When a reviewer clears an alert, what evidence is recorded beyond a click?
• Are there workarounds, such as paying through a different entity or a manual bank transfer, when a block gets in the way?
• Which alerts are routinely cleared without investigation, and why does the team trust that pattern?

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.