How to Choose PEP Screening Software: Buyer and POC Checklist

Choosing PEP screening software is not a search for the largest database or the most confident marketing claim. It is a procurement decision about whether a supplier's data and workflows can implement the PEP control your organisation has defined.

This guide assumes that you already understand the underlying screening process. If you need the definitions, investigation steps, risk assessment and monitoring background, start with the practical PEP screening guide. Here, the question is narrower:

What evidence should a buyer demand, and how should the organisation test whether the software can support its PEP policy?

The buying sequence is:

Define the perimeter → inspect the data → test representative identities and relationships → assess workflow evidence → test change and failure → compare suppliers.

Start with the PEP perimeter your firm must implement

Build a buyer-owned requirements matrix before asking vendors for demonstrations. A generic promise of “global PEP coverage” does not show whether a service fits the definitions, jurisdictions or customer population relevant to your firm.

FATF provides an international baseline for foreign, domestic and international-organisation PEPs, their family members and close associates. It also states that PEP requirements are preventive and should not be interpreted as implying criminal activity.¹

Binding duties arise through the framework applicable to the firm. For example, UK Regulation 35 requires relevant persons to use appropriate systems and procedures to determine whether a customer or beneficial owner is a PEP or a family member or known close associate, and then to apply the required risk-based measures.² Current UK rules distinguish domestic and non-domestic PEP treatment, while EU rules and national implementation create their own perimeter.³⁴

Software should help implement that perimeter. It should not silently define it for the buyer.

Inspect the PEP record, not the database-size claim

A useful PEP result should let a reviewer understand why the profile may be relevant. Ask the supplier to demonstrate real records and the evidence fields exposed through each delivery method.

“Comprehensive” is not a testable requirement. Ask which public functions and jurisdictions are represented, what sources support the record, how the vendor handles corrections, and which fields are available to your reviewers and integrations.

Verify role classification and jurisdiction mapping

PEP status arises from a qualifying prominent public function or defined relationship, not from a generic label. The software should expose enough context for the firm to apply the relevant definition.

Test whether a vendor can distinguish:

• domestic, foreign and international-organisation PEP categories;
• senior functions from junior or non-qualifying public employment;
• the country and institution connected to the role;
• current and former roles; and
• the vendor's data classification from the customer's final policy decision.

This matters because local rules differ. UK Regulation 35 and FCA guidance illustrate a UK-specific approach; current EU legislation requires jurisdiction-aware treatment, including Member State lists of exact prominent public functions.²⁵⁴ Do not accept a single global category map without testing it against the countries that matter to the business.

Procurement also needs a dated view of regulatory change. Regulation (EU) 2024/1624 introduces a new directly applicable EU AML framework, but as of September 2026 it generally applies from 10 July 2027.⁶ A buyer may test readiness for that change without describing the future framework as already generally applicable or ignoring current national implementation.

Verify relatives, close associates and relationship evidence

A result should show whether the subject is the direct PEP or a relative or close associate (RCA). It should also show the relationship and the evidence supporting it. An RCA should not simply inherit the principal's job title or appear as an unexplained “PEP = yes” record.

Ask:

• Which family and close-associate definitions does the dataset implement?
• Can the reviewer see the linked PEP and the relationship type?
• What source establishes the relationship, and when was it observed?
• How are additions, corrections and ended relationships represented?
• Can your policy treat uncertain relationship evidence differently from a confirmed relationship?

UK Regulation 35 contains specific definitions of family members and known close associates.² FATF also extends the relevant measures to family members and close associates, but implementation remains jurisdiction-specific.¹

Verify former roles and date history

Former-PEP treatment cannot be implemented reliably if the supplier provides no role dates or history. Ask vendors to show how a reviewer can see when a role ended, what the previous profile showed and what changed.

The software should preserve evidence without applying one unexplained global expiry rule. UK Regulation 35 requires specified treatment of a former PEP for at least 12 months and for longer where appropriate to address the continuing risk, but that UK rule is not a universal worldwide cutoff.² The firm—not a hidden vendor timer—must apply the relevant law and its assessment.

Test matching as identity resolution, not PEP confirmation

Matching creates candidates. It does not establish that a customer is the person in a PEP profile, that the role qualifies under the applicable definition, or that the relationship should be rejected.

A proof of concept should therefore include:

• exact names and known variants;
• reordered, abbreviated and incomplete names;
• authentic aliases;
• original-script and transliterated names relevant to the buyer's population;
• common names shared by several people;
• incomplete or approximate dates of birth; and
• records with matching and conflicting nationalities, locations or roles.

Observe both retrieval and resolution. A sensitive matcher may retrieve the expected profile but still create uncontrolled review volume. A narrow configuration may reduce candidates while missing relevant variants. There is no universal fuzzy threshold or acceptable false-positive rate.

For each case, capture why a candidate appeared, which identifiers supported or contradicted identity, what the reviewer concluded and what remained unresolved. The detailed PEP investigation process belongs in the practical PEP screening guide; the buyer's job here is to test whether the software provides enough evidence to perform it.

Preserve the distinction between status, risk and action

The product should not collapse several different decisions into one score:

PEP status is not sanctions status and does not prove wrongdoing. Adverse media may provide additional risk context, but it is not what establishes that a person holds a qualifying public function. For the category boundaries, see watchlist screening versus sanctions and PEP screening.

Test whether reviewers can preserve a confirmed PEP status while recording a proportionate, separate customer-risk outcome. FCA guidance for firms in its scope emphasises a proportionate, risk-based and case-by-case approach.⁵ Software can support that workflow; it should not manufacture the legal or customer decision.

Evaluate monitoring around real PEP changes

“Continuous monitoring” is meaningful only when the vendor can explain what changes are detected, how quickly they become available under the agreed service, and what the reviewer sees.

Ask the supplier to demonstrate or document what happens when:

• an existing customer assumes a qualifying public role;
• a PEP leaves office;
• a role title, institution or jurisdiction changes;
• a family or close-associate relationship is added or corrected;
• a source record is corrected or withdrawn; or
• the customer's identifying data changes.

The event should preserve the prior state, the new information, the reason for review and the eventual decision. Do not prescribe one global re-screening cadence or update interval: the buyer should define triggers under the applicable framework and verify that the service can implement and evidence them.

Check whether reviewers can reconstruct the decision

A convincing demonstration should continue from candidate retrieval through review. Ask another qualified reviewer to reconstruct a closed case using only retained evidence.

The record should show:

• the customer data supplied for screening;
• the returned PEP profile and source information available at the time;
• the matching configuration and timestamps;
• identity similarities and conflicts;
• public-role or RCA evidence and relevant dates;
• the reviewer, rationale, escalation and approval;
• the PEP classification, customer-risk outcome and final action as separate fields or decisions; and
• later changes and reopened review history.

FCA supervisory work has identified weak PEP/RCA definitions, ineffective reassessment and poorly explained risk rationales among reviewed firms.⁷ A case tool does not solve those governance problems by itself, but it should make controlled review and evidence possible.

Check portal, CSV and API fit

Delivery method and PEP-data quality are separate questions. Run selected cases through every workflow you expect to use.

For technical distinctions between screening APIs and behavioural transaction-monitoring APIs, use the transaction screening API versus sanctions and PEP API guide. Generic platform questions such as authentication, rate limits, security, availability and incident ownership should be verified in current documentation and contract rather than inferred from a marketing page.

Run a PEP-specific proof of concept

Agree the test records, expected observations and evaluation method before vendors see the results. Use buyer-owned cases that reflect the jurisdictions, scripts and data quality of the actual customer population.

Do not convert this table into one blended score. Record at least four outcomes separately:

1. Retrieval performance: did the expected candidate appear?
2. Resolution quality: was enough evidence available to resolve identity?
3. PEP-data quality: could the buyer understand the role, relationship, source and relevant dates?
4. Operational control: could the team review, evidence and recover from errors?

A practical comparison record is:

Requirement | Test record | Expected behaviour | Observed behaviour | Evidence | Missed result? | False candidate? | Unresolved? | Operational issue | Vendor explanation | Buyer assessment

Use evidence-backed ratings such as meets, partially meets, does not meet and not demonstrated. There is no universal pass threshold.

Compare suppliers with an evidence matrix

After the POC, compare what each vendor demonstrated rather than what each vendor promised.

PEP data

• Are relevant roles and jurisdictions represented with source evidence?
• Are direct PEPs and RCAs clearly distinguished?
• Are role and relationship dates visible where sources provide them?
• Can historical changes and corrections be reconstructed?
• Does the supplier explain gaps rather than calling every field complete?

Matching and review

• Did expected variants appear across relevant scripts and data-quality conditions?
• Could reviewers resolve common names using secondary identifiers?
• Were misses, irrelevant candidates and unresolved identities measured separately?
• Can configuration changes be versioned, approved and regression-tested?

Monitoring and evidence

• Which political-role, relationship, source or customer changes create review work?
• Can a reviewer understand what changed and why?
• Can another person reconstruct the classification, risk rationale, approval and action?
• Are prior decisions revisited when relevant facts change?

Integration and operations

• Do the portal, CSV and API paths support the intended operating model?
• Are errors, partial failures, retries and reconciliation documented?
• Can the buyer detect source or processing failures?
• Are implementation, support, change-management and incident duties assigned?

For generic screening-platform procurement questions, see how to choose sanctions screening software. Apply those controls without copying sanctions-specific legal or data assumptions into the PEP decision.

Where Checklynx fits

Checklynx supports PEP screening through its screening portal, CSV batch screening and real-time screening API, with ongoing monitoring, case management and audit evidence workflows. These capabilities help teams execute and document their approved control. The customer remains responsible for its applicable perimeter, policy, classification, risk assessment and final relationship decisions.

Frequently asked questions

What should buyers look for in PEP screening software?

Look for fit with the firm's legal perimeter, transparent role and relationship evidence, usable identity data, controlled matching, change monitoring, review workflows and reconstructable decisions. Verify those points with representative buyer-owned cases rather than a feature checklist alone.

Is the largest PEP database automatically the best?

No. A record count does not establish whether the relevant jurisdictions and roles are covered, whether the records are current and traceable, or whether reviewers receive enough information to resolve identities and relationships.

Does a PEP match mean the customer is high risk?

No. A candidate must first be resolved to the correct identity and classified under the applicable framework. Confirmed PEP status is then one input into a proportionate customer-risk assessment; it is not evidence of criminality or an automatic rejection decision.

Can a commercial PEP database satisfy compliance requirements by itself?

No. FATF says commercial and other external databases can assist but are neither required by FATF nor sufficient by themselves.¹ The firm still needs appropriate scope, review, risk assessment, approvals, controls and evidence under its applicable framework.

How should PEP screening software be tested?

Use representative direct PEPs, RCAs, former roles, common names, transliterations, incomplete identities, expected non-matches and political-role changes. Report retrieval, resolution quality, PEP-data quality and operational behaviour separately.

Is one former-PEP period valid worldwide?

No. Continuing treatment depends on the applicable jurisdiction and risk. UK Regulation 35, for example, specifies at least 12 months for a former PEP and longer where appropriate, but that should not be presented as a global rule.²

Is PEP screening the same as sanctions screening or adverse-media screening?

No. PEP screening identifies relevant political exposure; sanctions screening tests possible exposure to restrictive measures; adverse-media screening provides additional contextual information. The controls may share identity data, but their status and decision paths remain distinct.