Explainable Entity Resolution: Confidence Scores, Match Thresholds and Audit Trails (2026)

What makes entity resolution explainable in financial services?

Explainable entity resolution means a team can defend why two records were linked, kept separate or sent for review. The explanation should point to the fields compared, the normalization applied, the rules or model signals used, the score produced, the threshold band selected and the final decision.

The point is not to make every algorithm simple. It is to make the business decision reproducible. NIST's AI Risk Management Framework frames trustworthiness as something built into design, use and evaluation. For entity resolution, that translates into clear evidence for every match decision that affects a regulated process.

This matters because matching is not only a data-cleaning task. A match can decide whether two accounts belong to one customer, whether a counterparty should be grouped with another borrower, whether a sanctions alert is relevant or whether a KYC refresh has enough context. A black-box merge is hard to defend after the fact.

A good explanation has two layers. The technical layer shows record IDs, source systems, transformations, rule IDs, edge labels, match scores and entity versions. The operating layer shows who approved the policy, which threshold was active, what exceptions existed and whether the action was automatic or reviewed.

How should a confidence score be used?

A confidence score should rank how much evidence supports a proposed match. It should not be allowed to become the whole decision. Scores can be excellent for ordering candidates, separating obvious matches from unlikely pairs and routing uncertain cases, but they still need policy context.

The AHRQ record linkage concepts describe probabilistic matching as a process that calculates pair scores, uses cut-off values for automatic accept and reject decisions and leaves a gray area for clerical review. That structure is useful because it treats uncertainty as something to govern, not something to hide.

In Tilores, entity and search responses can expose the resolved entity, records, edges, duplicates, an entity score and a hit score. The Tilores API reference describes score as reflecting the overall quality of matches within an entity, while hitScore indicates how closely a search result aligns with the supplied search parameters.

Keep those meanings separate. Match confidence is not the same as customer risk. Search closeness is not the same as evidence sufficiency. Data completeness is not the same as identity certainty. When the labels are explicit, reviewers can challenge the right thing.

How should match thresholds be set and justified?

Thresholds should be calibrated against the institution's own data, not copied from a vendor slide or a public benchmark. Names, addresses, identifiers, beneficial-owner data and business records behave differently across countries, products and source systems.

Start by defining the decision bands before arguing over numbers. A high-confidence band can allow automatic linking when the evidence is strong and conflict is low. A low-confidence band can reject or keep candidates separate. The middle band should trigger manual review, extra evidence or a source-system correction.

The threshold register should record the threshold value, the field set, the matching method, the intended action, the known failure modes, the sample used for calibration, the reviewer group and the date it became active. It should also record what changed when source data, rules or products changed.

Tilores rules let teams define how records are connected into entities and how search values are compared. The rules documentation describes rule based edges, rule sets and matchers, including cases where a threshold can be defined inside matching logic. That makes the threshold a configured policy object rather than an undocumented side effect.

Use deterministic rules where the evidence really is deterministic, such as a controlled internal ID. Use probabilistic or fuzzy matching where real-world variation exists. Tilores' fuzzy matching tools show why names, addresses and strings need more than exact equality.

What should the audit trail capture for every match decision?

An audit trail should make a future reviewer able to reconstruct the match without guessing. At minimum, it should capture source record IDs, source systems, submitted values, normalized values, fields compared, rule or model version, score, threshold band, decision, decision time, action taken and reviewer or automation path.

It should also capture negative evidence. If records were kept apart because a date of birth conflicted, because a business registration was different or because a policy overrode the score, that reason is as important as a successful match. Regulators and model-risk teams often care most about the exception path.

Tilores entity responses expose records, edges, duplicates and score, while record insights can filter, group and aggregate records inside an entity. The API also supports operations such as disassemble for removing records or edges. In a governed implementation, these events should be retained beside threshold policy and reviewer notes.

The audit trail should not live only in screenshots or tribal knowledge. It should be durable enough to support a compliance review, a customer complaint, a model change, a source-system migration or a post-incident reconstruction.

How does this support KYC, AML and connected-client work?

KYC and AML teams need current context about customers, counterparties and beneficial owners. Entity resolution helps by assembling records that describe the same real-world party before the downstream system makes a screening, review or refresh decision.

The FATF Recommendations remain the global reference point for AML and counter-terrorist-financing standards. They do not tell a bank which matching threshold to use, but they do make clear that customer and risk controls need reliable information. Poor entity resolution weakens that foundation.

Connected-client analysis raises the stakes. The EBA final technical standards on groups of connected clients describe a framework for identifying persons linked by control, economic dependency or combined risk factors. That kind of grouping depends on being able to explain how entities and relationships were formed.

Tilores has already written about connected clients, perpetual KYC and real-time entity resolution for AML and KYC. This article narrows the operating question: how do you defend the confidence score, threshold and audit evidence behind each match?

The clean pattern is to resolve and assemble records during ingestion, then retrieve current resolved context at query time. That gives AML, KYC and exposure workflows a current entity view without forcing every downstream system to rebuild matching logic.

Where should Tilores sit next to MDM, CDP and governance platforms?

Tilores should sit next to MDM, CDP, KYC, AML, warehouse and governance systems. It should not replace them. MDM still owns stewarded master-data processes. A CDP still owns activation and segmentation. KYC and AML tools still own screening, case workflow and regulatory records. Governance platforms still own catalog, policy and lineage controls.

The entity-resolution layer has a different job. It ingests records, applies schema and matching rules, assembles entities and makes the current resolved context available through API queries and events. The Tilores schema documentation describes how input, output and search structures can be customized to match the application. That is what lets the resolved entity layer fit the domain rather than forcing all records into a generic shape.

A practical architecture is simple. Source systems submit records to Tilores. Tilores resolves them into entities during ingestion. Business systems query the entity, search for candidates or consume events. MDM, KYC, AML, CDP and analytics systems then use that resolved context while keeping their own approval and action history.

This separation also improves explainability. If a KYC case asks why two profiles were linked, the answer should not be hidden inside the KYC tool. It should point back to the entity-resolution evidence: source records, rule set, score, threshold band and review decision.

What operating controls keep thresholds defensible in 2026?

Defensible thresholds need operating controls, not only model metrics. The control pack should include versioned schema and rules, documented threshold bands, sample-based validation, exception queues, reviewer guidance, change approvals, monitoring and a rollback or correction path.

BCBS 239 is useful as a governance reference because it focuses on risk data aggregation and reporting capabilities. The BIS page for Principles for effective risk data aggregation and risk reporting emphasizes that banks need to aggregate exposures and identify concentrations fully, quickly and accurately. Entity resolution is one of the data foundations that makes that possible.

Review thresholds when source systems change, when a new product is added, when a data-quality pattern shifts, when reviewer overrides increase or when a false merge affects a regulated decision. The point is not to chase perfect precision. The point is to know which errors the institution accepts, which it does not accept and why.

For regulated teams, the strongest position is usually conservative automation with fast review. Let obvious matches flow. Reject obvious non-matches. Keep the uncertain band visible. Store enough audit evidence that a future reviewer can understand the decision without asking the original analyst what happened.