canonical: https://jentic.com/apis/namescan.io/namescan # NameScan PEP and Sanctions API Jentic publishes the only available OpenAPI specification for NameScan PEP and Sanctions API, keeping it validated and agent-ready. NameScan screens individuals and entities against politically exposed person (PEP) lists, global sanctions lists (OFAC, UN, EU, UK HMT, AUSTRAC), and adverse media for AML and KYC compliance. Three endpoints support real-time scans of a single person, a single legal entity, or batches of names - returning match scores, confidence levels, and full source citations so compliance teams can review hits and document decisions. ## For AI agents Screen people and entities against PEP, sanctions, and adverse-media lists for AML/KYC compliance. Returns match scores and citations. ## Scope Does not handle identity document verification, biometric matching, or transaction monitoring - use for PEP and sanctions screening only. ## Capabilities - Screen an individual's name and date of birth against global PEP lists with match scoring - Scan a legal entity name against international sanctions lists including OFAC, UN, EU, and HMT - Run batch scans of up to thousands of names per request for periodic customer rescreening - Surface source citations for every match so compliance teams can defend decisions in audits - Filter results by match strength to suppress false positives during high-volume onboarding flows ## Use cases ### Customer Onboarding KYC Screening Banks, fintechs, and crypto exchanges must screen every new customer against PEP and sanctions lists before opening an account. Calling POST `/v3/person-scan` during onboarding returns match details within seconds, including source list, match category, and confidence score, letting the platform pass clean customers through automatically and queue hits for manual review. The API key authentication keeps integration simple while satisfying audit requirements. Example prompt: POST `/v3/person-scan` with name='John Smith', dob='1980-05-12', country='GB' and flag the customer if any match has a score above 0.85. ### Periodic Customer Rescreening Sanctions and PEP lists change daily, so AML programmes rescreen their entire customer base on a regular schedule. The `/v3/batch-scan` endpoint accepts a list of customer records and returns a structured result for each one in a single call, letting compliance teams run nightly or weekly rescreens at scale without orchestrating thousands of individual requests. Example prompt: POST `/v3/batch-scan` with the previous month's new-customer list and email a CSV of any records returning match_strength='strong' to the compliance officer. ### Entity and Counterparty Due Diligence B2B platforms and corporate banking systems need to screen suppliers, vendors, and counterparties - not just individuals. POST `/v3/entity-scan` checks a legal entity name against global sanctions lists and adverse-media sources, returning UBO and registration metadata when available. This makes it possible to wire entity due diligence directly into procurement and onboarding workflows. Example prompt: POST `/v3/entity-scan` with name='Acme Trading Ltd', country='RU' before approving a new vendor in the procurement system. ### AI Agent Compliance Workflow An AI compliance assistant invoked through Jentic can answer questions like 'is this customer on any watchlist?' by searching for the screening operation, loading its schema, and executing it with the customer's details. Because Jentic stores the NameScan API key encrypted in the vault, the agent never sees the raw key - it receives only a scoped token to call the operation. Example prompt: Search Jentic for 'screen person against pep and sanctions', load the POST `/v3/person-scan` operation, and execute it for the customer record under review. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/v3/person-scan` | Screen an individual against PEP and sanctions lists | | POST | `/v3/entity-scan` | Screen a legal entity against sanctions lists | | POST | `/v3/batch-scan` | Run a batch screening across many records | ## Key resources - **PersonScan** — Screen an individual against PEP, sanctions, and adverse media - **EntityScan** — Screen a legal entity against sanctions and adverse media - **BatchScan** — Run sanctions and PEP scans across many records in one request ## Why Jentic - **Setup:** Wiring NameScan by hand means holding its api-key, setting it on every call against namescan.io/api, and shaping the person, entity, and batch screening requests yourself. Through Jentic you install once, import the NameScan PEP and Sanctions API from the API Directory, store the key once, and your agent calls it. - **Permission scoping:** NameScan sends the subject to screen in the request body rather than a resource id in the URL path, so scope the agent to the operations it needs, such as person or entity screening, and leave batch scanning out of the allowed set unless you include it. - **Credential handling:** Your NameScan api-key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'screen a person against sanctions', and Jentic returns the matching NameScan operation with its input schema so the agent fills in the customer record without browsing the reference docs. ## Related APIs - **ComplyAdvantage API** — Real-time AML and sanctions screening with adverse media - **Onfido API** — Identity document verification and biometric checks - **Sumsub API** — End-to-end KYC platform combining ID verification and AML screening ## FAQ ### Why is there no official OpenAPI spec for NameScan PEP and Sanctions API? NameScan does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call NameScan PEP and Sanctions API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the NameScan PEP and Sanctions API use? NameScan uses an API key passed in the api-key HTTP header on every request. When called through Jentic the key is encrypted in your Jentic One instance and the agent receives a scoped token; the raw api-key never enters the agent's context window. ### Can I run a batch screening with the NameScan PEP and Sanctions API? Yes. POST `/v3/batch-scan` accepts an array of person or entity records and returns a result object for each, ideal for periodic rescreening of an existing customer base. Use POST `/v3/person-scan` or POST `/v3/entity-scan` for single real-time onboarding checks. ### Which sanctions lists does the NameScan PEP and Sanctions API check against? Scans cover global sanctions sources including OFAC, UN, EU, UK HMT, AUSTRAC, and DFAT, alongside PEP databases and adverse-media feeds. Each match in the response includes a 'sources' array citing the specific list and entry that produced the hit, so compliance teams can document decisions. ### What are the rate limits for the NameScan PEP and Sanctions API? Rate limits are tier-dependent and not declared in the spec. Refer to the NameScan dashboard for your current plan's quota; the batch endpoint should be preferred when running large rescreens to avoid exhausting per-second request limits. ### How do I screen a new customer through Jentic? Run jentic.search('screen person against pep and sanctions'), select POST `/v3/person-scan`, then jentic.execute with the customer's name, date of birth, and country code. Jentic returns the structured match list and the agent can apply your firm's match-score threshold to decide whether to escalate. ### Can I limit what my agent is allowed to do with the NameScan PEP and Sanctions API? Yes. Because you run Jentic One yourself, your own rules decide which NameScan operations and credentials the agent may use. NameScan takes the subject to screen in the request body rather than a resource id in the URL, so you scope the agent to only the operations it needs, such as POST `/v3/person-scan` for individuals or POST `/v3/entity-scan` for legal entities. You can leave POST `/v3/batch-scan` out of the allowed set unless you deliberately grant it, and the api-key stays with your instance rather than in the agent's context.