Entity Resolution Buyer's Guide: API-Native vs On-Prem vs Open Source (2026)

TL;DR: Choosing an entity resolution platform in 2026 comes down to five decisions: deployment model (API-native, on-premises, or open source self-hosted), latency profile (real-time at query time versus nightly batch), matching approach (deterministic plus probabilistic), explainability depth, and data-residency obligations. Use the scorecard table below to apply these criteria to any vendor before you shortlist.

What criteria actually separate entity resolution platforms in 2026?

Entity resolution is the process of deciding whether two records refer to the same real-world entity despite variations in name, address, or identifier. Every credible platform today combines deterministic rules (exact field agreement) with probabilistic matching (weighted scoring across partial signals). What separates vendors in 2026 is not whether they do both, but how they expose those capabilities across six operational dimensions: deployment model, latency profile, explainability, regulated-use readiness, data residency, and total cost of ownership. The scorecard below forces explicit decisions on each, rather than letting vendor marketing collapse them into a single claim.

API-native, on-premises, or open source: which deployment model fits your team?

Deployment model is the first filter because it determines everything downstream: who owns the infrastructure, who handles scaling, and where data physically travels.

API-native (cloud-hosted SaaS): The vendor runs the matching engine. Your team calls an endpoint. Setup is fast. Scaling is automatic. The trade-off is that your records cross into a third-party environment, which is problematic for some data classifications and for customers in the EU, APAC, or highly regulated sectors. You also depend on the vendor’s uptime and schema.

On-premises or private-cloud deployment: The engine runs in your VPC or data centre. Records never leave your perimeter. This is the architecture of choice for banks, insurers, and government agencies with strict data-sovereignty requirements or where customer data cannot legally reside on a third-party service. The cost is that your team owns provisioning, patching, and scaling. Some vendors offer this as a separate SKU; others are built specifically for it.

Open-source self-hosted: Frameworks like Splink (UK Cabinet Office, Apache licence) let you run probabilistic record linkage without a license fee. The matching logic is transparent and auditable. The real cost is engineering: you own model configuration, threshold calibration, performance tuning, scaling infrastructure, and ongoing maintenance, as our reproducible Splink vs. Tilores benchmark illustrates. For teams that need fine-grained control over the matching model and have the engineering capacity to support it, open source is a serious option. For teams that need operational reliability and real-time latency without a dedicated ML-ops capability, it is usually not the right choice.

A fourth pattern is gaining traction in 2026: deploy-in-own-environment commercial platforms. These run inside your VPC, combining commercial operational reliability with the data-sovereignty guarantees of on-prem. The engine deploys into your environment; the vendor manages the software but not your data.

Real-time vs batch: when does the latency profile actually matter?

Entity resolution involves two distinct phases, and confusing them leads to poor purchasing decisions.

Resolution at ingestion is the process of assigning an incoming record to an existing entity cluster, or creating a new cluster, as data arrives. This is a write-time operation. Batch systems do this in scheduled runs; typically nightly or hourly. The resolved state you query is always slightly stale.

Retrieval at query time is the process of returning the current resolved context for an entity when a downstream system or user asks for it. This is a read-time operation. A real-time system resolves at ingestion and makes the result available immediately for retrieval.

The practical question is: what is the cost of stale resolution in your use case?

Customer onboarding and KYC: stale resolution is a compliance risk. If a new account arrives that matches a sanctioned entity, and the resolution batch does not run until midnight, you have an exposure window. Real-time resolution at ingestion is required.
Fraud detection: the same logic applies. A transaction linked to a known fraud ring needs to be flagged immediately, not after the next batch run.
Customer-360 analytics and marketing: a lag of hours or even a day is usually tolerable. Batch resolution is appropriate, and its lower operational complexity is an advantage.
AI assistant and RAG pipelines: if a large language model is retrieving entity context to answer questions about customers, the resolution must be current at retrieval time. Stale resolved context produces confident-sounding wrong answers.

See our analysis of real-time entity resolution for AML and KYC for a detailed treatment of the compliance-latency trade-off in regulated onboarding.

What does “explainable matching” mean in practice, and why do compliance teams require it?

A match decision is explainable when a human reviewer can see exactly which fields agreed, which were fuzzy, what weights were applied, and what the resulting confidence level was. The alternative is a system that returns a binary match or a score with no supporting evidence.

For compliance teams, explainability is not a nice-to-have. Financial regulators expect institutions to explain automated decisions affecting customer risk ratings, and a black-box score does not satisfy that requirement. Sanctions screening produces false positives: a reviewer needs to see which fields matched and at what weight before they can clear an alert. When threshold recalibration is needed after a data-quality change, systems that expose field-level match evidence are far easier to govern than those that do not. Deterministic rules are inherently explainable; probabilistic matching requires surfacing the feature weights and individual field scores. Both are achievable, but not all platforms implement the probabilistic case at the field level.

Precision and recall trade-offs in entity resolution are directly connected to this: explainability lets you trace whether a threshold change is producing better precision or better recall, and for which record types.

What does the scorecard look like for evaluating any entity resolution vendor?

Use this table as a starting framework. Score each vendor on a scale of 1 (absent or weak), 2 (partial), or 3 (strong) per criterion. Add weighting columns for your specific context.

Criterion	What to evaluate	Regulated fintech / KYC	Data engineering / analytics
Deployment model	Can it run in your environment? Does data cross the vendor’s perimeter?	Critical (must be in-environment or on-prem)	Moderate (SaaS acceptable if data classification allows)
Real-time resolution at ingestion	Does the entity cluster update when a new record arrives, or only in batch?	Critical	Low (batch usually sufficient)
Real-time retrieval at query time	Can downstream systems query current resolved state via API without delay?	Critical	Moderate
Deterministic AND probabilistic matching	Does it support both exact rules and fuzzy/weighted scoring? Are thresholds configurable?	Critical	Critical
Explainability (field-level evidence)	Does each match decision expose contributing fields, weights, and confidence?	Critical	Moderate
Sanctions / PEP / adverse-media screening	Native integration with lists like OpenSanctions? Alert workflow for hits?	Critical	Not applicable for most
Data residency controls	Can you lock data to a specific region or jurisdiction? GDPR Article 25 data-by-design support?	Critical (EU AI Act / GDPR)	Moderate
API-first developer experience	REST or GraphQL API? SDK quality? Time to first integration?	High	High
MDM / CDP / warehouse integration	Does it complement your existing data stack, or try to replace it?	High	High
Total cost of ownership	Engineering hours to operate, maintain thresholds, and handle schema changes	Moderate	Critical (often underestimated for open source)

How should regulated buyers approach sanctions, PEP, and adverse-media screening?

Sanctions screening is a specific application of entity resolution with additional requirements. The core task is comparing an incoming entity (a new customer, a transaction counterparty, a beneficial owner) against curated lists of sanctioned individuals, politically exposed persons, and entities with adverse-media coverage. The resolution challenge is that list entries and customer records rarely match exactly: names are transliterated, dates of birth are partial, aliases are common.

A capable platform needs to handle all of the following:

Fuzzy name matching across transliteration variants and aliases, not just exact string comparison.
List currency: sanctions lists update continuously. The OFAC SDN list, UN consolidated list, EU consolidated list, and open-source lists like OpenSanctions all have different update frequencies. The platform must keep pace.
Alert explainability: regulators expect an institution to document why an alert was raised and why it was cleared. Field-level match evidence is required for defensible alert disposition.
False-positive rate: high false-positive rates impose significant operational cost on compliance teams. Threshold calibration and the quality of probabilistic matching directly affect this.
Audit log: every screening decision, including clears and escalations, must be logged with timestamp and the resolved evidence at the time of the decision.

PEP screening adds ongoing monitoring: a customer who was not a PEP at onboarding may become one. This requires a platform that can re-resolve entities against updated lists, not just screen at ingestion. GDPR Article 25 adds a further consideration: data protection by design requires purpose limitation, so a resolution system that enriches records beyond what the screening purpose requires may create exposure. Platforms that let you scope the data used in each resolution context have an advantage here.

What is the real total cost of ownership for open-source entity resolution?

Open-source frameworks like Splink are a legitimate option for teams with significant ML-ops capacity. The license cost is near-zero and the matching logic is auditable. The costs typically underestimated are: threshold calibration (probabilistic matching requires recurring ground-truth labelling as data quality shifts), infrastructure ownership (provisioning, scaling, patching), adding real-time ingestion on top of frameworks designed for batch, and custom instrumentation to generate the field-level audit trails that regulators expect. For most production use cases requiring real-time resolution and compliance audit trails, the full TCO of open source exceeds commercial alternatives. For a ranked comparison, see our guide to entity resolution tools for enterprises in 2026.

Where does Tilores sit in this landscape?

Tilores is an API-native entity resolution platform that deploys in your own environment. Records are resolved at ingestion using both deterministic and probabilistic matching, and the current resolved entity context is retrievable at query time via API. It is designed to sit alongside existing MDM, CDP, KYC-AML, and data-warehouse infrastructure, not replace it. The deploy-in-own-environment model means data does not leave your perimeter, and field-level match explainability means each decision is auditable.

Where Tilores is not the complete answer: it is a resolution and retrieval layer, not a native sanctions-list provider. For sanctions and PEP screening, buyers pair it with a list source such as OpenSanctions or a commercial provider. For the broader architecture of entity resolution inside AI and RAG pipelines, see our IdentityRAG guide.

Buyer checklist: six questions for any shortlist conversation

Where does the matching engine run, and do records cross your environment boundary?
Is resolution performed at ingestion (and immediately available for retrieval), or only in batch?
Does the platform support both deterministic and probabilistic matching with configurable thresholds?
Does each match decision expose field-level evidence for audit and alert-disposition workflows?
For regulated buyers: what is the audit-log format, and does it satisfy your regulatory requirements?
What is the total engineering cost to integrate and maintain the platform over 12 months, beyond the license?

FAQ

What is the difference between deterministic and probabilistic entity resolution?

Deterministic matching uses exact or near-exact rules: two records match if specified fields agree exactly (for example, same national ID number). Probabilistic matching assigns weighted scores across multiple fields, so partial name agreement plus address agreement plus date-of-birth proximity can collectively produce a confident match even when no single field is definitive. Most production platforms use both: deterministic rules for high-confidence cases, probabilistic scoring for the ambiguous remainder.

Should I choose an API-native or on-premises entity resolution platform?

If your records contain personal data governed by GDPR, financial data subject to banking secrecy, or any data classified as sensitive under your organisation’s policies, an on-premises or deploy-in-own-environment model is usually the right choice. It keeps records inside your perimeter. If your data classification allows third-party processing, API-native SaaS offers faster setup and lower operational overhead. The choice is primarily a data-governance decision, not a technical one.

What is real-time entity resolution and when is it required?

Real-time entity resolution means that when a new record arrives, it is immediately resolved against existing entity clusters, and the updated resolved context is available for retrieval within milliseconds. It is required for use cases where stale resolution creates risk: customer onboarding and KYC (where a delay in identifying a sanctioned entity creates compliance exposure), real-time fraud detection, and AI applications where a language model retrieves entity context at query time and needs current data.

How do sanctions screening and entity resolution relate?

Sanctions screening is a specific application of entity resolution: comparing an incoming entity against curated lists of sanctioned individuals and organisations. The resolution challenge is that names, aliases, and identifiers rarely match exactly across lists and customer records. A capable entity resolution platform applies fuzzy matching and probabilistic scoring to reduce false negatives (missed sanctioned entities) while explainability and threshold controls reduce false positives (unnecessary alerts). The list source (such as OpenSanctions, OFAC, or a commercial provider) is separate from the resolution engine.

What is the total cost of ownership for open-source entity resolution frameworks?

The license cost is typically zero, but the engineering cost is substantial. You own infrastructure provisioning and scaling, threshold calibration (a recurring data-science task), generating regulatory audit trails, and any real-time capability beyond what the framework natively provides. Teams with dedicated ML-ops capability and no real-time latency requirement are the best fit for open source. For most production use cases requiring real-time resolution, compliance audit trails, and operational reliability, the full TCO of open source exceeds commercial alternatives.

How does entity resolution differ from MDM or a CDP?

Master data management and customer data platforms manage a curated golden record: a single authoritative view of an entity with defined governance workflows. Entity resolution is the underlying matching and clustering layer that decides which records belong to the same entity. They are complementary: entity resolution feeds the MDM or CDP with the matching decisions it needs to maintain the golden record. A resolution platform sits alongside your existing MDM or CDP rather than replacing it.

What data-residency questions should I ask an entity resolution vendor?

Ask: where does the matching engine run? Do records leave my environment during processing? Is the data stored, and if so where and for how long? Can I specify a region or jurisdiction? For EU buyers, relevant considerations include GDPR Article 25 (data protection by design) and any sector-specific data localisation requirements. A deploy-in-own-environment model eliminates the cross-boundary transfer question by keeping records inside your perimeter throughout the resolution lifecycle.

How do I evaluate explainability in an entity resolution platform?

Request a sample match response and verify that it includes: the list of fields that contributed to the match decision, the weight or score assigned to each field, the overall confidence level, and a unique decision ID that links to an audit log. If the response contains only a match boolean or an aggregate score without field-level evidence, the platform does not provide defensible explainability for compliance or audit purposes. For regulated use cases, this should be a hard filter, not a preference.