The latest articles on Forem by Verifex (@verifex). https://forem.com/verifex https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3845333%2F7b385c48-735c-486f-b496-4d0aa2054973.png https://forem.com/verifex en Verifex Sun, 12 Apr 2026 14:15:31 +0000 https://forem.com/verifex/bank-of-scotland-was-fined-ps160k-for-a-cyrillic-transliteration-failure-heres-the-technical-3h5m https://forem.com/verifex/bank-of-scotland-was-fined-ps160k-for-a-cyrillic-transliteration-failure-heres-the-technical-3h5m <p>In January 2026, OFSI fined Bank of Scotland £160,000. <br> 24 payments went through to a designated Russian individual. <br> Root cause: the screening tool couldn't match Cyrillic <br> transliteration variants.</p> <p>This wasn't negligence. It was a technical failure that <br> most sanctions screening tools still have today.</p> <h2> Why Cyrillic matching fails </h2> <p>There are multiple competing standards for Cyrillic → Latin <br> transliteration: BGN/PCGN (used by US/UK governments), ISO 9, <br> GOST, ICAO, and dozens of informal spellings.</p> <p>A single name like "Шварц" legitimately appears as:</p> <ul> <li>Shvarts</li> <li>Shvartz </li> <li>Schwarz</li> <li>Shvarc</li> <li>Svarc</li> </ul> <p>Every one of them is "correct" — depending on which standard <br> was used. Most screening tools pick one. If the watchlist <br> entry uses BGN/PCGN and the customer's passport uses ICAO, <br> you get a miss. That miss cost Bank of Scotland £160K.</p> <h2> The patronymic problem </h2> <p>Russian names have three parts: given name, patronymic, <br> and surname.</p> <p>"Ivan," "Ivanov," and "Ivanovich" are completely different <br> people:</p> <ul> <li>Ivan → given name</li> <li>Ivanov → surname ("of Ivan")</li> <li>Ivanovich → patronymic ("son of Ivan")</li> </ul> <p>A naive fuzzy matcher sees 70%+ character overlap and scores <br> them as near-matches. This floods compliance queues with <br> false positives while simultaneously missing real hits.</p> <h2> The "Mohammed problem" </h2> <p>Arabic has 12+ formal romanization systems: ALA-LC, ISO 233, <br> UNGEGN, BGN/PCGN, DIN 31635...</p> <p>A single Arabic name produces 300+ valid Latin spellings. <br> "Mohammed," "Muhammad," "Mohamed," "Mehmet," "Muhamad" — <br> same person, different systems.</p> <p>The Beider-Morse algorithm — arguably the most sophisticated <br> phonetic matching system ever built — explicitly removed <br> Arabic support. The maintainers cited "severe performance <br> issues related to excessively complicated phonetics."</p> <p>If the best phonetic algorithm gives up on Arabic, what are <br> most commercial tools doing?</p> <p>Answer: Jaro-Winkler with a threshold. Which is why false <br> positive rates on Arabic names run above 90% in most systems.</p> <h2> The substring trap </h2> <p>"Computing" contains the substring "p-u-t-i-n."</p> <p>Without whole-word boundary enforcement, your screening <br> system flags tech companies. This sounds absurd — but it <br> happens in production systems every day.</p> <p>We caught this when testing our own engine. A query for <br> a software company returned a high-confidence sanctions <br> match because a substring of the company name overlapped <br> with a sanctioned individual's name.</p> <p>The fix: whole-word tokenization. Only match on complete <br> tokens, never on substrings.</p> <h2> What the benchmark gap looks like </h2> <p>No commercial sanctions screening vendor publishes accuracy <br> benchmarks. Not Refinitiv, not ComplyAdvantage, not <br> sanctions.io.</p> <p>OpenSanctions — the best open-source system — publishes <br> their numbers: <strong>91.3% F1, 99% recall, 84.5% precision.</strong></p> <p>The Federal Reserve published a sanctions screening paper <br> in September 2025. Best result using GPT-4o: <strong>98.95% F1</strong> — <br> tested on Latin-script organization names only.</p> <p>Nobody is publishing results on Arabic transliteration, <br> Cyrillic variants, or patronymic edge cases. Exactly the <br> cases that generate real fines.</p> <h2> What we built </h2> <p>We built Verifex (verifex.dev) to address this directly. <br> The matching engine combines:</p> <ul> <li> <strong>Soft TF-IDF + Monge-Elkan</strong> — the academic gold standard for string matching (Cohen, Ravikumar, Fienberg 2003)</li> <li> <strong>IDF corpus weighting</strong> — "Mohammed" and "Kim" are statistically common. They should score lower than rare tokens like "Qadhafi"</li> <li> <strong>Double Metaphone phonetic blocking</strong> — across multiple transliteration standards simultaneously</li> <li> <strong>9 penalty layers</strong> — patronymic derivatives, substring boundaries, entity-type mismatches, mixed-script detection</li> <li> <strong>LLM cascade</strong> — for ambiguous matches in the 40-95% confidence range</li> </ul> <p>Result: <strong>100% F1 on an independent 145-case benchmark</strong> — <br> including Arabic transliteration, Cyrillic variants, phonetic <br> matching, and adversarial substring inputs.</p> <p>The full benchmark is public: <strong>verifex.dev/benchmark</strong></p> <p>Anyone can run it against any provider.</p> <p><em>Bank of Scotland's fine was preventable. The technology <br> to handle Cyrillic transliteration exists — it's just not <br> in most commercial tools. If you're building or evaluating <br> a sanctions screening solution, the benchmark cases at <br> verifex.dev/benchmark show exactly where most tools fail.</em></p> webdev fintech api security Verifex Sat, 11 Apr 2026 20:43:22 +0000 https://forem.com/verifex/how-we-built-a-sanctions-screening-api-that-outperformed-the-federal-reserves-benchmark-57m2 https://forem.com/verifex/how-we-built-a-sanctions-screening-api-that-outperformed-the-federal-reserves-benchmark-57m2 <p>The Federal Reserve published a sanctions screening <br> benchmark in September 2025. Their best result using <br> GPT-4o: 98.95% F1.</p> <p>We hit 100%. Here's how.</p> <h2> The problem with existing tools </h2> <p>90-95% of sanctions screening alerts are false positives.<br> Analysts spend $130B/year investigating alerts that are wrong.</p> <p>The root cause: basic fuzzy matching. Most tools use <br> Jaro-Winkler with a threshold. That's it.</p> <h2> What we built </h2> <p>9 penalty layers targeting specific false positive patterns:</p> <ul> <li>Patronymic derivatives (Ivan ≠ Ivanov)</li> <li>Business-to-person mismatch</li> <li>Substring traps ("Computing" contains "Putin")</li> <li>Common name IDF weighting</li> <li>Mixed-script rejection</li> <li>Zero-width character evasion detection</li> </ul> <h2> The matching pipeline </h2> <ol> <li>Normalization → smartNormalize()</li> <li>FAISS MiniLM semantic ANN search</li> <li>Jaro-Winkler + Monge-Elkan + Soft TF-IDF</li> <li>Double Metaphone phonetic blocking</li> <li>9 penalty layers</li> <li>LLM cascade (40-85 confidence range)</li> <li>Adjudication engine</li> </ol> <h2> The benchmark </h2> <p>145 real test cases across 13 categories:</p> <ul> <li>OFAC, UN, EU, UK sanctions lists</li> <li>Arabic/Cyrillic transliteration</li> <li>Phonetic matching</li> <li>Substring traps</li> <li>Adversarial inputs</li> </ul> <p>Result: 145/145. 100% F1, 100% Recall, 100% Precision.</p> <p>The Federal Reserve tested organization names only, <br> Latin script only, 10 countries. They explicitly noted <br> individual names and non-Latin scripts were <br> "beyond the scope."</p> <p>That's exactly what we tested.</p> <h2> The dataset is public </h2> <p>verifex.dev/benchmark</p> <p>Anyone can run it against any provider.</p> <p>We're Verifex — sanctions screening API for developers.<br> $49/month. verifex.dev</p> fintech api webdev security