"Is this the same customer?" and "who does this customer roll up to?" sound like variations on the same question. Computationally, they aren't. The first is a pairwise comparison problem — take two records, decide how similar they are. The second is a traversal problem — starting from one entity, walk a network of relationships to answer a question about structure. Systems built to do the first one well are usually not built to do the second one well, and platforms that try to force a single engine to handle both tend to be mediocre at each.
Two different kinds of question
Matching questions are local: given record A and record B, how confident are we they represent the same entity? The answer depends on comparing attributes — names, addresses, identifiers — and doesn't inherently require knowing anything about a third record.
Hierarchy and relationship questions are structural: given entity A, what entities are connected to it, how many steps away, and through what kind of relationship? Answering "show me every policy under this parent organization, three levels down, including recently acquired subsidiaries" isn't a comparison — it's a graph traversal, and it gets computationally expensive fast on a system that wasn't built to do it.
Where insurers feel this most
- Producer and agency hierarchies — commission structures, sub-agency relationships, and book-of-business rollups all require multi-hop traversal, not record-to-record comparison.
- Corporate family structures — parent/subsidiary relationships that matter for underwriting aggregation and exposure limits change over time and require walking a structure, not scoring a pair.
- Household and party relationships — who's related to whom, and how that affects policy bundling or claims context, is inherently a network question.
A platform that tries to answer these questions by layering hierarchy logic on top of a relational matching engine tends to hit two walls: query performance degrades sharply as traversal depth increases, and the data model itself resists representing relationships that change shape — a subsidiary gets acquired, a producer moves to a new agency — without a rewrite.
Why keeping them separate is a design decision, not a limitation
The practical implication isn't that hierarchy questions are unsolvable inside a matching-first platform — it's that solving them well usually means routing them to a purpose-built graph layer rather than forcing the matching engine to do double duty. The matching engine stays fast and simple because it only has to answer one kind of question. The graph layer stays fast because it only receives the data it actually needs to answer traversal questions — typically the resolved entities and the relationships between them, not the full record set.
A system that's good at everything is usually mediocre at the two things that matter most.
For enterprises evaluating an MDM platform, this is a useful question to ask directly: when a hierarchy changes — an acquisition, a re-org, a producer reassignment — does the platform handle that as a natural update, or does it require reworking match rules that were never designed to represent structure in the first place?