A Fundable Customer Master Business Case for a Smaller Bank

TL;DR: A smaller bank can make a customer master fundable by narrowing the first decision: one shared identity layer, four concrete use cases, a labelled evaluation set, measurable precision and recall targets, and funding released in stages. The committee approves evidence and control, not a transformation promise.

Book a Demo · Try Tilores Studio (Free)

On this page

1. What should the committee approve?
2. Which four use cases belong in the case?
3. How should funding be staged?
4. Which measures make the case credible?
5. How should governance shape the case?
6. What architecture keeps scope under control?
7. How should the bank compare build and buy?
8. What should go into the committee pack?
9. FAQ

What should the funding committee approve?

The committee should approve a sequence of bounded decisions, not a promise to create a perfect customer record across the whole bank. The first request is permission to prove that a shared identity layer can reduce a small set of known costs and risks without taking ownership away from source systems or established governance.

That framing matters for a smaller institution. A broad master data programme can quickly collect every data quality complaint, integration wish and reporting dependency in the bank. The resulting proposal becomes too large to price confidently and too vague to measure. A fundable case starts with a customer identity problem that can be tested on representative records and observed in an existing workflow.

The proposal should name an executive sponsor, a business owner, a technical owner and a control owner. It should define which customer population is in scope, which source systems contribute records, what action the resolved identity will support and what remains explicitly outside the first stage. Credit decisioning, transaction monitoring, identity verification and case management should remain with the systems and teams already accountable for them.

The committee is therefore deciding whether to fund evidence. It is not being asked to accept a final architecture, an untested accuracy claim or an irreversible migration.

Which four use cases belong in the case?

Use cases should share the same underlying need to recognise one customer across inconsistent records, while producing different operational value. This creates leverage without pretending that every workflow should use the same decision threshold.

Use case	Decision improved	Baseline to capture	First-stage evidence
Duplicate checks at account opening	Whether an applicant may already exist in the customer estate	Current search effort, duplicates found later and referrals caused by uncertain matches	Known duplicate and non-duplicate pairs tested before any automated action
Customer servicing	Which records an authorised colleague should inspect together	Average search time, hand-offs and corrections caused by fragmented records	A resolved view that links source records while preserving provenance
Screening preparation	Which customer identity and aliases should be passed to existing controls	Repeat searches, avoidable false alerts and manual identity assembly	A consistent identity package passed to sanctions, PEP and adverse media workflows
Management and risk reporting	How customer populations should be counted and reconciled	Manual reconciliation effort, disputed counts and unresolved differences	Repeatable entity counts with traceable source records and match evidence

These are four uses of one governed identity configuration, not four separate master data platforms. Each workflow can consume the same resolved customer boundary while applying its own confidence threshold, human review rule and downstream permissions.

Keep sanctions, PEP and adverse media in the committee pack as distinct governed workflows. The customer master can make identity inputs more consistent and explainable, while the existing control owners retain their rules, sources, decisions and accountability.

How should funding be staged?

Stage funding around uncertainty. Release enough budget to answer the next material question, then return with observed results. Four gates are usually sufficient to distinguish discovery, technical evidence, operational evidence and expansion.

1. Approve discovery

Confirm the four use cases, in-scope systems, owners, current process costs and representative evaluation records. Record known matches, known non-matches and difficult edge cases. Agree how personal data will be minimised and protected in the evaluation.

2. Approve a controlled evaluation

Test the same labelled records against the shortlisted approach. Measure precision and recall separately for each use case. Inspect false positives and false negatives by segment, source and match rule. The output is a decision pack, not a production integration.

3. Approve one limited production use case

Choose the use case with the clearest value and safest action boundary. Add monitoring, access controls, human review and rollback. Preserve the original records and the evidence behind every link so that a steward can understand and challenge the result.

4. Approve expansion

Add the remaining workflows only after the first one meets its quality, control and operating-cost gates. Reuse the identity configuration where appropriate, but recalibrate thresholds when the consequence of an incorrect link changes.

This sequence protects both sides of the decision. The bank avoids committing to a large programme before match quality is known, while the implementation team receives enough scope to prove value on real data rather than a polished demonstration.

Which measures make the case credible?

A committee needs targets, but invented universal thresholds make a proposal weaker. Set targets after measuring the bank’s starting point and label every early number as illustrative until the evaluation confirms it.

Precision answers: of the record links proposed, how many were correct? Recall answers: of the links that should have been found, how many were found? A high-precision configuration can still miss too many genuine matches. A high-recall configuration can create too many incorrect links. The appropriate balance depends on the action that follows.

Measure	Why the committee needs it	How to set the gate
Precision	Shows the risk of linking different people	Set by use case and consequence, using labelled bank records
Recall	Shows the risk of leaving the same person fragmented	Set beside precision, never as a substitute for it
Manual review rate	Reveals whether uncertainty has merely moved into an operations queue	Compare with available steward capacity and current referral volume
Decision time	Connects technical quality to customer and colleague effort	Measure the existing workflow before the pilot
Unresolved duplicate rate	Tests whether the chosen use case is improving	Track a stable sample over time
Cost per reviewed case	Turns workload reduction into a finance input	Use the bank’s actual labour and platform costs
Change stability	Shows whether new sources or rules degrade results	Re-run the labelled set after every material configuration change

Do not average away the hard cases. Break results down by source system, name and address quality, customer type and the rules that produced a link. A single blended score can hide a segment that fails exactly where the bank most needs control.

The same accepted identity can support four workflows, but each workflow needs its own action threshold and control; uncertain matches first require human review.

How should governance shape the business case?

Governance belongs inside the value case, not in an appendix added after the technology choice. Accurate, comprehensive and timely data aggregation and reporting capabilities are critical for identifying and managing material risks. The committee should therefore see data lineage, ownership and operational value in the same decision.

The European Commission lists accuracy among the seven key GDPR principles. For a customer master, that makes match quality, correction and traceability part of the operating model. The proposal should show how a colleague can identify the source records behind a customer view, challenge a questionable link and propagate an approved correction through the appropriate systems.

The Bank of England notes that available, accurate and timely data are essential to the operations of individual firms and FMIs. Treating monitoring, rollback and source-system ownership as funded work is therefore part of the business case, not technical decoration.

The governance section should answer five questions. Who owns the customer identity definition? Who may change matching rules? Who reviews uncertain links? How are decisions logged? How does the bank respond when a customer disputes a connection? Clear answers make the programme easier to control and easier to cost.

The bank should also define the action boundary for every use case. An uncertain match can be displayed for review without automatically changing a customer record. A reporting workflow may tolerate a different threshold from account opening. Screening preparation can pass aliases and provenance to established sanctions, PEP and adverse media systems without replacing their case logic.

What architecture keeps scope under control?

The simplest useful architecture separates source systems, identity resolution, customer-master governance and consuming workflows. Systems of record continue to own their data. The resolution layer normalises and compares records. The governed customer master decides which attributes are published or stewarded. Applications consume only the identity and evidence they need.

Entity resolution is a resolution layer that sits alongside MDM, CDP and KYC or AML systems. It does not replace the governance, lineage, or workflow capabilities of those systems. This boundary keeps the proposal focused on matching, linking and retrieval instead of absorbing every governance and workflow requirement in the bank.

For Tilores, the technical boundary is precise. GraphQL only. There is no REST API. At query time, one GraphQL call can return the resolved entity, linked source records and match evidence. Tilores uses deterministic, fuzzy and probabilistic matching as three distinct methods. Data is normalised and persisted; originals are retained.

That architecture supports a customer-owned master rather than a vendor-owned business definition. The bank controls source authority, survivorship, access, review and downstream action. The resolution service supplies candidate identity boundaries and evidence. Our guide to entity resolution for master data management explains how that layer can fit beside an existing MDM operating model, while the GraphQL customer profile example shows the retrieval pattern.

How should the bank compare build and buy?

Compare complete operating models, not a matching algorithm with a licence fee. A build option includes data parsing, normalisation, deterministic rules, fuzzy comparisons, probabilistic scoring, candidate generation, entity assembly, persistence, explainability, monitoring, access control, infrastructure and ongoing rule ownership. A buy option still requires integration, configuration, testing, governance and supplier oversight.

Put both options through the same evidence gate. Give each the same labelled records, required throughput, deployment constraints and use-case thresholds. Compare the quality of proposed links, the evidence available to reviewers, the effort required to introduce a new source and the team needed to operate the service after the pilot.

The three-year view matters more than the demonstration. The committee should see initial delivery cost, annual ownership cost, expected change effort, specialist staffing, infrastructure, incident response and exit work. Unknown values should be shown as ranges or open assumptions, not hidden inside a confident total.

Use our build versus buy framework to structure the options paper, then replace generic assumptions with the bank’s own evidence. Buying is not automatically safer, and building is not automatically cheaper. The fundable choice is the one whose risks, controls and ownership can be stated clearly.

What should go into the committee pack?

Keep the pack short enough to decide and detailed enough to challenge. The core paper should fit around the decision, with technical evidence attached rather than buried.

1. Decision requested: the exact stage, budget range, owner and end date.
2. Problem baseline: current duplicate, search, review and reconciliation effort for the four use cases.
3. Scope: customer population, source systems, downstream workflows and explicit exclusions.
4. Target operating model: accountable owners, steward path, correction path and action thresholds.
5. Evidence plan: labelled data, precision, recall, review rate, operational outcome and segment analysis.
6. Architecture: source ownership, resolution boundary, customer-master responsibility and consuming systems.
7. Options: build, buy and a limited hybrid where relevant, assessed on the same requirements.
8. Risk and control: privacy, access, lineage, supplier risk, change management, rollback and exit.
9. Stage gates: the evidence required before any further funding is released.

The strongest final slide is not a forecast of perfect records. It is a compact decision tree: if the evaluation meets the agreed match-quality and control gates, fund one production use case; if it misses narrowly, recalibrate and retest; if it cannot meet the bank’s requirements, stop without carrying a transformation programme.

Test the case on your records. Book a Demo · Try Tilores Studio (Free)

What do funding committees ask about a customer master?

What should a smaller bank fund first?

A smaller bank should first fund a bounded discovery and evaluation stage, not an enterprise-wide customer master transformation. The stage should end with measured match quality, operating effort and a recommendation for one limited production use case.

Which metrics should the funding committee require?

The committee should require precision, recall, manual review rate, unresolved duplicate rate, time per review and one use-case outcome tied to existing operational cost. Targets should be set from the bank’s labelled records and risk appetite.

Can one customer master configuration support several use cases?

Yes, one governed customer identity configuration can support onboarding duplicate checks, servicing, screening preparation and reporting, provided each workflow has its own action threshold and controls. Shared identity logic should not mean shared permission or identical automation.

Should a smaller bank build or buy entity resolution?

The bank should compare the full operating model, including configuration, testing, monitoring, explainability, infrastructure, change management and long-term ownership. Both options should be tested against the same labelled records and acceptance criteria.

Does entity resolution replace KYC or AML controls?

No. Entity resolution is a resolution layer that sits alongside those systems. It does not replace their governance, lineage, or workflow capabilities. Sanctions, PEP and adverse media processes retain their own rules, sources, decisions and accountability.

Sources

1. Implementation of the BCBS 239 principles for risk data aggregation and risk reporting, Basel Committee on Banking Supervision, Basel Committee on Banking Supervision.
2. Principles of personal data processing under the GDPR, European Commission.
3. Operational resilience in a macroprudential framework, Bank of England.
4. How to Query a Unified Customer Profile Through an API in Real Time, Tilores.
5. Build vs Buy Entity Resolution: What Enterprise Teams Get Wrong, Tilores.
6. Master Data Management: Real-Time Entity Resolution for MDM, Tilores.