List Check
Compliance Screening
List Check
POST
List Check
Check entities against KYC watchlists (OFAC, UN, EU, UK, and many more) to identify sanctions, PEPs (Politically Exposed Persons), crypto-related risks, and other risk entities.
The match works whether the number is stored on the list entry as
or in the JSON body:
Per-request ephemeral must be enabled for your account first: the endpoint identifier (
Endpoint
Authentication
Requireskyc:create permission. Include your Bearer token in the Authorization header.
Request Body Parameters
Subject Parameter Details
Required Fields
At least one of the following must be provided:Entity Types
Identifiers Array Format
When using theidentifiers field, provide an array of objects:
Identifier Matching
Identifier and document matching is value-first. An exact ID or document number matches a list entry regardless of how the document-type label is named on either side (CI, DNI, National ID, document_id, a numeric id, etc.). Values are normalized
before comparison (non-alphanumeric characters stripped, case-insensitive).
This means you do not need to send document_type to get an exact identifier hit —
document_id alone is enough:
ci, document_id,
a numeric id, or inside an identifiers[] array. Sending document_type (or the
identifiers array) is still supported and never blocks a match. An exact identifier
match always returns confidence_score: 1.0.
nationality and birth_date refine name-based matches only (and may lower
confidence on a mismatch). They never affect an exact identifier match.Ephemeral List Check
For synchronousPOST /kyc list checks, you can request ephemeral processing with either:
kyc.single for single-list checks, kyc.multi for multi-list checks, kyc.batch for direct multi-entity batches — or the wildcard *) has to appear in your tenant’s data_processing_config.allowed_ephemeral_endpoints, otherwise the request is rejected with a 400.
Tenants can also opt in account-wide: when your tenant’s data_processing_config.mode is set to ephemeral, every synchronous list check runs in ephemeral mode regardless of per-request headers or body flags (the tenant-level setting always wins and does not require the allowlist). Contact support to enable either option on your account.
When ephemeral mode is active, the API returns the normal match response but does not save validation records, audit DynamoDB records, or detailed audit events, even if save_validation is true.
The platform still retains aggregate billing metrics, such as one counted list check, and operational logs without subject PII for the configured CloudWatch retention period. Tenants with retain_billing_metrics: false in their data_processing_config also suppress the aggregate usage event.
Ephemeral processing applies to synchronous list checks (single, multi-list, and direct multi-entity batches), 1:1 face verification (see Face Match), adverse media analysis (see Adverse Media), and crypto wallet checks (see Crypto Wallet Check). Asynchronous batch jobs (POST /kyc/jobs) reject ephemeral mode with ZDR_UNSUPPORTED_FOR_BATCH because they rely on SQS queues, job records, and dead-letter queues. Screening and sessions are not covered yet.
Available Watchlists
If you send neither
list_name nor lists (or send an empty lists array),
the check runs against every list enabled for your environment. To pin a
specific set — for example the core sanctions set — pass them explicitly:
"lists": ["ofac", "un", "senaclaft_uy"].Government Sanctions Lists
US Export Control Lists
Regional & Specialized Lists
Cryptocurrency Lists
Search Types
When
search_type is omitted, the default is fast_precise_cascade. The
llm_enhanced value is deprecated and rejected. If you need the previous
default behavior, send "search_type": "composite" explicitly.Request Examples
Check Person Against Single List
Check Person with Document ID
Check Cryptocurrency Wallet
Check Company
Check Vessel by IMO Number
Check Multiple Lists
Check with Multiple Identifiers
Save Validation for Dashboard
Usesave_validation: true to store the validation result and view it later in the dashboard:
Response Format
OFAC Metadata Fields
When an OFAC entry includes public identity metadata, the API returns it insidematches[*].match_data:
nationalitybirth_dateidentifiers(array with document/wallet/tax identifiers depending on list entry data)
Note: Metadata availability depends on source list data. If a source entry does not publish nationality/identifiers, those fields may be absent.The response envelope depends on whether you check a single list (via
list_name) or multiple lists (via lists, or by omitting both — which
checks every enabled list).
- Single-list responses wrap the check under a top-level
resultobject. - Multi-list responses expose
results(keyed by list name) plus asummaryaggregate. - Both include an
execution_contextobject (the request id lives there asexecution_context.request_id— there is nometaobject).
Match Object
Each entry in a list’smatches array has this shape:
Success Response (Single List)
Returned when the request useslist_name.
Success Response (Multiple Lists)
Returned when the request useslists (or omits both list_name and lists,
which checks every enabled list). Each entry in results has the same shape as
the single-list result object.
If an individual list fails to evaluate, its entry in
results is replaced
with { "is_match": false, "error": "Validation failed for this list", "matches": [] }
and summary.has_errors is set to true. A failure in one list does not fail
the whole request.Summary Fields (Multi-list)
No Match Response (Single List)
Error Responses
Error responses share the same envelope as success responses: a top-levelstatus: "error", an error object, and an execution_context (the request id
is execution_context.request_id — there is no meta object).