Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026

TL;DR: A bank entity resolution proof of concept needs seven PoC inputs: representative source extracts; stable source IDs and provenance; comparison/match fields; confirmed match/non-match/unresolved labels; difficult edge cases; relevant change events; and written acceptance criteria. The bank and vendor should separately agree security controls, output format, the decision statement and the refinement plan before evaluation starts.

Plan your proof of concept with us. Book a Demo · Try Tilores Studio (Free).

On this page

1. Which seven inputs does the PoC need?
2. How should the bank choose representative records?
3. How can the bank protect customer data?
4. Which criteria should be agreed before testing?
5. How should the PoC and refinement process run?
6. What evidence should the bank receive?
7. What else do banking teams ask?

What should an entity resolution PoC prove?

An entity resolution PoC should prove that a bank can make a defined customer identity decision on its own data. The decision could be whether two records belong to one customer, whether a new applicant already exists, or whether historical records can be consolidated before a customer master migration.

The test needs a written boundary. Name the source systems, customer populations, batch or real-time path, and downstream use. A broad goal such as “improve the customer 360” leaves reviewers unable to distinguish a matching result from a mastering, workflow or data-quality requirement.

The evaluation should also reflect the operating consequence of an error. A missed match can fragment a customer view. A false merge can place one person’s financial data inside another person’s profile. That makes precision a privacy control as well as a model-quality measure.

Which 7 PoC inputs does a bank entity resolution PoC need?

A useful input pack combines customer records with the context needed to judge them. Sending a flat file without stable identifiers, labels or evaluation criteria can demonstrate that software runs, but it cannot support a defensible buying decision.

Input	What to provide	Why it matters
1. Representative source extracts	Records from every in-scope source, preserving the variations and missing values found in normal operations.	Cross-source differences often determine whether a configuration works outside a clean demonstration set.
2. Stable source IDs and provenance	A stable source record ID, source-system name and available creation or update metadata.	Every proposed link, correction and rerun must trace back to the record and source that produced it.
3. Comparison/match fields	Names, addresses, dates of birth, phone numbers, email addresses and relevant customer or business identifiers.	Original values preserve spelling, formatting and transliteration patterns needed for normalisation and comparison.
4. Confirmed match/non-match/unresolved labels	Confirmed matches, confirmed non-matches and unresolved cases, with the reason for each available decision.	The PoC needs evidence for both correct links and links that must never form.
5. Difficult edge cases	Name changes, moved addresses, shared households, incomplete dates and duplicate identifiers.	Edge cases expose whether the approach remains explainable and reversible when customer data is difficult.
6. Relevant change events	Updates, deletions, reopenings and other events that affect the in-scope customer records.	Change events test whether the approach remains traceable as customer data changes.
7. Written acceptance criteria	Agreed measures, review roles, output format and exception-handling thresholds for judging the PoC.	Written criteria prevent the evaluation from changing after results are visible.

Tilores supports deterministic, fuzzy and probabilistic matching as distinct methods. The right configuration depends on the evidence available and the bank’s need for explainability. The entity resolution product overview explains how records become traceable entities while source values remain available.

How should a bank choose representative customer records?

A representative sample covers the identity patterns the production system will face. It does not need to reproduce the bank’s full data estate, but it must include every source and variation that could change the decision.

• Source coverage: include records from each CRM, core platform, data warehouse, application channel or archive in scope.
• Value variation: retain abbreviations, transliterations, typographical errors, old addresses, missing fields and conflicting identifiers.
• Positive and negative cases: include known duplicates alongside similar customers who must remain separate.
• Operational states: include updates, deletes and resubmissions when the production use case is continuous.
• Risk cases: include records that test consistency rules, such as a conflicting date of birth or tax identifier.

Do not clean away the problem before evaluation. If every name and address arrives in one standard format, the test no longer measures the normalisation work that production matching requires. Tilores can retain original values alongside normalised values and apply consistency rules that stop an entity forming when an invariant conflicts.

For KYC and customer-mastering use cases, include cases that show how a resolved identity connects to sanctions, politically exposed person and adverse media workflows. OpenSanctions documents entity and identifier structures that can help teams design realistic screening fixtures. The PoC should keep the identity link, screening result and reviewer decision separately traceable.

How can a bank protect customer data during a PoC?

Start with data minimisation. Article 5 of the GDPR requires personal data to be adequate, relevant and limited to what is necessary. The bank should map each requested field to a matching rule, evaluation measure or investigation need. Fields with no role in the test stay out.

Protection must preserve the comparison being tested. Irreversible hashing can work for equality checks on stable values, but a hashed name or address no longer contains the character patterns required for fuzzy matching, transliteration or address normalisation. The bank and vendor should choose masking, tokenisation, encryption or controlled clear-text access field by field. NISTIR 8053 describes the trade-offs involved in de-identifying personal information.

• Purpose: document why each field and record group is included.
• Transfer: agree an approved encrypted route and named recipients.
• Access: restrict the evaluation workspace to authorised participants.
• Retention: record when inputs, outputs and temporary copies will be returned or deleted.
• Deployment: decide where the evaluation will run and how data residency will be handled. Review the available Tilores deployment options in that decision.

Vendor governance starts before production. The US banking agencies’ SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management treats planning, due diligence, contracting, monitoring and termination as connected parts of risk management. A PoC should leave the bank with evidence that can move into those controls.

Which criteria should be agreed before testing starts?

The bank and vendor should write the scorecard before reviewing results. The values belong to the bank’s risk appetite and use case, so a credible vendor should not invent universal thresholds.

Criterion	Question for the scorecard	Evidence to retain
Precision	How often are proposed customer links correct?	Confirmed links, false links and the rule or evidence behind each proposal.
Recall	How many known duplicate relationships are recovered?	Missed links, source patterns and fields that affected the result.
Explainability	Can a reviewer understand why two records linked?	Field comparisons, rule identifiers, normalised values and decision history.
Safety	Which conflicts must block an entity from forming?	Consistency-rule outcomes and difficult negative cases.
Stewardship	Which cases require human review, and how are corrections captured?	Review decisions, reasons, user identity and reversal history.
Operational fit	Can one configuration support the required bulk and real-time paths?	Reproducible requests, outputs and relevant change events.
Portability	Can the bank retain and understand the resulting configuration?	Rules, field mappings and implementation assumptions.

A confidence score alone does not explain a merge. In Tilores, entity links retain the rule identifier that created them. That gives reviewers a path from the resulting entity back to the records and rule involved. The GraphQL API reference covers the interfaces used to search, submit and preview records.

How should the PoC and refinement process run?

The refinement cycle: candidate linking, human review, rule adjustment, rerun and auditable output.

The process should turn business judgement into reproducible configuration. Bank specialists do not need to design fuzzy logic. They need to recognise correct and incorrect customer relationships and explain the evidence they used.

1. Write the decision statement. Define the customer identity decision, affected systems, operating mode and exclusions.
2. Prepare the data pack. Supply the seven PoC inputs: representative source extracts; stable source IDs and provenance; comparison/match fields; confirmed match/non-match/unresolved labels; difficult edge cases; relevant change events; and written acceptance criteria, through the agreed secure route.
3. Agree controls and criteria. Record access, retention, outputs, review roles and acceptance measures before evaluating results.
4. Review links and non-links. Ask business and data specialists to adjudicate proposed matches, rejected candidates and uncertain cases, recording why each correction is needed.
5. Refine and read back the evidence. Convert adjudicated cases into configuration changes, rerun the agreed evaluation set and record the rules, results and audit history.

This loop matters because exceptions reveal structure. A shared address may support a match in one segment and create a dangerous false merge in another. A missing date of birth may require review, while a conflicting date of birth may block the link. Each correction should become a rule, consistency check or documented exception that can be tested again.

What evidence should the bank receive at the end?

The PoC output should be reproducible by someone who did not attend the working sessions. A slide with an aggregate score is too thin for architecture, procurement, privacy and data-governance reviewers.

• the input manifest, field definitions and source lineage;
• the matching and normalisation configuration used in the evaluation;
• linked, unlinked and review-queue results tied to stable record IDs;
• field-level reasons and rule identifiers for proposed links;
• the labelled evaluation set and adjudication history;
• documented data controls, retention status and deletion evidence;
• open limitations, implementation assumptions and the proposed production boundary.

The resulting configuration, field mappings and implementation assumptions should be documented for the bank. The entity event stream publishes merge and split events for integration with the surrounding architecture. This lets the bank evaluate the matching engine without forcing a replacement of its customer-master operating model.

What else do banking teams ask about entity resolution PoCs?

Does a bank need to share its entire customer database?

A Tilores PoC can use a minimised extract that still represents the sources, variations and difficult decisions in scope. The sample must preserve the patterns the engine needs to evaluate, while unnecessary fields and records remain outside the test.

Can customer data be hashed before it is sent?

A Tilores PoC can use protected values where the transformation preserves the required comparison. Irreversible hashing removes the character and structural variation needed for fuzzy matching and normalisation, so the bank and vendor must choose controls field by field.

What labels are needed?

A Tilores PoC benefits from confirmed matches, confirmed non-matches and unresolved cases, each linked to stable source record IDs. Labels should record who made the decision and why, especially where similar names or shared addresses could produce a false merge.

Should sanctions, PEP and adverse media data be included?

A Tilores PoC for KYC or customer mastering should test whether resolved identities connect reliably to sanctions, PEP and adverse media workflows. Keep the screening evidence and identity matching decision distinct so reviewers can trace each result to its source.

What should the bank receive when the PoC ends?

A Tilores PoC should leave the bank with reproducible inputs, the matching configuration used in the evaluation, linked and unlinked results, explanations for each decision, adjudication history and an agreed view of what would move into production.

How can a bank prepare its evaluation?

Start with the decision the bank needs to make, then build the smallest data pack that still represents that decision. Stable identifiers, realistic variation, difficult negative cases and written criteria matter more than a large extract with weak context.

Tilores can help map the use case, data fields, controls and review process into an evaluation plan. Book a Demo to discuss the architecture, or Try Tilores Studio (Free) to begin testing.

Sources

1. Regulation (EU) 2016/679, General Data Protection Regulation, European Union.
2. NISTIR 8053: De-Identification of Personal Information, National Institute of Standards and Technology.
3. SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management, Board of Governors of the Federal Reserve System.
4. OpenSanctions Documentation, OpenSanctions.
5. Entity Resolution Product Overview, Tilores.
6. Deployment Options, Tilores.
7. GraphQL API Reference, Tilores.
8. Entity Event Stream, Tilores API Reference.