Limits
What the LinkinLegal sanctions endpoints cannot do: scripts that are not transliterated, entity kinds that cannot be matched, the candidate ceiling and response times.
Read this page before you design your screening. Every limit here is real and measured. None of them is a reason to skip a check; all of them change how you send the request.
Scripts
| Script | match | search |
|---|---|---|
| Latin | Yes | Yes |
| Cyrillic | Yes. Names are written in Latin letters on both sides, so Gulina finds ГУЛИНА. | Only when your text is in the same script as the caption. |
| Greek | Yes, same as Cyrillic. | Same as above. |
| Arabic, Chinese, Japanese, Korean | Not read. A name written only in these scripts finds nothing, also when the list has the same spelling. | Chinese characters and Japanese kana return 400 query_too_short. |
What to do: send the Latin spelling in properties.name. If you hold both, send both — every spelling you add can only help:
{ "properties": { "name": ["الشركة العربية", "Al Sharikah Al Arabiyah"] } }Entity kinds that cannot be matched
match accepts six kinds of subject: Person, Company, Organization, LegalEntity, Vessel and Airplane. Any other value returns 400 invalid_request.
Security(bonds, shares and other financial instruments) cannot be matched. Find these withsearch, or withGET /sanctions/entities/{id}.- Link records (
Ownership,Family,Directorship,Membership,Occupancyand the rest) are never match candidates. They carry no name of their own; they join two entities.searchand the entity endpoints do show them.
Only entities with target: true are match candidates.
The candidate ceiling
For each source (sanctions, pep), match first collects up to 100 candidates by name and by identifier, and then scores them.
The collection step allows a small number of typing errors per word (one for a word of 4 to 7 letters, two from 8 letters), and it takes exact identifier values.
Two consequences:
- A very common name can fill the 100 places with other people. The true hit is then scored with the rest, but a name-only query gives you little to decide with. Send the birth date, the country and every identifier you hold.
- A name with three or more typing errors in one word is not collected at all. The score cannot save what was never found.
The scored list you get back is cut by limit (1 to 25).
Search reads the caption only
search finds your text inside the caption, nothing else:
- Aliases, former names and other spellings are not read.
- The word order must be the same.
- The script must be the same.
An empty search result is not a clean screen. Use match for that. Read What "contains" means for you.
A single word never matches
One word against a multi-word name reaches 0.70 at most, and the default threshold is 0.8. A lone given name or a lone surname therefore gives match: false.
A one-word name does match an entity whose name is that one word: the vessel NAKO matches NAKO with a score of 1.
This is deliberate: Vladimir is not a screening decision. Send the full name.
Response time
Measured on the live service: a match call answers in about 0.3 seconds, and up to 0.6 seconds.
A batch of 100 subjects takes longer than one call, and far less than 100 calls. Set your client timeout to at least 30 seconds for a full batch, and retry a 503 index_unavailable.
What the API does not decide
The API returns data and a score. It does not decide whether you may do business with somebody, it does not keep your audit trail, and it does not tell you which list your regulator expects you to screen against.
Store, for every screening you run: the subject you sent, the id and score of every candidate, your decision, and the date. That record is yours to keep.
Last updated on