Starting today, every Xident document verification can answer one more question alongside “is this person old enough” and “is this document genuine”: is this person on a sanctions or politically-exposed-persons list?
No second vendor. No second integration. One new field in the result you already read.
What it does
When a user verifies with an identity document, the extracted identity — name, date of birth, nationality — is matched against the consolidated OpenSanctions dataset: more than four hundred data sources (443 at the time of writing) merged into one, including OFAC’s SDN list, the EU consolidated list, UN Security Council designations, the UK’s OFSI list, Interpol notices, and a worldwide politically-exposed-persons layer. The dataset refreshes on our servers every night, so new designations are screened against within a day of publication.
The result lands in the same verification result you already consume, as a new checks.aml entry with the same {performed, passed} shape as every other check — in the API response and in the webhook, identically. If you ignore unknown fields, nothing about your integration changes until you decide to read it.
A name match never rejects a person
Screening data is fuzzy by nature — names collide, transliterations vary, and a distant civil servant can share a name with a designated individual. So we made one rule absolute: a screening match never automatically fails a verification. A strong match routes the session to your review queue with the reason aml_match and the match context your reviewer needs. A person is only ever rejected by another person.
Screening without leaking the name
Here is the part we think matters most. The standard way to add screening is to call a screening bureau’s API — which means sending your users’ names to one more third party, adding one more processor to your DPA, and trusting one more retention policy.
We self-host the entire matching stack — the engine and the full dataset — on our own EU infrastructure. The screened name never leaves it. No screening vendor ever sees your users, and your sub-processor list is exactly as long as it was yesterday. If you have read our privacy architecture, you will recognize the pattern: the same reasoning that keeps face images in the browser keeps screened names in our racks.
Honest scope
One sentence of honesty, because compliance marketing tends to omit it: Xident provides sanctions and PEP screening as a control inside your compliance program. We flag, contextualize, and route; your team decides; and your obligations under applicable AML law remain your own. If a vendor tells you their API makes you “AML compliant,” ask them which regulator agreed.
Who this is for
If you operate in iGaming, wagering, or any licensed vertical, your regulator already expects screening — until now that meant a second vendor beside your age-verification provider. If you run a marketplace or platform where sanctions exposure is a commercial risk rather than a licensing mandate, you now get the check effectively for free with the verification you were already running.
Screening is available on document-path verifications today. Details on how it works, what data backs it, and what your reviewers see: xident.io/sanctions-screening. The API change is documented in the changelog.
