PEP Screening API: How to Screen Politically Exposed Persons (2026)

What is a Politically Exposed Person?

The Financial Action Task Force (FATF) defines a Politically Exposed Person as an individual who is or has been entrusted with a prominent public function. This includes heads of state, senior government officials, senior executives of state-owned enterprises, high-ranking military officers, members of parliament, senior judiciary officials, and ambassadors.

Applicable frameworks may also address family members and close associates, often called RCAs. Source data and the relevant legal framework determine what relationship context is available and how it should be assessed. Relationship context is not proof of identity or wrongdoing.

There are three categories of PEPs recognized internationally:

• Foreign PEPs: individuals holding prominent public functions in another country. Under FATF Recommendation 12, foreign PEPs always require enhanced due diligence (EDD).
• Domestic PEPs: individuals holding prominent public functions in your own country. FATF treats them as high-risk on a risk-sensitive basis — EDD applies where the business relationship is assessed as higher risk, rather than automatically.
• International organization PEPs: senior figures in international organizations like the United Nations, World Bank, or International Monetary Fund.

Why PEP screening matters

FATF Recommendation 12 establishes a preventive, risk-based framework for relationships involving PEPs. The purpose is to help institutions identify relevant context and apply their own lawful controls, not to infer criminality from office, family relationship, or name similarity.

A screening result is only one input to that process. The candidate, source context, available identity evidence, coverage state, and the institution's policy must remain distinct. A name candidate is not a confirmed identity. This article is operational guidance, not legal advice; teams should determine their obligations with the relevant regulator and legal advisers.

The challenge: broad PEP coverage changes constantly

PEP screening is harder than sanctions screening for several reasons. The population is broad and constantly changing across jurisdictions, public offices, family relationships, and close associates. PEP lists are not centralized: unlike sanctions lists published by specific authorities (OFAC, EU, UN), there is no single authoritative PEP database, so PEP data must be aggregated from government records, public databases, parliamentary websites, and open-source intelligence.

Public functions and published relationship information change over time. Source recency, scope, and availability belong in the review record rather than being assumed complete. And names and entity details vary across source records, so retrieval is useful for surfacing candidates but does not establish identity certainty on its own.

How Verifex handles PEP screening

Verifex supports configured PEP sources and screens PEP signals in the same workflow as sanctions and watchlist checks. Coverage depends on plan, source configuration, and environment. The production engine uses multiple retrieval and identity-evidence signals rather than treating a name similarity as confirmation. When available, a screening request can carry:

• Name input: candidate retrieval can surface similar names and aliases for review.
• Date of birth: a conflicting date of birth is conflict evidence. It cannot silently confirm identity or turn the result into a clear outcome.
• Country and other lawful identifiers: context can assist a review when it is available and relevant.
• Coverage and decision fields: the served response identifies whether execution was complete enough to support the applicable policy.

PEP screening API example

PEP source screening uses the same screening request contract. This illustrative request is not a decision guarantee. Use the current API reference for the complete request and response schema.

curl -X POST https://api.verifex.dev/v1/screen \
  -H "Authorization: Bearer vfx_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Recep Tayyip Erdogan",
    "type": "person",
    "dob": "1954-02-26",
    "country": "TR"
  }'

The served response distinguishes candidates from confirmed identities and reports coverage and evidence availability. Date of birth, country, and other lawful identifiers can help a reviewer assess a retrieved candidate. They do not make a name similarity conclusive.

Enhanced due diligence for PEPs

Identifying relevant PEP context is only one input. Applicable requirements and a customer's risk-based program can call for enhanced due diligence measures such as source-of-wealth and source-of-funds review, escalation or senior-management approval, and ongoing review and periodic reassessment. Each should follow the policy and legal framework that applies to the relationship. Verifex provides screening and decision evidence; it does not determine legal obligations, identity confirmation, or an onboarding decision.

Some PEP sources publish relationship information about relatives and close associates. A relationship record can be useful context for a risk-based process, but it is not an allegation, proof of identity, or a complete record of a person's relationships. Verifex reports relationship context only where it is present in configured source data.

Matching and identity assessment

Name variants can retrieve a useful candidate, but retrieval is not identity certainty. Reviewers should use the served identity evidence and conflict signals, including date of birth and country where lawful and available. An Exact-Only no-hit is not a compliance clearance, and partial, unavailable, or capped execution cannot be represented as complete coverage. Current matching methodology and measured scope are published separately; internal algorithm labels are not a substitute for the served decision contract.

Starter and above. Free-plan screening excludes PEP sources. Review the sources, coverage, and plan scope that apply to your workflow before relying on a result, and validate the result contract against your own policy.

Frequently asked questions