PEP (Politically Exposed Person) Check

Credits: 1 per call.

Searches the consolidated PEP (Politically Exposed Persons) database for a subject — covering active PEPs, former PEPs (EX_PEP), and their immediate family and close associates (PEP_AFFINITY, EX_PEP_AFFINITY).

Input flexibility — three valid invocation forms:

The endpoint accepts a search in any of three forms — pick the one that matches the data you have on hand. You may include nationalIdNumber alongside any of them to tighten the match.

1. Single name (name) — pass the full name as one string. Quick and convenient when you only have the full name as a single value.
2. Separated name (givenNames + firstSurname + optional secondSurname) — Mexican-style split. Strongly recommended for best match quality, because the matching engine can apply per-component logic that produces fewer false positives on compound first names and compound surnames. When using this form, both givenNames and firstSurname are required.
3. Identifier only (nationalIdNumber) — pass a CURP or RFC by itself when that is all you have. The search runs against records that publish the identifier.

If more than one form is sent (for example name plus separated fields), the separated fields take precedence over name. The nationalIdNumber is normalised (trim, uppercase) and reported back per match in matchedOn.identifiersMatched and in the standalone identifierMatch field.

Risk Level Matrix (riskLevel):

Each match in matches[] has a base severity per its listType:

The endpoint riskLevel is the maximum severity across matches[]:

• NONE — no matches at or above minSimilarityScore. Safe for automated approval from a PEP perspective.
• LOW — only EX_PEP_AFFINITY hits found (family or close associate of a former PEP).
• MEDIUM — at least one EX_PEP, PEP_INACTIVE, or PEP_AFFINITY hit.
• HIGH — at least one PEP_ACTIVE hit. Aligned with the categories that FATF Recommendation 12 and Mexican LFPIORPI flag for Enhanced Due Diligence (EDD).

riskLevel is a screening signal intended to feed your compliance workflow. Combine it with identifierMatch, similarityScore, and the per-match complianceDetails we surface so your team can apply its own internal policy.

Which variant matched: every entry in matches[] carries a matchedOn object identifying the canonical record that was hit and an identifiersMatched array — for example name and nationalIdNumber — listing which fields agreed. The standalone identifierMatch field exposes the precision of the identifier comparison (EXACT, PARTIAL, MISMATCH, or NOT_PROVIDED when no identifier was sent). Use these together to audit the confidence behind a hit.

How similarityScore is computed: the score reflects combined name + identifier confidence, not name alone. A match’s similarityScore is the higher of (a) the name match quality and (b) the strength of the identifier comparison — an EXACT nationalIdNumber match contributes a full-confidence score, a PARTIAL match contributes a strong-but-not-certain score, and MISMATCH / NOT_PROVIDED contribute nothing (the name drives the score in those cases). This means a search by nationalIdNumber alone still returns a high-confidence hit even though no name was supplied to compare — a CURP or RFC coincidence is a deterministic identity signal. Inspect identifierMatch and matchedOn.identifiersMatched to see why a given match scored the way it did.

Multi-match handling: the response returns every match at or above minSimilarityScore, sorted by similarityScore descending. data.totalMatchesFound mirrors matches[].length and is provided for convenience.

Use this endpoint as part of AML programs where screening counterparties against PEPs is part of your KYC workflow — common in regulated financial services, cross-border payments, and onboarding pipelines.