Build1 publisher3 min readPublished
Shared Starting Letters Score 'Sect of Revolutionaries' 0.85 Against Query 'Sergei Ivanov'
One sanctions screen at threshold 0.7 returned 101 matches with a single exact hit. The organization name that collided with the query scored 0.85, three hundredths below a genuine alias match on a sanctioned relative.
The Engineer · Build desk
What happened
- A screen of the name Sergei Ivanov at threshold 0.7 against OFAC, UN and EU lists returned 101 matches, 50 of them from the OFAC SDN list, 50 from the EU FSF and one from the UN consolidated list.
- Exactly one of the 101 was an exact hit: entity 16688, displayed as Sergei Borisovich IVANOV, scored 1.0 against the alias Sergei IVANOV.
- Entity 34598, Sergei Sergeevich IVANOV, scored 0.88 as a fuzzy match on the alias Sergey IVANOV JR., with a Jaro-Winkler of 0.918 and a Levenshtein ratio of 0.75.
- The entry SECT OF REVOLUTIONARIES came back at 0.85 against the human-name query, with a Levenshtein ratio of 0.154 between the two strings.
- The author ran the screen to settle a threshold argument on a fintech onboarding project, where the compliance officer wanted 0.95 and the product manager wanted 0.65.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint No single cut separates the acronym from the sanctioned relative, so setting this threshold is a choice about which error to absorb.
- cost Every score above the cut becomes a review item, so one common Slavic name at 0.7 hands an analyst 100 fuzzy records to clear by hand.
- decision The include_aka flag governs both the noise and the catch, so trimming alert volume by switching aliases off means giving up the perfect score on entity 16688.
- exposure A zero beside a list the request never queried can pass for clean screening in an audit file, and whoever signs the review carries that reading.
The 0.88 and the 0.85 sit three hundredths apart [2]. Entity 34598, Sergei Sergeevich IVANOV, is described in the post as a related individual under the same Russia program [8]. SECT OF REVOLUTIONARIES is an organization name whose string happens to begin with the same two letters as the query [9]. A reviewer cannot tell those two apart by score. Set the cut at 0.95, as the compliance officer on the team wanted, and both fall below it [3]. Set it at 0.65, as the product manager wanted, and everything stays in the queue [12].
The post gives two accounts of the 0.85. One is the shared "Se" prefix [9]. The other is that the query soundex S621 was close enough to the target soundex S000, with a Levenshtein ratio of 0.154 [10]. Those codes are not the same code [4], so phonetic equality is not what lifted the score. The fuzzy_detail block on the 0.88 record prints a Jaro-Winkler of 0.918, a Levenshtein ratio of 0.75, a soundex pair and a token Jaccard of 0.25 [7]. At least four signals fold into the one number the caller is allowed to threshold. The author wrote of the 0.85 hit: "That's not a name match. That's string matching gone feral." [11]
The clean hit is stranger than it looks. Entity 16688 displays as Sergei Borisovich IVANOV, and the 1.0 was scored against its AKA field, matched value "Sergei IVANOV" [5]. The payload sent include_aka set to True [3]. OFAC entries carry aliases such as Sergei IVANOV, Sergey IVANOV JR. and Sergei MATVIENKO [14]. Turn include_aka off and this record stops matching the query at all.
Before the count of 101 travels anywhere, look at what produced it. The response reported zero matches from UK FCDO and zero from BIS CSL [2], and the request asked for OFAC, UN and EU only [3]; those zeros are counters for lists that were never screened [5]. OFAC returned 50, the EU FSF returned 50, the UN list returned 1, and those three sum to the total [6]. If 50 is a per-list result limit, the number of entries scoring above 0.7 is higher than 101.
The post is headlined on 1,400 tests [15]; the counts examined in it come from one screen of one name at one threshold [1]. What makes any of it auditable is the match_explanation object, which breaks each hit into matched_field, match_type, tokens_matched and fuzzy_detail, and the author wrote that this transparency is the only reason the article exists [13]. For the figure to transfer to another onboarding flow, that flow would need the same list selection, the same alias handling, and a customer name distribution as dense in Slavic patronymics as this query is. Of the 101, one was exact and 100 were fuzzy [1].
What to watch
- Whether the API exposes separate thresholds for person and organization entity types, which would let one cut serve both.
- Whether the vendor documents the match_explanation fields as stable; a review workflow reading fuzzy_detail breaks if jaro_winkler or the soundex pair is dropped.
- Whether the post's 1,400 tests are published with per-threshold false positive counts by entity type.