The Fellegi-Sunter model formalizes entity resolution by calculating the likelihood ratio for each record pair. It compares agreement and disagreement patterns across multiple fields—such as name, address, and date of birth—assigning weights based on the probability that a matching field indicates a true match (m-probability) versus random chance (u-probability). This produces a composite match weight.
Glossary
Fellegi-Sunter Model

What is Fellegi-Sunter Model?
The Fellegi-Sunter model is the foundational statistical framework for probabilistic record linkage, classifying record pairs as matches, non-matches, or potential matches based on agreement pattern likelihood ratios.
Pairs are classified into three zones using upper and lower decision thresholds. Pairs scoring above the upper threshold are designated matches, those below the lower threshold are non-matches, and those falling between are potential matches requiring clerical review. This triage mechanism minimizes both false positives and false negatives, forming the statistical backbone of modern entity resolution and synthetic identity detection systems.
Key Components of the Fellegi-Sunter Model
The Fellegi-Sunter model decomposes the record linkage problem into a rigorous statistical decision framework. Each component quantifies the evidence for or against a match, enabling automated classification at scale.
Agreement Pattern Vector
The foundational data structure representing the outcome of comparing two records across multiple fields. For each field i, a binary or categorical value indicates whether the values agree, disagree, or are missing.
- Binary vector: 1 for agreement, 0 for disagreement
- Example: Comparing (John, Smith, 1980) with (Jon, Smith, 1980) yields the vector [0, 1, 1]
- Missing data: A third state is often introduced to handle null values without penalizing the match score
- The vector is the sole input to the likelihood ratio calculation
M-Probability (Match Parameter)
The conditional probability that a field agrees given that the record pair is a true match. It quantifies the reliability of the data source.
- Formula: m = P(field agrees | true match)
- Interpretation: An m-probability of 0.95 for surname means that 95% of true matches will have the same surname
- Error source: The complement (1 - m) accounts for typographical errors, name changes, or data entry mistakes within legitimate matches
- Estimation: Typically initialized using expectation-maximization (EM) algorithms on unlabeled data
U-Probability (Non-Match Parameter)
The conditional probability that a field agrees purely by random chance given that the record pair is not a true match. It represents the background noise of the dataset.
- Formula: u = P(field agrees | non-match)
- Interpretation: A u-probability of 0.001 for a rare surname means only 0.1% of non-matching pairs will coincidentally share it
- Discriminative power: Fields with low u-probabilities (like Social Security Numbers) are highly informative; fields with high u-probabilities (like gender) contribute little weight
- Estimation: Often approximated by the frequency distribution of values in the overall dataset
Likelihood Ratio (Weight)
The ratio of the m-probability to the u-probability for a given field, expressed as a log-weight for computational stability. This is the core evidentiary unit of the model.
- Agreement weight: log₂(m/u) — positive weight supporting a match
- Disagreement weight: log₂((1-m)/(1-u)) — negative weight against a match
- Additive property: Total match weight is the sum of individual field weights, assuming conditional independence
- Example: An SSN agreement might contribute +30 to the weight, while a gender agreement contributes only +1
Decision Thresholds
Two fixed cutoff values that partition record pairs into three exhaustive and mutually exclusive classes, enabling automated decision-making without manual review for the majority of pairs.
- Upper threshold (T_μ): Pairs with composite weight above this are classified as definite matches
- Lower threshold (T_λ): Pairs with composite weight below this are classified as definite non-matches
- Clerical review zone: Pairs falling between the thresholds are flagged as potential matches requiring human adjudication
- Optimal thresholds: Chosen to minimize a cost function that penalizes both false positives and false negatives
Expectation-Maximization Estimation
The iterative algorithm used to estimate the unknown m and u parameters from unlabeled data when no ground-truth training set of known matches exists.
- E-Step: Calculate the posterior probability that each record pair is a match, given current parameter estimates
- M-Step: Re-estimate m and u parameters by maximizing the expected log-likelihood derived from the E-step
- Convergence: The algorithm iterates until parameter changes fall below a tolerance threshold
- Latent variable: The true match status is treated as an unobserved variable, making this a classic unsupervised learning application within the model
Frequently Asked Questions
Explore the foundational concepts of the Fellegi-Sunter model, the statistical framework that powers modern entity resolution by mathematically quantifying the likelihood that two records refer to the same real-world entity.
The Fellegi-Sunter model is a probabilistic record linkage framework that classifies record pairs as matches, non-matches, or potential matches by calculating likelihood ratios based on field agreement patterns. It works by comparing a set of common attributes—such as name, date of birth, and address—across two records and assigning a match weight to each field. The model computes the ratio of the m-probability (the probability that a field agrees given the pair is a true match) to the u-probability (the probability that a field agrees by random chance). These weights are summed to produce a composite score, which is then compared against two thresholds: an upper threshold for automatic acceptance and a lower threshold for automatic rejection. Pairs falling between these thresholds are flagged for clerical review, making the model highly efficient for large-scale identity resolution tasks.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
The Fellegi-Sunter model is the statistical backbone of modern identity resolution. These related concepts form the complete toolkit for detecting synthetic identities in financial systems.
Fuzzy Matching
The string comparison techniques that feed similarity scores into the Fellegi-Sunter likelihood calculations. These algorithms quantify how close two text strings are, tolerating the typographical errors and formatting inconsistencies common in real-world identity data.
- Levenshtein distance: Edit-based metric counting insertions, deletions, and substitutions
- Jaro-Winkler similarity: Optimized for short strings like names, giving higher weight to matching prefixes
- Phonetic algorithms like Soundex and Metaphone encode names by pronunciation, catching spelling variations that edit-distance metrics miss
Identity Clustering
The unsupervised machine learning step that follows pairwise matching. Once the Fellegi-Sunter model assigns match probabilities to record pairs, clustering algorithms group these pairs into disjoint identity clusters representing distinct real-world individuals.
- Transitive closure: If record A matches B, and B matches C, then A, B, and C form a single cluster
- Graph-based approaches model records as nodes and match scores as weighted edges, applying community detection algorithms
- Critical for detecting synthetic identity rings where multiple fabricated identities share overlapping attributes
Privacy-Preserving Record Linkage
Cryptographic protocols that enable the Fellegi-Sunter methodology to operate across organizational boundaries without exposing plaintext personally identifiable information. Essential for collaborative synthetic identity detection between financial institutions.
- Bloom filter encoding: Converts identity attributes into irreversible bit arrays that still support fuzzy matching via set-based similarity metrics like Dice coefficient
- Secure multi-party computation: Allows multiple parties to jointly compute match probabilities without revealing their private inputs
- Enables federated fraud detection while maintaining compliance with data privacy regulations

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us