PEP Screening

Availability and commercial scope

PEP Screening appears as KYC → PEP Screening at /app/kyc/pep only when the active license includes the KYC Module and pep Sub-module and the installed OneView version supports it. Execution also requires an active compatible PEP Screening connection from Prembly or OpenSanctions.

PEP Screening and Sanction Screening are independent provider operations. Licensing, configuring, or running one does not include or run the other. Confirm the client's separate commercial approval, provider pricing, and permitted use for each operation before production use. One PEP request uses OneView execution capacity and may incur the provider's PEP Screening charge even when the outcome is not a match or the request later fails.

PEP status is a risk-screening signal, not proof of wrongdoing. The client remains responsible for its lawful basis, screening policy, decision process, escalation criteria, and any legally required review.

Configure a connection

A connector administrator needs vendors:read and vendors:manage.

1. Confirm License & Updates → License lists KYC → PEP Screening. Select Refresh after an approved license change.
2. If the Sub-module is licensed but absent, check License & Updates → System updates and apply the approved release that supports it.
3. Open Operations → Vendor connections and choose the released PEP Screening service from Prembly or OpenSanctions.
4. Choose a supported environment and complete only the friendly credential fields OneView displays.
5. Select Save and validate, then confirm the connection is active and preferred for PEP Screening in that environment.

Create and manage the PEP connection separately from a Sanction Screening connection, even when the provider issues the same account credential. Saved configuration confirms the installed contract and protected credential storage; it does not prove provider authentication, account balance, network access, or that a live screening will succeed.

OpenSanctions hosted production

OpenSanctions provides the separate pep-screening service for this Sub-module. It screens the provider's PEP-related categories, including relevant related-person categories, without also running a sanction query.

The released v1 connection uses the hosted OpenSanctions production API only. Obtain a commercial OpenSanctions API key under the client's provider agreement, store the authoritative value in the client's secret manager, and enter it in the friendly OpenSanctions API key field. Confirm current pricing, usage allowances, processing terms, and supported screening categories directly with OpenSanctions before production use.

There is no OpenSanctions sandbox connection in v1. Provider-approved synthetic tests use the hosted production service and may count toward provider usage or charges. Self-hosted or on-premises OpenSanctions yente is not a supported OneView v1 connection.

Run a browser screening

A browser user needs verifications:execute. verifications:read provides metadata-only history, while verifications:results:read is additionally required to reveal stored result previews and details.

1. Open KYC → PEP Screening.
2. Select New Verification and choose an active PEP Screening connection.
3. Enter First name and Last name.
4. Add the optional friendly fields supported by the selected service only when approved and available. OpenSanctions displays Middle name, Date of birth, Nationality, and Gender. Do not invent an optional value to make the request appear more complete.
5. Optionally enter a safe operational purpose that contains no name, date of birth, or other identity data.
6. Review the selected operation and subject fields, then select Run verification once.

PEP Screening does not run Sanction Screening in the background. Run the other Sub-module separately only when the client's approved process requires it. After an uncertain outcome, review history before trying again to avoid a duplicate provider charge.

OneView does not automatically retry an OpenSanctions PEP provider call. If the browser disconnects or the request outcome is uncertain, review verification history before submitting again and reconcile provider usage when required.

Synchronous API

An external client application uses an active API Service Account and the released endpoint. The selected connection determines the provider contract:

This example selects a hosted OpenSanctions production connection:

POST /api/verifications/pep
Authorization: Bearer <service-account-api-key>
Idempotency-Key: pep-screen:00000001
Content-Type: application/json

{
  "connectionId": "<active-opensanctions-pep-connection-id>",
  "purpose": "Approved customer screening",
  "data": {
    "firstName": "<provider-approved-synthetic-first-name>",
    "lastName": "<provider-approved-synthetic-last-name>",
    "middleName": "<optional-synthetic-middle-name>",
    "dateOfBirth": "<optional-supported-value>",
    "nationality": "<optional-supported-value>",
    "gender": "<optional-supported-value>"
  }
}

data.firstName and data.lastName are required for both providers. Use only the optional fields supported by the selected connection. Follow the friendly labels and exact date, nationality, and gender formats shown by that connection's API Usage panel. Omit an unavailable optional field instead of sending an empty or invented value. Omit connectionId only when the preferred active production PEP connection is intended.

The response follows the common Synchronous API envelope. A completed normalized result includes the screening outcome, whether a match was indicated, the match count, the searched name, provider-specific guidance, and whether manual review is required. PEP results may also include a bounded set of normalized match details. Treat those details as a screening aid rather than a complete provider record, and do not build against undocumented provider fields.

An OpenSanctions result exposes only bounded normalized screening fields, not its raw response or a complete provider profile. Its match confidence describes how strongly the submitted identity resembles a candidate. It is not a risk rating, proof of PEP status, or a client decision.

Interpret the result

The normalized outcome has one of these values:

• clear — no candidate match was identified from the completed screening; this is not a permanent guarantee.
• potential_match — one or more candidates require manual comparison and client review.
• match — the service identified a strong match signal; the client must still follow its approved review and decision process.
• inconclusive — OneView cannot present a confident screening conclusion; do not treat it as clear.

matched is the normalized match indicator, and matchCount is the number of candidate matches represented by the normalized result. searchedName records the normalized search name. Provider-specific risk guidance, OpenSanctions match confidence, and the manual-review indicator guide the next step; they do not make a legal, onboarding, employment, or account decision for the client.

For potential_match, match, or inconclusive, route the case to an authorised reviewer. Compare only the bounded details available in the installed release, use the client's approved provider-review process when more evidence is required, record the decision outside purpose text, and restrict stored result access to approved reviewers.

Troubleshooting and safe handling

• PEP Screening is missing — confirm the pep entitlement, refresh the license, confirm the installed version, and sign in again. A Sanction Screening entitlement does not grant PEP Screening.
• No connection is available — confirm a released PEP service connection is active in the intended environment and preferred when the request omits connectionId.
• Input is rejected — provide both names and use only the optional formats displayed by the selected service.
• Provider request fails — confirm the PEP connection, provider account state, network allow-listing, and safe error code. Reconcile uncertain requests before retrying.
• OpenSanctions is unavailable in sandbox — use its hosted production connection with a client-approved synthetic test and confirm possible provider usage or charges first. Do not configure a self-hosted yente endpoint.
• OpenSanctions rejects the credential — re-enter the client's complete commercial API key from its secret manager and confirm the provider account is active. Do not paste the key into logs or support requests.
• Confidence looks high — treat it as match confidence, not subject risk or a final PEP finding. Complete the approved manual review.
• Result is unexpected — confirm the request used PEP Screening rather than Sanction Screening, then follow the client's manual-review procedure. Do not repeatedly resubmit a real person to seek a different answer.

Names, dates of birth, match details, and screening results are personal data. Never place them in URLs, idempotency keys, logs, metrics, screenshots, chat, or support tickets. When an OpenSanctions connection is selected, the approved identity fields are sent to the configured OpenSanctions hosted production API. Include that transfer in the client's privacy review and data map. Use provider-approved synthetic identities for testing.