Engine v3
Matching methodology.
How Verifex transforms a name into a calibrated decision: normalisation, candidate generation, scoring, penalty filtering, calibration, and structured explainability.
Stage 0
Input sanitisation & normalisation
Before any comparison, the input is inspected for evasion techniques, cleaned, parsed into typed components, and normalised for cross-script equivalence.
Evasion detection
Strips zero-width characters, detects homoglyph attacks, rejects mixed-script inputs, and flags nonsense queries designed to bypass screening.
Transliteration
Arabic, Cyrillic, Greek, and Chinese names are converted to Latin equivalents using language-aware rules. Diacritics are normalised for canonical comparison.
Token role classification
Names are parsed into semantic components — given name, surname, patronymic, honorific, suffix, particle — with language-specific rules for Azerbaijani, Russian, Arabic, and Chinese naming conventions.
Unicode normalisation
NFKC canonical equivalence ensures that visually identical characters are compared as identical, regardless of how they were encoded.
Stage 1
Candidate generation
Four matchers run in parallel to maximise recall. Each produces candidates with an initial confidence and match type.
Exact matching — 5 strategies
Exact matches are the fastest and highest-confidence path. Five strategies cover full names, aliases, token reordering, word-boundary containment, and distinctive single tokens.
Exact match after full normalisation pipeline. Highest-confidence path.
Matches against known aliases and alternate name forms after normalisation.
Handles name-order variations (e.g., Western vs. Eastern order) by comparing token sets.
Word-boundary containment check for cases where the query is a substring of a longer sanctioned name.
Flags rare or distinctive single tokens that are strong match indicators even without full name context.
Fuzzy matching — hybrid retrieval
A composite fuzzy score combines multiple string-similarity metrics with role-aware constraints that prevent given-name-to-surname false positives. Hybrid retrieval (semantic + lexical + orthographic) ensures high recall without sacrificing precision.
Phonetic matching
Double Metaphone and Soundex on significant tokens catch transliteration variants that purely orthographic metrics miss — e.g., "Putin" vs. "Poutine".
Identifier matching
Direct lookup for crypto addresses and ID document numbers bypasses the name pipeline entirely. When an identifier hits, confidence is near-certain.
Stage 2
Scoring & penalty layers
Matches are scored and then passed through a multi-layer heuristic safety system refined against real false-positive patterns observed in production.
Generic query suppression
Heavily penalises overly generic inputs that would otherwise flood analysts with false positives.
Context noise reduction
Down-weights matches where contextual signals (DOB, country) are weak or contradictory.
Substring trap prevention
Caps confidence on partial substring matches to prevent flagging names that merely contain a sanctioned token.
Name rarity calibration
Adjusts confidence based on name frequency — common names require stronger evidence; rare names need less.
Entity-type consistency
Penalises matches between different entity types (person vs. organisation) unless explicitly overridden.
Candidate overload protection
Reduces confidence when an unusually large number of candidates are returned, signalling low specificity.
Distinctive overlap gating
Requires meaningful token overlap; matches on generic terms alone are suppressed.
First-name contradiction
Strongly down-weights matches where given names are clearly different.
Patronymic handling
Recognises patronymic derivatives and applies appropriate confidence adjustments.
Well-known company filtering
Prevents false positives on widely known company names that happen to overlap with sanctioned entities.
Surname absence gating
Applies stricter thresholds when surname information is missing or ambiguous.
Common-name evidence requirements
Requires stronger supporting evidence for very common names (e.g., Mohammed, Kim, Smith).
Company evidence requirements
Organisation matches require additional corroborating signals before reaching high confidence.
Fellegi-Sunter contextual scoring
Context signals (DOB, country, entity type) are weighted using probabilistic agreement models from record-linkage theory. Rare signals (exact DOB) contribute more than common ones (country match). Contradictions are weighted more heavily than agreements — a country mismatch is a stronger signal than a weak DOB match.
Date of birth
Exact, year-month, or year-only matches contribute probabilistically based on population rarity.
Country
Country agreement strengthens confidence; mismatch is a stronger negative signal than weak positive DOB.
Entity type
Type mismatch (person vs. organisation) is treated as a hard structural contradiction.
Stage 3
v3 probabilistic comparison levels
Engine v3 uses ordered comparison levels with probabilistic weights accumulated into a total score, then passed through a calibrated sigmoid to produce a well-calibrated confidence percentage.
The calibration pipeline uses temperature scaling optimised via grid-search minimisation of Expected Calibration Error (ECE) on labelled cases. The result: confidence scores that are meaningfully probabilistic — a 90% score means approximately a 90% chance of being a true match, not merely a rank ordering.
Stage 4
Calibration & thresholds
Raw scores are calibrated and mapped to actionable recommendations based on confidence bands tuned against production false-positive patterns.
Low confidence or heavily penalised matches. No human review required.
Moderate confidence. Match context provided for analyst review.
High confidence. Elevated review recommended before action.
Very high confidence on sanctions source. Immediate escalation pathway.
Based on published 500-case benchmark (Engine v3). 3 false negatives are documented and inspectable. View the benchmark →
Stage 5
Evidence & explainability
Every match produces a structured Evidence Capsule — a deterministic, auditable snapshot of the decision with positive, negative, and neutral evidence buckets.
Positive evidence
Surname exact match, given name exact, DOB exact, country match, identifier exact
Negative evidence
Surname mismatch, DOB hard contradiction, entity type mismatch, country mismatch
Neutral / missing
Context fields absent, approximate source data, incomplete identifiers
Add explain: true to any screening request and every match returns a structured explainability object with calibrated confidence, per-field contributions, threshold reasoning, and an evidence summary.
Honesty
Known limitations
The benchmark is vendor-authored and self-administered. It should not be read as an independent audit.
Production data has long-tail edge cases not captured by any finite benchmark.
Cross-script transliteration is improved but not solved. Some valid transliterations may be missed.
Common names (Mohammed, Kim, Smith) generate near-matches at low confidence that are intentionally tolerated to protect recall.
v3 weights are hand-tuned, not trained on labelled data. Source-family priors are provisional placeholders.
Calibration requires ≥1,000 labelled production cases for statistical meaningfulness.