Three quick clarifications:
IDs are returned without special characters (e.g., HKID A808080(9) → A8080809). → Should we send both raw and cleaned versions, or do you normalize automatically?
Many PEP records have no ID stored (e.g., Li Ka-shing). When we search name + ID, the record disappears. → Best practice: treat ID as optional and always fall back to name match?
What exactly is the difference between “ID” and “National ID” in your data?
Hi @innoac, we have two categories of identifiers in the data: those with a well-understood format (eg: swiftBic, ogrnCode, innCode, uscCode, leiCode) and more generic fields for identifiers whose format we do not have specific handling instructions for (eg.: registrationNumber, idNumber, taxNumber ). We do minimal normalization when we compare these, so it’s a bit more of a matter of luck than I’d really like.
For PEP screening in particular, we very very rarely have IDs from the data source - so I think putting them into the request mostly makes sense in a sanctions screening use case.
Finally, there’s the entity ID itself - which is something we generate and manage, not a property of the person. See https://www.opensanctions.org/docs/identifiers/ for more info.
Best,
I have a follow-up regarding data matching: Sanction records typically include formal IDs, whereas PEP (Politically Exposed Persons) records often do not. Given this discrepancy, if an end-user searches using both an ID and a Name, should I search Sanction records by ID and PEP records by Name separately? What is the industry best practice for handling these divergent search criteria?
Should I raise this as a new question?
I assume by ID you mean something like taxpayer, passport or national registration numbers? In that case, I’d really just go for: more is more. If you have any of them in your records, include them in the query. There’s really no reason I can think of not to throw such detail into the ring and see if it can help make a match.
The problem we’ve discovered underneath: identifiers are great ways to make a positive match, but often much less suitable to qualify/discount one. For example, I think I have four or five different tax IDs between me and the German government right now. If you included one of those in a query to identify me in a watchlist and got a match, that would be strong evidence. But if the watchlist linked me to a different ID and you used that difference to discard the match, that’d be a mistake. We see this in many countries - very few actually manage to have strong identifiers for companies and people (and often this is a political decision).
Thank you for the prompt reply. I want to clarify my understanding of the search logic.
If I search using both a Name and an ID (e.g., Passport Number), the system applies an ‘AND’ condition. This means if the database contains a matching name but lacks the specific ID number, which is common for many PEP records, the search will return ‘Not Found.’
This is why I am asking if it is better to perform two separate searches: one using both the Name and ID, and another using the Name only. This would ensure that I catch records even when the ID is missing from the source data.
In this case, the cost for searching will be increased - 1 search vs 2 searches. Or is there a way I can apply “OR” condition i.e. Make ID as optional for searching?