How a Bank and Its Entity Resolution Vendor Agree on Matching Rules Before a PoC

TL;DR: The business does not write the matching rules. We propose a first rule set from the bank’s own sample data, the business says yes or no on specific edge cases and explains why, and we turn those answers into a revised rule set, over a minimum of two rounds, ending in a configuration the bank keeps.

Book a Demo · Try Tilores Studio (Free)

On this page

1. Why can’t the business just write down the matching rules?
2. What does the rule-tuning process actually look like, round by round?
3. What should a bank ask for when the PoC ends?
4. Where does Tilores fit into this?
5. What should a bank ask a vendor about rule tuning before signing a PoC?
6. Frequently asked questions
7. Sources

A bank’s entity-resolution PoC gets its success criteria written down before anyone has seen the data behave: an agreed precision target, an agreed recall target, a sign-off date. None of that tells the business reviewer what a matching rule actually says, or why one borderline pair should merge and another should not.

That gap is not a training problem. A data governance lead can look at two account records and know, correctly, that they belong to the same customer or to two different people. Writing that judgement down as logic a matching engine can run is a different skill, and not one the business should have to learn mid-PoC.

The working answer is a short, structured exchange between the vendor and the business, repeated over at least two rounds until the rule set holds.

Why can’t the business just write down the matching rules?

A data governance lead who has reviewed thousands of customer records can usually tell a true match from a false one on sight, in much the same way most people recognise a face without being able to describe its exact proportions. Economists have a name for that gap between what someone knows and what they can state as an explicit rule: Polanyi’s paradox, after the philosopher Michael Polanyi’s observation that “we know more than we can tell.”

The same gap shows up inside a bank’s PoC. A reviewer can say, correctly, “these two records are the same customer” or “these two are not” for a specific pair in front of them. Stating the combination of name similarity, address agreement and date-of-birth consistency that makes that true across every other pair in the portfolio is a different task, and one the business was never asked to do before entity resolution turned up as a procurement line.

A workable PoC process does not ask the business to write the rule. It asks the business to keep making the judgement it already makes well, on specific real records, and lets someone else turn the pattern across those judgements into a rule the matching engine can run.

What does the rule-tuning process actually look like, round by round?

The process a bank should expect runs as a fixed cycle, not a one-off handover. Each round narrows the rule set; the bank’s own data decides how many rounds it takes to close the real edge cases, not a template.

The business and the vendor agree one shared rule list before the proof of concept runs.

1. We propose a first rule set from the bank’s own sample data. Normalisation runs first: names, addresses, phone numbers and dates are standardised so the first comparison is like with like. A first deterministic and fuzzy rule set then runs against the bank’s own representative sample, not a generic rule library tuned on someone else’s data.
2. The business reviews specific edge cases and says yes, no or escalate, with a reason. An aggregate precision or recall number does not tell a reviewer which specific pair was wrong or why. The useful review happens at the level of individual candidate pairs, especially the ones that land between the auto-merge and auto-reject thresholds, where the system itself is not confident enough to decide alone.
3. We turn those answers into a revised rule set. Each yes, no or escalate answer, together with the reviewer’s reason, becomes an input to the next revision: a field weight changes, a consistency rule is tightened, a phonetic variant is added. The output is a second rule set, tested against the same sample plus any new edge cases the first round surfaced.
4. The cycle repeats for a minimum of two rounds. One round rarely closes every edge case a real customer base produces. Running the same propose, review, revise sequence at least twice is what separates a rule set tuned to a handful of obvious examples from one that holds up against the messier cases a bank’s own data keeps producing.
5. The bank receives a measured result against the agreed targets. The PoC does not end on a demo. It ends on a measured precision and recall result against the targets the two sides agreed before testing started, plus the rule configuration that produced that result.

One round-two review item shows why the business’s reason, not only the score, is what the vendor needs. A candidate pair scored 0.71, below the auto-merge threshold of 0.85 and above the auto-reject threshold of 0.55, so it waited in the steward queue instead of resolving on its own. Surname and address matched after normalisation. One record was missing a date of birth, so the date-of-birth consistency rule could neither confirm nor block the match, and the two records’ known email addresses were first seen eleven years apart.

A reviewer who answers “merge, because the missing date of birth is a data-entry gap, not a conflict” is giving the vendor a different rule to encode than one who answers “escalate, the age gap this address implies is too wide to assume.” Both answers are defensible on the same 0.71 score. Neither exists until someone with the business context gives it, which is the entire reason the review step exists. A consistency rule like this one is exactly what data-quality practice calls a business rule: DAMA’s research on data quality dimensions, building on the DAMA-DMBOK, defines it as a conformance condition a data value must satisfy, one that has to be agreed explicitly by the people who know the data rather than inferred from the data itself.

Sanctions, PEP and adverse-media matching is one category of edge case worth agreeing explicitly before testing starts, because a false non-match on a politically exposed person carries a different cost than a false non-match on a marketing record. OpenSanctions alone tracks more than 700,000 individual PEP targets across 264 countries, so the volume of near-miss name variants a bank will hit during tuning is not a hypothetical worth leaving until production.

What should a bank ask for when the PoC ends?

A PoC that ends with a demo and a verbal description of “the rules we used” hands the bank a result it cannot independently verify or carry forward. What should leave the PoC with the bank is the configuration itself: the exact rule set, in a form the bank can read, version and re-run outside the vendor’s own session.

We version every rule change in an audit trail, store each match as a graph edge that records the specific rule that created it, and let the bank export the resulting rule configuration instead of keeping it inside a vendor-only interface. Resubmitting a record with the same source ID updates that record in place instead of creating a duplicate, which matters once the tuned rules move from a PoC sample into live, continuous ingestion.

This is also what UK and EU outsourcing rules already expect of a regulated bank, independent of any single vendor’s goodwill. The FCA’s SYSC 8.1 outsourcing requirements require a firm to keep “rights of information, and its right to inspections and access,” not merely a demo of an outsourced function, and the PRA’s SS2/21 and the EBA’s 2019 outsourcing guidelines extend the same expectation of retained oversight to the arrangements a bank depends on. A rule configuration a bank cannot export is a configuration it cannot audit against that standard. The rule set itself is also the kind of model UK regulators already have a framework for: the PRA’s model risk management principles in SS1/23 bring “decision-based rules or algorithms” into scope as models, and expect an independent validation function to give a model’s development and use “ongoing, independent, and effective challenge,” not a one-off sign-off at the end of the PoC.

The same rule set then carries forward instead of resetting. We run one engine and one rule set for PoC-scale and production-scale matching, so the configuration a bank reviewed and tuned during the PoC is the configuration running on day one of production, not a different build started from scratch.

Where does Tilores fit into this?

The rule-tuning conversation above is not a generic PoC formality we describe after the fact. It is how we run every paid proof of concept: propose from the bank’s own sample, review specific edge cases with reasons, revise, repeat for a minimum of two rounds, then hand over a measured result and an exportable, versioned rule configuration.

A bank that wants to see the first round of that process before any PoC conversation starts can run matching locally in Tilores Studio against up to 100,000 of its own records, free, with nothing leaving the machine.

What should a bank ask a vendor about rule tuning before signing a PoC?

A short list of direct questions, asked before a PoC statement of work is signed, separates a vendor that will run the process above from one that will hand back a black box.

• How many refinement rounds are included in the PoC price, and what happens if our data needs more?
• Who proposes the first rule set, and from what sample of our own records, not a generic data set?
• Will specific edge cases be reviewed with reasons, not only an aggregate precision and recall number?
• Is the final rule configuration exportable, versioned and ours to keep, not held inside your interface?
• Does the same rule set and engine carry into production, or does tuning reset at go-live?
• How are our reviewers’ answers logged, so a later audit can see why a specific rule changed?

A vendor that answers all six without hesitation is describing a process it already runs, not one it is inventing for this conversation. Our guide to the seven PoC inputs a bank needs covers the data side of the same PoC; the two guides together cover what to bring and what to ask for.

Frequently asked questions

Does the business need to understand fuzzy matching to take part in rule tuning?

No. The business answers yes, no or escalate on specific record pairs and gives its reason; we turn those answers into the matching logic. Nobody on the business side needs to write a rule.

How many rule-tuning rounds does a Tilores PoC include?

A minimum of two. Most PoCs need the first round to produce a workable draft and a second to close the edge cases that draft missed; a bank can ask for more rounds if its own data keeps surfacing new ones.

Who keeps the rule configuration after the PoC ends?

The bank does. We export the rule configuration, including the audit trail of every rule change, instead of keeping it inside a vendor-only session the bank cannot take away.

Does a PoC-tuned rule set need to be rebuilt for production?

No. We run one engine and one rule set for PoC-scale and production-scale matching, so the configuration tuned during the PoC is the configuration that runs in production.

Can a bank see why two specific records did or did not merge during tuning?

Yes. Every match is stored as a graph edge that records the rule that created it, so a reviewer can trace a specific merge or non-merge back to the rule and the data that produced it.

Sources

1. Tilores: One Resolved Data Layer, Tilores.
2. Tilores Deployment Options, Tilores.
3. Tilores Studio: Download the Free Evaluation, Tilores.
4. Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026, Tilores.
5. How to Evaluate Identity Resolution Vendors for Banking and Regulated Industries, Tilores.
6. Polanyi’s Paradox and the Shape of Employment Growth, David H. Autor, National Bureau of Economic Research Working Paper No. 20485.
7. A Theory for Record Linkage, Ivan P. Fellegi and Alan B. Sunter, Journal of the American Statistical Association, Vol. 64, No. 328 (1969).
8. Overview of Record Linkage and Current Research Directions, William E. Winkler, US Census Bureau Research Report Series.
9. SystemER: A Human-in-the-Loop System for Explainable Entity Resolution, Kun Qian, Lucian Popa and Prithviraj Sen, Proceedings of the VLDB Endowment, Vol. 12, No. 12 (2019).
10. SYSC 8.1: General Outsourcing Requirements, Financial Conduct Authority Handbook.
11. SS2/21: Outsourcing and Third Party Risk Management, Bank of England Prudential Regulation Authority.
12. EBA Publishes Revised Guidelines on Outsourcing Arrangements, European Banking Authority.
13. Politically Exposed Persons Datasets, OpenSanctions.
14. Dimensions of Data Quality (DDQ) Research Paper, DAMA Netherlands, version 1.2, building on the DAMA-DMBOK (DAMA, 2017) and DAMA UK (2013).
15. SS1/23: Model Risk Management Principles for Banks, Bank of England Prudential Regulation Authority.
16. Entity Resolution, Explained, Schmitdy Gadget, YouTube.