Databricks or a Matching Engine? A Bank's Build versus Buy Guide for 2026

TL;DR: Build entity resolution on Databricks when custom matching is strategically important and your bank can permanently own the engineering, governance and operational workload. Buy only after confirming which matching, clustering, review and monitoring components the product maintains, while retaining named bank ownership. A hybrid architecture can make those boundaries easier to specify.

Compare build and buy on your own data. Book a Demo · Try Tilores Studio (Free).

On this page

1. What decision are banks really making?
2. What must a bank build beyond matching logic?
3. When does building on Databricks make sense?
4. When does buying a matching engine make sense?
5. Is a hybrid architecture the better answer?
6. How should a bank evaluate the options?
7. What is the practical verdict?
8. Frequently asked questions

What decision are banks really making?

The choice is not simply between Databricks and another piece of software. Databricks provides a powerful data and analytics platform on which a bank can engineer an entity resolution system. A matching engine provides the specialised resolution capability itself. The real decision is therefore about operational ownership: which parts of identity resolution should the bank design, maintain and defend over time?

A proof of concept can make a custom solution look deceptively compact. Load records, standardise a few fields, calculate similarities and assign a common identifier. Production changes the question. The bank must handle incomplete data, conflicting attributes, relationship changes, false merges, missed matches, historical decisions and exceptions that need human review.

That distinction matters because a data pipeline is not yet an operational entity resolution capability. A bank evaluating the options should compare the complete service it must run, not just the code that produces an initial match score.

Use this comparison as a due-diligence map, not as a statement that every product supplies the same scope. The bank should identify the owner and lifecycle cost of each row before choosing an architecture.

Decision area	Build on Databricks	Buy a matching engine	Hybrid model
Matching logic	Designed and maintained by the bank	Verify the product’s supported matching scope and supplier responsibilities	Define which resolution responsibilities remain with the engine and which remain with the bank
Golden record	Bank designs mastering and survivorship	Verify whether the product supports, rather than owns, mastering workflows	Bank assigns ownership of the mastered record and uses resolved entities at the agreed boundary
Data platform	Databricks hosts the resolution workflow	Separate engine integrates with bank systems	Databricks remains the data platform and the engine handles resolution
Operations	Bank owns monitoring, incidents and upgrades	Allocate monitoring, incidents and upgrades explicitly between bank and supplier	Ownership is divided through explicit service boundaries
Customisation	Maximum freedom, with corresponding maintenance	Configuration within the engine’s supported model	Custom orchestration around a maintained resolution core

What must a bank build beyond matching logic?

The following eight-layer map is a practical bank evaluation framework, not a universal industry taxonomy. The peer-reviewed entity-resolution literature distinguishes alignment, blocking, linkage and canonicalisation, and explains why pairwise linkage and entity-level clustering are different problems. For a bank, the map extends those technical stages to governance, review and service responsibilities that need named owners.

Production entity resolution extends beyond match scoring across ingestion, candidate generation, matching, clustering, mastering, review, monitoring and service operations.

1. Data ingestion and normalisation. Names, addresses, dates, identifiers and contact details arrive in different formats and with different quality. The bank needs repeatable transformations, source traceability and rules for retaining original values.
2. Candidate generation. Comparing every record with every other record is rarely a sensible production design. The entity-resolution literature describes blocking as the stage that limits comparisons; its design therefore needs testing for plausible candidates that it may exclude.
3. Match decisions. Deterministic, fuzzy and probabilistic methods solve different parts of the problem. Fuzzy similarity is not the same as probabilistic matching. A production design needs explicit rules for how each method contributes to a decision.
4. Entity clustering. Pairwise similarity does not automatically produce stable entities. A peer-reviewed review explains that pairwise methods can miss transitivity constraints, so the service needs explicit treatment of merges, splits and contradictory evidence across a cluster.
5. Golden record logic. Matching records and deciding which values become authoritative are separate concerns. Survivorship, provenance and business ownership need their own design.
6. Explainability and review. Investigators, data stewards, auditors and model owners need to understand why records were linked. Review outcomes must feed back into controlled configuration changes.
7. Monitoring and change control. Source systems, customer behaviour and data quality change. The bank must detect drift, review false positives and false negatives, test rule changes and preserve decision history.
8. Integration and service operations. Downstream systems need stable entity identifiers, interfaces, access controls, service monitoring, recovery procedures and accountable support. The Basel Framework requires clear ownership and controls across the data and technology lifecycle for bank risk data.

Databricks supplies useful foundations for several of these layers. Unity Catalog lineage can help trace data movement, while Lakeflow pipeline expectations can express and monitor data quality constraints. MLflow Tracking can record parameters, metrics and artifacts for model experiments. Those capabilities support governance, but the bank still has to design and operate the entity resolution behaviour built on top of them.

When does building entity resolution on Databricks make sense?

Building is credible when entity resolution is a strategic engineering capability rather than a supporting function. The bank should have a durable team, not merely temporary project capacity: the Basel Framework assigns ownership, controls and lifecycle responsibilities to business and IT functions for bank risk data.

A Databricks build is strongest when the bank needs unusual resolution logic, has mature data engineering and machine learning operations, and can accept responsibility for every production decision. It may also suit an organisation whose architecture requires matching logic to remain deeply embedded in existing lakehouse workflows.

The build case should answer five questions before implementation begins:

• Who owns match quality after the project team moves on?
• Who investigates false merges and missed matches?
• How are thresholds, features and rules approved, tested and rolled back?
• What interface allows stewards to review ambiguous entities?
• How will the bank explain historical decisions after the underlying data or logic changes?

If those answers depend on individual engineers or undocumented notebooks, the bank is not evaluating a production build. It is evaluating a prototype whose ongoing operating work has not yet been specified.

When does buying a matching engine make sense?

Buying may be attractive when the bank wants to own the business outcome and governance without engineering every specialised mechanism itself. The value should not be assumed from prewritten similarity functions alone: the evaluation needs to establish which parts of normalisation, candidate generation, matching, clustering, explainability, review and operational control the product actually maintains.

A matching engine should still be tested against the bank’s own data and failure costs. Product capability does not remove the need for accountable thresholds, privacy review, stewardship or integration design. It changes which team is responsible for the specialised mechanics, which the bank should record explicitly.

Our matching rules combine deterministic matchers, such as simple text equality, with fuzzy text matching and probabilistic matching as distinct methods. We use transformations to normalise working values; submitted records are compared with records already stored in Tilores, while fuzzy lookup matching compares original values through the configured similarity comparer. Applications use our GraphQL API at runtime. The public MCP server supports configuration work, including rule linting and GraphQL query templates, rather than acting as the runtime resolution interface. Deployment can be assessed separately through our deployment options.

The buying case is strongest when time spent creating an internal matching product would displace more valuable bank specific work. It is weaker when the bank’s requirements fall outside the engine’s supported operating model or when the organisation is unwilling to establish clear ownership for configuration and outcomes.

Is a hybrid Databricks and matching engine architecture the better answer?

For many bank architectures, the useful answer is not a complete replacement of one platform by another. Databricks can remain the environment for ingestion, transformation, analytics and controlled data products. A matching engine can resolve records into entities. The bank can then retain ownership of the golden record, survivorship policy and downstream customer model.

This division creates a clear boundary:

• Databricks prepares governed source data and consumes resolution outputs.
• The matching engine handles candidate discovery, match decisions and entity clustering.
• The bank owns the definition and use of its mastered customer record.
• Steward feedback and approved corrections return through controlled workflows.

The hybrid model avoids treating a matching engine as the owner of every customer data decision. It also avoids turning the data platform team into the permanent maintainer of a specialist resolution product. The boundary must be designed explicitly, particularly for entity identifiers, reprocessing, deletion, lineage and recovery.

How should a bank evaluate build versus buy?

Start with representative failure cases, not a polished average dataset. Include duplicate customers with sparse attributes, shared contact details, transliteration, changed names, conflicting addresses and records that should remain separate despite superficial similarity.

Then evaluate the complete operating model through a structured proof of concept:

1. Define decision consequences. A false merge and a missed match can create different risks. State which downstream processes consume the result and what each error could affect.
2. Separate resolution from mastering. Decide whether the test is judging record linkage, golden record construction or both. Do not let a strong match demo obscure an undefined mastering policy.
3. Test explainability. Reviewers should be able to inspect the evidence behind a link, understand the applied method and trace an approved correction.
4. Test operational change. Add new records, amend source data, split an incorrect entity and change a rule. Observe whether the system remains understandable and reversible.
5. Map permanent ownership. Assign every layer to a named team, including data quality, matching configuration, infrastructure, stewardship, incident response and supplier management. The Basel Framework similarly calls for established roles and responsibilities for the ownership and quality of risk data across business and IT functions.
6. Compare total scope. Compare both options on the same lifecycle boundary. The Federal Acquisition Regulation definition of lifecycle cost includes acquiring, operating, supporting and, where applicable, disposing of an item; for this decision, list the equivalent implementation and ongoing operating work on both sides rather than comparing a licence with an incomplete internal estimate.

Banking use cases also require privacy and financial crime controls to be designed into the workflow. The GDPR principles make accuracy, data minimisation and accountable processing relevant to how identity evidence is selected and retained. Customer due diligence may combine resolved identities with sanctions and politically exposed person data from sources such as OpenSanctions, alongside separately governed adverse media signals.

Precision is therefore not just a technical score. An overbroad entity can expose information to the wrong workflow, contaminate screening results or create unnecessary review. The proof of concept should show how the system prevents, detects and corrects that outcome.

What is the practical verdict?

Choose a Databricks build when your bank deliberately wants to become the product owner for entity resolution and can sustain that choice across engineering, stewardship, governance and operations. Choose a matching engine when the product demonstrably covers the specialised mechanics the bank does not intend to build, while the bank retains its own data, policy and outcome ownership.

Choose a hybrid design when Databricks is already the governed data platform but matching should remain a distinct service. In that model, the matching engine resolves identities while the bank preserves control of its golden record and the processes that depend on it.

The fairest comparison is not custom code versus a software licence. It is one complete operating model versus another, with a like-for-like lifecycle boundary and a named owner for every material control.

Frequently asked questions

Can Databricks perform entity resolution?

Databricks can provide the data engineering, governance and machine learning foundations for a custom entity resolution system. The entity-resolution literature distinguishes blocking, linkage, clustering and canonicalisation; a bank building on Databricks still needs to decide and maintain its own scope around those stages, including review, monitoring and service operations.

Is a matching engine a replacement for Databricks?

A matching engine does not need to replace Databricks. Databricks can prepare and govern data while the engine resolves records into entities. Resolution outputs can return to the bank’s data platform and customer mastering workflows.

Who should own the golden record?

The bank should assign accountable ownership of its golden record definition, survivorship rules and downstream use. A matching engine can identify which records belong together without taking ownership of every mastered customer attribute; the Basel Framework requires defined ownership and controls for bank risk data across business and IT functions.

What should a bank include in total cost of ownership?

Total cost of ownership should apply the same lifecycle boundary to both options. The Federal Acquisition Regulation defines lifecycle cost to include acquiring, operating, supporting and, where applicable, disposing of an item; use that discipline to include the relevant implementation and ongoing operating work on both sides.

What should a bank test in a proof of concept?

A bank should test representative ambiguity, false merges, missed matches, explainability, steward corrections, rule changes, reprocessing and golden record boundaries. The test should measure operational control as well as initial matching quality.

Sources

1. (Almost) All of Entity Resolution, Binette and Steorts, Science Advances
2. Risk data aggregation and risk reporting, Basel Framework, Bank for International Settlements
3. FAR 7.101 Definitions, Acquisition.gov
4. Data lineage with Unity Catalog, Databricks
5. Manage data quality with pipeline expectations, Databricks
6. MLflow Tracking, MLflow
7. General Data Protection Regulation, EUR-Lex
8. OpenSanctions documentation, OpenSanctions
9. Matcher Reference, Tilores documentation
10. Transformer Reference, Tilores documentation
11. Rules Configuration, Tilores documentation
12. Tilores API Reference, Tilores documentation
13. Tilores MCP Server, Tilores documentation
14. Deployment options, Tilores