> ## Documentation Index > Fetch the complete documentation index at: https://docs.tic.io/llms.txt > Use this file to discover all available pages before exploring further. # Screening > PEP, sanctions and adverse media screening through the LENS API - screen people and organisations by name and identity number, and understand how matching and hit ratings work. Enterprise+ tier Screening checks people and organisations against politically exposed person (PEP) lists, sanctions lists and adverse media, in a single call, without first creating them as person or company records in the platform. You supply a name and/or an identity number for each subject and get back the list entries that matched, with enough data on each hit to decide whether it is the same person or organisation. | | | | ----------------- | -------------------------------------------------------------------------------------- | | Endpoint | [`POST /screening/search`](/api-lens/screening/search) | | Authentication | `x-api-key` header, see [Authentication](/api-lens/authentication) | | Subjects per call | 1 to 50 | | Billing | Every call places an order. [Test mode](/api-lens/screening/test-mode) calls are free. | These pages cover what the endpoint reference cannot: [how matching works](#how-matching-works), [what a result contains](/api-lens/screening/results), [which lists are screened](/api-lens/screening/lists), and [how to test](/api-lens/screening/test-mode). ## Quick start ```bash theme={null} curl -X POST https://lens-api.tic.io/screening/search \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "testMode": true, "subjects": [ { "reference": "cust-1001", "name": "Anna Exempelsson", "birthDate": "1975-04-12", "countries": ["SWE"] }, { "reference": "cust-1002", "identityNumber": "5560000000" } ] }' ``` The response contains one entry per subject under `results`, each with its own list of `hits`. A subject with no hits is still returned, with `hitCount` 0. See [Results](/api-lens/screening/results) for the full data model and an example response. ## Request essentials The full request schema is on the [endpoint page](/api-lens/screening/search). The properties that shape the outcome are: | Property | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `subjects[].name` | The name to match. At most 8 name parts. Required unless `identityNumber` is set. | | `subjects[].identityNumber` | Personnummer or samordningsnummer (10 or 12 digits) for a person, organisationsnummer (10 digits) for an organisation. Matched exactly. Required unless `name` is set. | | `subjects[].birthDate` | `yyyy-MM-dd`, `yyyy-MM` or `yyyy`. Filters hits by birth date. | | `subjects[].countries` | ISO 3166-1 alpha-3 codes, for example `["SWE", "NOR"]`. Filters hits by country. | | `subjects[].reference` | Your own reference, echoed back on the result and used in warning and error messages. | | `serviceScope` | Which lists to screen: a group (`SANCTION`, `PEP`, `INFO`), a single list name, or a comma-separated combination. Omit for every list enabled on your account. See [Lists](/api-lens/screening/lists). | | `nameMatching` | `Regular` (default) or `Phonetic`. | | `minimumNameMatchScore` | 0.6 to 0.99. Required with phonetic matching, ignored otherwise. | | `fuzzyBirthDateMatching` | Accept near matches on the birth date. | | `testMode` | Run against the test environment. See [Test mode](/api-lens/screening/test-mode). | ## How matching works Understanding the matching rules is the key to useful results and few false positives. **Name or identity number.** A subject with both a `name` and an `identityNumber` returns entries that match either one, not only entries that match both. An exact match on the identity number is the strongest possible match and outranks everything else. **Identity number.** Matched exactly against the identifiers registered on the list entry. Some PEP list entries carry a country prefix on the identity number, for example `SE198202029878`. A prefix is not required to get an exact match, but if you include one you will only be matched against entries with the same prefix. Use a prefix only when screening specifically against the `PEP_Edge` list. **Birth date.** Supplying `birthDate` filters out entries whose birth date does not match. Entries with no known birth date are always returned, since they cannot be ruled out. Use `fuzzyBirthDateMatching` to accept near matches. **Countries.** Supplying `countries` filters out entries registered to other countries. Entries with no country data at all are always returned. Country data on PEP lists is generally reliable, country data on sanctions lists less so, so a country filter cuts false positives but can also exclude a true hit whose list entry has poor country data. **Regular versus phonetic name matching.** Regular matching compares the name against the exact aliases stored on each entry. Phonetic matching also matches names that sound alike and is the right choice when spelling is uncertain, for example transliterated names. It must be combined with `minimumNameMatchScore`, and a low score combined with phonetic matching produces a very large number of hits. Start at 0.85 and adjust. ### Hit rating Every hit has a `hitRating` from 1 to 5 that states what the entry matched on. The higher the rating, the more certain the match. | `hitRating` | Person matched on | Organisation matched on | | ----------- | ------------------- | ----------------------- | | 5 | Identity number | Organisation number | | 4 | Name and birth date | not used | | 2 | Name and country | Name and country | | 1 | Name only | Name only | A rating of 1 means only the name matched. Whether that is the same person needs to be established from the other data on the hit: birth date, countries, roles and aliases. ### Name match score `nameMatchScore` is a value between 0 and 1 that states how closely the subject's name matched the best alias on the entry, where 1.0 is an exact match. It is only populated when `minimumNameMatchScore` was set on the request. ## Recommendations * **Screen in batches.** Up to 50 subjects can be screened in one call. When screening a customer base, fill each call rather than sending one subject per call. * **Always send a `reference`.** It is the only reliable way to pair results with subjects when you screen several at once, and it is what warning and error messages refer to. * **Prefer identity numbers.** An identity number gives a `hitRating` of 5 and removes name ambiguity entirely. Send the name as well when you have it, since some lists lack identity numbers. * **Narrow with birth date and countries.** They remove most false positives on common names. Remember that entries lacking that data still match. * **Treat rating 1 hits as candidates, not confirmations.** Use the birth date, countries, aliases and roles on the hit to decide. * **Keep the phonetic threshold high.** Start at 0.85 and lower it only if true hits are being missed. * **Check `errors` and `servicesQueried`.** A subject that was not screened, or a list that was not queried, looks like a clean result if you only count hits. * **Store `externalId`.** It identifies a list entry over time, which lets you tell a new hit from one you have already reviewed.