How to Evaluate Customer and Entity Screening Platforms

Two people can share a name and have nothing else in common. A screening platform earns its place by helping an investigator establish that difference without missing material risk. The buying decision therefore turns on data, matching, context, workflow, and control governance—not the number of lists printed on a sales slide.

This guide covers customer and entity screening during onboarding and throughout a relationship. It may include sanctions, politically exposed person (PEP), and adverse-media risk. It is distinct from payment screening, which evaluates parties and terms in a transaction while the payment is moving. The Wolfsberg sanctions guidance makes the same customer-versus-transaction distinction and treats both as parts of a wider financial-crime compliance program.

Decision context

Start with the control objective. Identify which people, legal entities, beneficial owners, directors, counterparties, or related parties must be screened; against which risk domains; at which events; and in which jurisdictions. State the required result for an alert: reject, pause, escalate, investigate, rescreen, or document a decision under policy.

Map the current failure before selecting a replacement. Common problems include incomplete customer data, slow list updates, opaque matching, duplicate alerts, weak segmentation, inconsistent disposition reasons, or no reliable link between a list record and the decision evidence. A high alert count alone does not diagnose the cause. It could reflect poor source data, broad configuration, genuine exposure, duplicate list records, or an operating process that repeatedly reopens the same case.

Define the scope of PEP and adverse-media work separately from sanctions. PEP status is not a sanctions designation or proof of wrongdoing. FATF’s PEP guidance ties PEP controls to risk management and effective customer due diligence. The FCA’s Financial Crime Guide includes press reports and court judgments among sources of money-laundering risk information and warns against disregarding sustained criminal allegations from reputable sources. This supports treating some public reporting as a risk input, not a legal designation or a regulator-prescribed product workflow. Source, subject, allegation, recency, and credibility are editorial evaluation criteria for the adverse-media portion of this guide. A single threshold should not silently collapse these three decisions.

Requirements checklist

Reference data

The following source-lineage, deduplication, correction, and workflow checks are editorial procurement guidance. The cited authorities do not mandate one technical design.

Identify every sanctions, PEP, relative and close associate, enforcement, internal, and adverse-media source in scope.
Require source lineage, publication or retrieval time, update processing time, correction handling, and record history.
Preserve stable identifiers when the source provides them.
Show names, aliases, scripts, dates of birth, locations, nationalities, identifiers, entity type, ownership links, source labels, and program information without merging conflicting values invisibly.
Define deduplication rules and show which source records contributed to a consolidated profile.

Customer and entity input

Support the scripts, languages, entity types, and identifiers used by the institution.
Screen beneficial owners, controllers, directors, and other related parties according to policy.
Detect missing or malformed fields before screening.
Retain the submitted value and normalized value so investigators can reconstruct matching.
Define what triggers rescreening: list change, customer-data change, risk event, periodic schedule, or manual request.

Matching and decisions

Configure name similarity, aliases, transliteration, token order, initials, dates, geography, entity type, and identifiers by risk domain and population.
Explain why a candidate was produced and which fields supported or contradicted it.
Allow distinct thresholds and workflows for sanctions, PEP, and adverse media.
Record list version, customer-data version, matching configuration, candidate, disposition, reason, reviewer, and timestamps.
Reuse prior decisions only under controlled rules that respond to material record changes.

Workflow and oversight

Separate initial triage, investigation, escalation, approval, and quality assurance.
Provide queue ownership, aging, priority, conflict checks, and absence coverage.
Report volumes and outcomes by source, segment, threshold, risk domain, and change event.
Restrict configuration and disposition permissions by role.
Export decision evidence in a durable, readable form.

Evidence to request

Request current source inventories and sample records rather than accepting a list count. Ask how the provider handles deleted records, corrected dates, source conflicts, duplicate identities, aliases, non-Latin scripts, corporate hierarchies, and ownership data. Obtain update-time evidence over a defined period, including delayed and failed updates.

For matching, request a plain-language design description, configurable fields, normalization steps, transliteration method, threshold behavior, and known limitations. OFAC’s match-review FAQ directs users to compare entity type, the full name, address, nationality, passport or tax identifiers, place and date of birth, former names, and aliases. That official example supports a field-by-field review; it does not endorse a particular algorithm or score.

Ask for audit samples showing a configuration change from proposal through approval, testing, release, and rollback. Request evidence that source updates are reconciled and that all in-scope customers were processed. The FCA’s sanctions screening guidance asks whether tools are calibrated for the firm’s needs, lists are updated, rescreening is effective, and third-party solutions receive oversight.

Proof-of-concept test plan

Build labelled test packs for people and entities. Include exact names, common names, reordered tokens, initials, aliases, transliterations, spelling errors, missing dates, conflicting locations, former names, corporate suffixes, nested ownership, and records that should not match. Include genuine list records from official sources where permitted, but do not treat one public list as the whole screening requirement.

Run these tests:

Ingestion and lineage. Load customer and reference data. Reconcile counts and inspect normalization, rejected records, source timestamps, and identifiers.
Candidate generation. Measure outcomes across risk domains and customer segments. Preserve the labelled set and configuration version.
Investigation. Give investigators only the information the production workflow would provide. Measure whether they can reach and explain the expected disposition.
Updates. Add, amend, and remove reference records. Confirm affected customers are identified, prior decisions are reconsidered under policy, and update failures surface.
Configuration. Change one threshold or matching field through the governed path. Compare results, approve the change, deploy it, and roll it back.
Scale and resilience. Run expected daily and peak volumes, interrupt a data feed, and verify recovery and reconciliation.

Report recall and precision only where the labelled set supports those calculations. Show counts and confidence limits when appropriate. Include investigation time, repeat-alert rate, queue growth, update latency, unresolved errors, and evidence completeness. Results on a curated test pack do not predict every production name or data condition.

Commercial and implementation questions

Clarify whether prices depend on profiles, screened records, rescreening events, API calls, data domains, source packages, users, or adverse-media documents. Ask whether test environments, historical rescreening, batch correction, implementation, model tuning, list additions, and audit exports cost extra. Model a major list update and a full-population rescreen, not only steady-state usage.

Implementation ownership needs named answers:

Who maps and improves incomplete customer fields?
Who sets thresholds and accepts residual risk?
Who validates source coverage for each jurisdiction?
Who approves reusable prior decisions?
Who resolves data conflicts and list-provider corrections?
Who monitors update failures and proves population completeness?
How will open alerts, decision history, and internal watchlists migrate?
What happens to data, configuration, and evidence at exit?

Red flags

Treat a single unexplained “match score” as a warning. The same applies when a supplier cannot show source provenance, hides normalization, equates PEP status with wrongdoing, presents adverse-media sentiment as a final decision, or cannot reproduce an alert after data changes. Be cautious when a demonstration excludes common-name cases, non-Latin scripts, entities, and updates.

A promised reduction in false positives is not transferable without the population, baseline, settings, and definition used to calculate it. Ask for the numerator, denominator, exclusions, test period, and whether missed relevant matches were assessed.

Procurement implications and limitations

Evaluate reference data and software separately, even when sold together. A strong workflow cannot repair missing source records; rich reference data cannot repair incomplete customer input or uncontrolled matching. Allocate scores to data lineage, match quality, explanation, update control, workflow, auditability, operations, security, implementation, and cost. Make unresolved evidence a visible decision risk.

No proof of concept establishes legal compliance. Sanctions obligations, PEP measures, and the use of public information differ across jurisdictions and institutional policies. Official lists change, adverse-media sources can be wrong, and labelled test packs are incomplete. The approval record should state the source scope, accepted limitations, validation plan, rescreening controls, operational staffing, and the people accountable for ongoing calibration and oversight.