MATERIAŁY I PRZEWODNIKI · GUIDEUPDATED 2026-08-20
Materiały i przewodniki
Przewodnik integracji API screeningu PEP
Zintegruj screening PEP z platformą przez REST API. Sprawdzaj osoby eksponowane politycznie i listy ostrzegawcze w czasie rzeczywistym.
A PEP screening API is a workflow, not a single yes-or-no lookup. This guide walks through the integration end to end: how to authenticate a PEP API request, how to design the submission payload so name matching has something to work with, how to handle asynchronous results without blocking onboarding, how to run CSV or XLSX batch jobs, and how to preserve the inputs, sources, and decisions reviewers may need months later. The same PEP sanctions API workflow covers politically exposed persons, sanctions lists, and criminal watchlists, so most teams integrate once rather than wiring one client per data type.
What this workflow covers
SCOPE- Create a scoped API key and send it in the X-API-Key header — server-side only, never in browser code.
- Submit one person or company through POST /api/v1/search with name, entity type, and any country or date-of-birth context you hold.
- Store the search ID and poll until processing reaches a terminal status; treat timeouts as manual review, not silent approval.
- Use the CSV/XLSX batch endpoint when many records share the same screening workflow, and keep a row-level reference for reconciliation.
- Run PEP, sanctions, and criminal-watchlist checks through the same PEP sanctions API workflow instead of maintaining separate integrations.
- Keep the submitted identity data, returned sources, reviewer notes, and final disposition together as one audit record.
- Use the interactive documentation or OpenAPI schema to confirm the current request and response contract before writing client code.
- Re-screen on a risk-based schedule and after material ownership, role, or jurisdiction changes — a PEP status can begin after onboarding.
Key statistics
DATA- Structured PEP coverage
- 750,000+ records from 134 public sources
- ScreenVeritAI public coverage register
- Integration surfaces
- Single search, CSV/XLSX batch, interactive docs, and OpenAPI schema
- ScreenVeritAI API v1 documentation
- Risk-based review
- FATF Recommendation 12 addresses PEP risk management and enhanced measures
- Financial Action Task Force
Compliance glossary
TERMS- PEP (Politically Exposed Person)
- An individual who holds or has held a prominent public position — such as a head of state, senior politician, or senior military officer — and their close associates and family members. PEPs require enhanced due diligence under FATF Recommendation 12.
- sanctions API
- A programmatic interface allowing software systems to screen names, entities, or transactions against official sanctions lists in real time.
- KYC (Know Your Customer)
- The process of verifying the identity of clients and assessing their suitability and risk profile, required under AML regulations globally.
- OpenAPI
- A standard specification format (formerly Swagger) for describing REST APIs, enabling automated documentation, SDK generation, and integration testing.
- PEP screening API
- An endpoint that accepts an identity — a person or a company — and returns structured politically exposed person context for review, including the public role behind a possible match and the sources supporting it. Integrations treat it as an asynchronous job rather than a synchronous lookup.
- asynchronous screening job
- A screening request that returns a search ID at submission and completes in the background. The client polls for a terminal status instead of holding the onboarding request open, which keeps user-facing flows responsive when a search takes longer than expected.
- batch screening endpoint
- An API endpoint that accepts a CSV or XLSX file of many subjects and runs them through the same search type, used for portfolio re-screening, supplier list reviews, and periodic recertification rather than one-at-a-time onboarding calls.
Authoritative references
SOURCES- 01FATF Recommendation 12 — Politically Exposed Persons
Financial Action Task Force
- 02OFAC SDN List API Access
U.S. Department of the Treasury
- 03EU PEP and Sanctions Compliance Requirements
European Commission
Expert perspective
NOTE“Risk controls perform best when sanctions checks and ownership context are reviewed together.”
Frequently asked questions
Q&A- What is a PEP screening API?
- A PEP screening API lets a system submit a person for screening against politically exposed person data and receive a structured result for review. In practice, the integration also needs to preserve the submitted identity data, the sources behind possible matches, and the final decision.
- How does ScreenVeritAI's PEP screening API work?
- Create a scoped API key, submit the subject through POST /api/v1/search, and retain the returned search ID. The search runs asynchronously, so your system retrieves the result after processing completes. The current endpoint contract is published in the interactive API documentation and OpenAPI schema.
- Can the same API workflow cover PEPs, sanctions, and criminal watchlists?
- Yes. The AML screening workflow checks PEP, sanctions, and criminal-watchlist data together. Use the documented search type for the workflow you need, and read the current OpenAPI schema rather than hard-coding fields that may belong to a different report type.
- How should an integration handle processing time?
- Treat screening as an asynchronous job. Store the search ID returned at submission, poll at a bounded interval, handle failed or incomplete states explicitly, and set a timeout that sends the case to manual review instead of silently approving it.
- When should I use the batch endpoint?
- Use the batch endpoint for CSV or XLSX files containing many subjects that should run through the same search type. Validate required columns before upload and keep a row-level reference so each returned result can be reconciled with the source record.
- What authentication does the PEP screening API use?
- Screening requests use a scoped API key in the X-API-Key header. Keep keys on the server, grant only the permissions the integration needs, and rotate a key if it may have been exposed. Do not place API keys in browser code or public repositories.
- Is the API compatible with OpenAPI/Swagger specifications?
- Yes. The interactive documentation is available at /api/v1/docs and the machine-readable schema at /api/v1/openapi.json. Use the schema for contract tests and client generation, then review generated code before it is used in production.
- How is PEP screening via API used in KYC and AML workflows?
- Teams commonly screen at onboarding, after a material ownership or jurisdiction change, and on a risk-based re-screening schedule. A possible match should create a review task with its source evidence; it should not become an automatic rejection without a documented decision.
- What is the difference between a PEP API and a sanctions API?
- A PEP API returns political exposure context — the public role held, the period, and the family members or close associates connected to it. A sanctions API returns designations issued by an authority such as OFAC, the EU, the UN, or HM Treasury. They answer different questions: a PEP match is a risk signal that calls for enhanced due diligence, while a sanctions match is usually a hard control. A combined PEP sanctions API returns both from one submission so the two signals can be reviewed against the same identity data.
- What data should be sent in a PEP API request?
- At minimum the full name and whether the subject is a person or a company. Country, date of birth, and known aliases or transliterations materially improve match precision and reduce the review queue, because most false positives come from common names screened without any distinguishing attribute. Send the data you already hold rather than guessing values, and keep the exact payload you submitted — reviewers need to know what was screened, not only what came back.
- How should I test the PEP screening API before going live?
- Generate a client from the OpenAPI schema at /api/v1/openapi.json, then run a fixed set of known subjects through the integration: a clear no-match, a known public figure, a common name that should produce several possible matches, and a non-Latin-script name. Assert on the shape of the response rather than on specific match counts, which change as source data changes. Confirm the failure paths too — expired key, malformed payload, and a job that never reaches a terminal status.
- How long should PEP API results be retained?
- Retention is driven by your AML policy and local regulation rather than by the API, and five years after the end of the relationship is a common baseline in EU and UK regimes. Store the search ID, the submitted identity data, the returned sources, the reviewer's decision, and the timestamp together; a screening record that cannot be reconstructed later is difficult to defend in an audit or examination.
Q.01
Q.02
Q.03
Q.04
Q.05
Q.06
Q.07
Q.08
Q.09
Q.10
Q.11
Q.12