Denied party screening checks people, companies, vessels and aircraft against official sanctions lists before onboarding or processing activity. KYCWire searches 33,381 records across five OFAC, EU, UK and UN lists, but every returned match remains a signal for human review—not a verdict.
TL;DR
- KYCWire covers 33,381 records across five official lists: OFAC SDN, OFAC Consolidated, EU, UK and UN.
- List data refreshes every 6 hours; API latency is 66 ms median and 142 ms at p95 on cold requests.
- KYCWire records recall@5 of 0.99 on a public test set. That metric does not guarantee perfect recall or measure false-positive volume.
- Exact passport, IMO or registration identifiers should outrank name similarity. Birth-year conflicts should reduce scores rather than suppress candidates.
- KYCWire does not cover politically exposed persons or adverse media.
Screen names against OFAC, EU, UK and UN lists in one API call—200 free checks a month, audit trail included.
What Denied Party Screening Actually Covers
Denied party screening compares a subject’s identity attributes with sanctions records published by governments and international bodies. The subject may be an individual, legal entity, vessel or aircraft; the comparison may involve names, aliases, dates of birth, addresses, nationalities and identifiers.
KYCWire’s screening universe contains 33,381 records drawn from these five sources:
- OFAC Specially Designated Nationals and Blocked Persons List
- OFAC Consolidated Non-SDN Lists
- European Union financial sanctions list
- United Kingdom sanctions list
- United Nations Security Council consolidated list
Official publishers remain the legal source of truth. The US Treasury provides the public OFAC Sanctions List Search, the European Union publishes the EU Sanctions Map, and the UK government maintains the UK Sanctions List.
Sanctions screening is not full KYC
KYCWire covers official sanctions lists only. It does not include PEP screening or adverse-media screening, so a team needing those checks must use separate data sources and document how the results enter its wider KYC process.
This boundary matters. A clean sanctions result means no sufficiently relevant candidate was returned from the covered lists at that time; it does not establish low customer risk, beneficial ownership or absence of negative reporting.
Public tools versus API screening
| Tool | Public access price | Coverage or purpose | Operational fit |
|---|---|---|---|
| KYCWire free plan | $0 for 200 checks per month | OFAC, EU, UK and UN official lists | API, batch screening, monitoring, webhooks and CSV audit trail |
| OFAC Sanctions List Search | $0 | OFAC lists | Manual research and verification |
| EU Sanctions Map | $0 | EU sanctions regimes | Regime research and source verification |
| UK Sanctions List | $0 | UK designations | Source records and downloads |
KYCWire turns five official lists into scored API results with explanations, batch support and a CSV audit trail. The free plan includes 200 checks each month.
Build a Matching Hierarchy, Not One Fuzzy Score
A practical screening engine should rank evidence by its identity value. An exact identifier match—such as a passport number, vessel IMO number or company registration number—should outrank any name similarity because identifiers generally distinguish subjects more precisely than names.
A useful evidence hierarchy is:
- Exact official identifier match
- Strong name or publisher-designated alias match plus compatible identity attributes
- Cross-script or transliterated name match with supporting attributes
- Approximate name match with limited corroboration
- Weak alias or partial-name similarity without supporting evidence
Cross-script matching needs dictionaries
Cross-script matching cannot be reduced to character similarity. The Cyrillic query “Владимир Путин” must be capable of reaching “Vladimir Vladimirovich PUTIN,” even though the strings do not share Latin trigrams.
Name dictionaries, transliteration rules and known name variants provide the bridge. Trigram-only engines can return nothing when a Cyrillic query is compared with a Korean name represented in Latin script, because the engine sees no shared character sequence even where a linguistic mapping exists.
This issue is broader than transliteration. Word order, patronymics, compound surnames and publisher formatting can all change the visible string without changing the underlying identity.
Publisher alias strength should survive ingestion
Sanctions publishers may classify aliases as strong or weak. A weak alias should not receive the same weight as a primary name: doing so expands the candidate set and can turn common or incomplete labels into persistent false positives.
A scored result should explain which field matched, which alias class was used and which attributes supported or contradicted the candidate. Teams assessing sanctions-screening precision and latency should inspect these explanations rather than treating a score as self-explanatory.
Design the Screening Workflow Around Change
KYCWire refreshes its source data every 6 hours. That variable affects the meaning of every result: a customer cleared yesterday may need review after a new designation, alias or identifier enters a source list.
Screen at onboarding and monitor afterward
Onboarding screening answers a point-in-time question. Ongoing monitoring asks whether a previously screened subject now corresponds to a changed list record.
KYCWire supports monitoring with webhooks, allowing an application to receive a change signal rather than repeatedly building its own list-diff process. Batch screening covers backfiles, while individual API calls fit account creation, payment review or counterparty approval flows.
Latency belongs in the workflow design
KYCWire reports a 66 ms median response time and a 142 ms p95 for cold requests. Those figures describe API response latency, not end-to-end decision time: network transit, retries, internal enrichment and analyst review remain separate variables.
Low latency makes synchronous screening feasible, but not every match should block the user interface indefinitely. A common design separates “no meaningful candidate returned” from “review required,” then routes the second state to a case queue with a clear transaction policy.
The companion guide to AML screening and monitoring discusses how point-in-time checks and change detection fit into one control.
Keep evidence that can reconstruct the decision
A CSV audit trail should preserve the query, timestamp, candidate record, source list, score, matching explanation and disposition. Reviewer identity and rationale should be stored in the compliance case system if they are not part of the screening export.
A score without the underlying matched fields is difficult to defend. Store enough evidence to explain why the candidate appeared and why a reviewer cleared, escalated or rejected it.
Challenge the Conventional Wisdom: More Blocking Is Not Safer
The non-obvious risk in denied party screening is that aggressive filtering can hide the candidate an analyst most needs to see. A conflicting birth year should lower a score, not eliminate the record before review.
Birth dates can be incomplete, approximate, mistranscribed or attached to aliases in inconsistent ways. Suppressing a strong name candidate solely because one year conflicts creates an unauditable false negative: the reviewer never sees the contradictory evidence.
The safer model preserves competing signals. An exact identifier can dominate the ranking; compatible birth data can increase confidence; conflicting birth data can reduce confidence; and a weak alias can contribute less than a primary name.
This does not mean returning every remotely similar record. Candidate retrieval and decision thresholds serve different purposes. Retrieval should retain plausible records, while ranking and workflow rules determine which results require analyst attention.
Recall@5 is useful but incomplete
KYCWire achieves recall@5 of 0.99 on a public test set. In practical terms, the metric asks whether the relevant result appears among the first five candidates; it does not claim that every production query is resolved correctly.
Recall@5 does not measure precision, reviewer workload or the legal sufficiency of a decision. A system can retrieve the correct record within five results and still return distracting candidates around it. Thresholds therefore need testing against an institution’s own names, scripts, fields and risk rules.
What We Got Wrong / What Surprised Us
The tempting model is “normalize both names, calculate fuzzy similarity, and choose a threshold.” That model is too shallow for multilingual sanctions data.
The strongest surprise is how completely character-based matching can fail across scripts. A trigram-only engine does not merely assign a mediocre score to some Cyrillic-versus-Latin comparisons; it can retrieve no candidate at all. Dictionaries and transliteration paths belong in candidate generation, before fuzzy ranking.
Alias handling creates a second mistake. Flattening every publisher alias into one equivalent name field discards strong-versus-weak metadata and inflates low-quality matches.
Conflicting data creates the third. Treating a mismatched birth year as a hard exclusion appears efficient, but it conceals the candidate and the reason for exclusion. A visible score reduction produces a more reviewable result.
The practical lesson is that explainability starts inside retrieval and scoring—not in a sentence generated after the score. For broader implementation criteria, see this practitioner review of sanctions screening software.
Practical Takeaways
-
Map the required lists and subject types. Planning estimate: 30–60 minutes. Difficulty: low.
Record whether the control must cover people, companies, vessels, aircraft or all four. Expected outcome: a written scope that prevents sanctions screening from being mistaken for PEP or adverse-media coverage.
-
Define an evidence hierarchy. Planning estimate: 2–4 hours. Difficulty: medium.
Place exact identifiers above strong names, strong aliases above weak aliases, and compatible attributes above contradictory ones. Expected outcome: documented scoring behavior that analysts can explain.
-
Test scripts and transliterations. Planning estimate: one working day for an initial set. Difficulty: medium.
Include Cyrillic, Latin variants, reordered names and non-Latin names represented through several transliterations. Expected outcome: visibility into retrieval failures that ordinary typo tests miss.
-
Connect results to a human-review state. Planning estimate: one to three working days, depending on the case system. Difficulty: medium to high.
Store candidates, explanations and reviewer dispositions. Expected outcome: screening results become reviewable signals rather than automated verdicts.
-
Add monitoring and webhook handling. Planning estimate: one to two working days for a basic integration. Difficulty: medium.
Handle duplicate events, retries and changed-record reviews. Expected outcome: existing subjects can be reconsidered after the 6-hour data refresh cycle introduces relevant changes.
-
Export and inspect the audit trail. Planning estimate: 60–90 minutes for an initial control check. Difficulty: low.
Confirm that the CSV contains enough information to reconstruct the query, candidate and disposition. Expected outcome: a defensible record of what the system returned and what the reviewer decided.
Try Denied Party Screening With Real Inputs
KYCWire screens people, companies, vessels and aircraft against 33,381 official-list records in one API. The 200-check free plan is enough to evaluate name variants, identifier priority, result explanations and CSV audit evidence before designing a production workflow.
Screen names against OFAC, EU, UK and UN lists in one API call—200 free checks a month, audit trail included.
FAQ
What is denied party screening?
Denied party screening is the comparison of a person, company, vessel or aircraft against official sanctions and restricted-party records. KYCWire searches 33,381 records across OFAC SDN, OFAC Consolidated, EU, UK and UN lists.
How often should denied parties be screened?
Screen subjects before onboarding or relevant transactions, then monitor them as lists change. KYCWire refreshes list data every 6 hours and supports webhooks for monitored subjects, but each organization must set review timing according to its legal obligations and risk model.
Does a sanctions match mean the customer is prohibited?
No. A match is a signal for human review, not a verdict. Analysts should compare identifiers, aliases, dates of birth, addresses and other attributes, then verify the source record and apply the organization’s legal and compliance rules.
Does denied party screening include PEPs and adverse media?
Not automatically. KYCWire covers official OFAC, EU, UK and UN sanctions lists only; it does not provide PEP or adverse-media data. Those checks require separate sources and controls.
