Core replacement is disproportionate as an answer to a relationship data problem
The core is a transaction processor and an excellent one. Building the relationship layer beside it is the proportionate response.
Dynamics 365 Sales · Financial Services
Relationship banking in a product-centric system
Your core system knows about a checking account, a mortgage and a commercial loan. It does not know they belong to the same household.
Abstract
Relationship banking in a product-centric system
Summary
Retail and commercial relationships are held at account level because that is how transactions work. Commercial decisions are made at relationship level, and the gap between them is filled by an account manager's memory.
This paper examines what that gap costs in pricing, concentration and cross-sell terms, argues that the answer is rarely core replacement, and sets out how relationship structure should be modelled so it survives the first person who belongs to two households.
Key findings
Four things this paper argues
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Household definition is a compliance decision before it is a technical one
Address-based, declared-relationship-based or a combination — each produces different aggregations and different regulatory implications.
Account hierarchy models ownership; connections model relationships
Modelling households in the hierarchy breaks the first time a person belongs to two, which happens immediately in real data.
Rollup latency must be labelled or it will be misused
A scheduled rollup used for a concentration decision is a decision made on stale data, and the field gives no indication.
Analysis
The argument in full
What the gap costs
Three things, in ascending order of consequence. A household offered a product it already holds, which damages the relationship the campaign was meant to build. A concentration exposure nobody aggregated, which is a risk finding waiting to happen. And pricing decisions made without knowing the full relationship, which systematically undervalues the institution's best customers.
The account manager's memory closes the gap in practice, and it is genuinely effective until they leave, go on holiday, or the institution grows past the point where individual memory scales.
Modelling it so it holds
The account hierarchy is right for legal ownership structures — a parent company and its subsidiaries — and wrong for households, where the relationship is not ownership and a person can belong to more than one.
Connections handle what the hierarchy cannot: many-to-many, role-typed relationships recording that two contacts are spouses, that a contact is a director of an account, or that two accounts share a beneficial owner.
Effective dating matters more than institutions expect. Recording when a relationship started and ended lets you reconstruct the household as it stood at a past date, which is what a regulatory question about a historic decision actually requires.
- A household entity with a written definition agreed with compliance
- A short connection role vocabulary — five roles applied consistently beats twenty applied loosely
- Effective dating so historic structure can be reconstructed
- Matching on a stable core system key rather than on name and address
- Rollup fields with their latency stated explicitly in the field description
The definition problem
Defining a household is genuinely difficult and it is a commercial and compliance decision rather than a technical one.
Address-based definitions capture people who live together and miss family relationships across addresses. Declared-relationship definitions capture what customers tell you and miss what they do not. A combination is usually right and needs a written rule for the cases where the two conflict.
Whatever is chosen, it should be written down, signed off by compliance, and reviewed annually with a change process. Aggregations built on an undocumented definition cannot be explained when questioned, and in a regulated institution being unable to explain an aggregation is itself a finding.
Framework
Something you can apply without us
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Framework
Building the relationship layer
Five stages. The first is the one that determines whether the rest is usable.
1
Define
Household and relationship group in writing, with compliance sign-off and an annual review.
2
Separate
Hierarchy for ownership, connections for everything else.
3
Date
Effective dates on relationships so historic structure is reconstructable.
4
Key
Match to the core on a stable identifier, never on name and address if avoidable.
5
Label
State rollup latency on every aggregated field so nobody mistakes it for real time.
Implications
What this means, depending on your seat
The same argument lands differently across an executive team. These are the three versions worth separating.
References
Where to check this for yourself
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
01
Dynamics 365 Sales account and contact hierarchies
02
Connections and connection roles
03
Rollup fields in Dataverse
04
Duplicate detection rules
05
Microsoft Cloud for Financial Services
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
Recognise the situation?
We will model one segment of your book against your household definition and show relationship managers the complete picture, before you commit to anything wider.
Discuss this paper Run the related checklist We reply to every message within one business day.
Keep reading
Related papers
One version of the truth: what it costs and what it is worth
Consolidation projects are usually justified on efficiency and delivered on hope. This paper examines where the value actually is and what the honest cost looks like.
July 12, 2026 · 18 pages · 19 min readRead
Evidence in the flow of work
The decisions were made properly. The evidence just was not captured at the time, so it has to be reconstructed.
March 15, 2026 · 14 pages · 15 min readRead