An institution claims to have a Single Customer View. Yet the same borrower remains a CRM customer, loan-system customer, card customer, payment account, collections case, accounting counterparty, bureau identity and decision-engine applicant. The screen looks unified; the decisions remain fragmented.
A single customer view is not a dashboard, CRM record or master row. It is the governed ability to resolve one economic borrower across identities, accounts, facilities, exposures, payment histories and risk states at the exact time a decision is made.
The problem is relational before it is visual
A polished screen can show name, contact details, products and balances while missing a card held under another technical ID, double-counting a replicated balance or applying today’s relationships to yesterday’s decision. “Customer” itself is ambiguous: person, company, applicant, debtor, account holder, payer, guarantor, beneficiary or household.
Put every field on one screen
Optimises visibility while assuming identity and relationships are already resolved.
Reconstruct the economic borrower
Resolves identity, role, exposure, behaviour, authority and time for a defined decision.
Do not build a single customer screen. Build a single customer state that every relevant decision can reconstruct.
Customer, account, facility and exposure are different objects
| Object | Meaning | Critical distinction |
|---|---|---|
| Identity | Evidence used to recognise an entity | One party may have many source identities |
| Party | Legal or economic entity in a relationship | A party can be borrower, co-borrower, guarantor or owner |
| Customer | A party in a specific institutional relationship | Party and customer are not universal synonyms |
| Account | Servicing or settlement object | One customer can have many; one account can involve several parties |
| Facility | Credit contract or commitment | One facility can map to multiple accounts |
| Exposure | Economically relevant amount at risk | Drawn balance, undrawn commitment, accruals and contingencies differ |
The arithmetic is simple. The architecture is not. Joint borrowers break one-account-one-customer assumptions; guarantors create role-sensitive attribution; household and corporate-group relationships can matter without becoming the same object as the customer.
Entity resolution is a risk control, not data cleaning
Consider one fictional borrower represented as CRM C10291, loan 841207, card P-77218, collections COL-3407 and accounting BP009882. If those records are not linked, total exposure and cross-product behaviour disappear from decisions.
False split
One party is represented as several customers because of spelling, transliteration, changed surname, missing identifier, migration or duplication. Exposure is understated and behaviour fragments.
False merge
Different parties are incorrectly combined. Exposure, affordability, collections treatment and risk evidence can be assigned to the wrong borrower.
Strong verified identifiers may permit deterministic matching. Inconsistent or unavailable identifiers may require probabilistic evidence. The architecture should expose confirmed, probable and unresolved linkage rather than manufacture certainty. Material low-confidence relationships can route to controlled review without becoming an adverse decision by themselves.
Merges and splits need lineage: source records, match evidence, mapping version and correction events. A technical customer ID can change during migration; economic identity cannot depend on one surrogate key.
Risk lives across relationships, not one customer row
Relationships such as owns, borrows, guarantees, pays, controls or belongs-to-household should be explicit where decision-relevant. A master customer table remains useful, but MasterTable ≠ RelationshipModel. Canonical does not mean one denormalised mega-record; it can remain relational, graph-based or event-driven.
| Product | Drawn | Additional state | One-product decision sees |
|---|---|---|---|
| Term loan | €8,000 | Current | €8,000 |
| Card | €3,000 | €5,000 limit | Missing |
| Overdraft | €1,500 | Revolving | Missing |
| Consolidated | €12,500 | Plus relevant undrawn commitment | Understated by €4,500 drawn |
For revolving products, exposure is not merely drawn balance; see IFRS 9 EAD & Credit Conversion Factors. Poor integration can also overstate exposure: a €2,000 card balance replicated in processor and servicing becomes €4,000 under naïve summation. Product → Facility → Account lineage prevents technical copies becoming separate economic exposures.
A real customer view is point-in-time
Accounts close, addresses change, co-borrower relationships end and facilities refinance. Historical validation cannot apply today’s master mapping to the past. It must reconstruct identity mapping, active relationships, facilities, exposure and behavioural state as they legitimately existed at decision time.
The best governed representation now.
Relationships and attributes valid at T.
The mapping logic and evidence available at T.
Valid-from and valid-to periods, source lineage and entity-resolution version matter where decisions must be reproduced. Slowly changing employment, address, income and risk classification should not be silently overwritten. If duplicate records are later merged, historical groupings may shift; validation must distinguish corrected infrastructure from information originally available.
One current product can conceal a stressed customer
A borrower may pay a term loan well while maxing out a card and using an overdraft continuously. Facility risk and customer risk are related but not interchangeable. Customer-level aggregation can reveal total utilisation, cross-product delinquency, debt service, new exposure and payment stress without erasing product-specific signal.
| Decision | Fragmentation failure | Customer-state contribution |
|---|---|---|
| Affordability | Other internal obligations and revolving commitments are missed | Role-aware obligations and exposure |
| Credit limit | Each product approves independently | Aggregate exposure, utilisation and available commitment |
| Behavioural scoring / EWS | Stress emerging first in another product is invisible | Cross-product behaviour and freshness |
| Collections | Several cases trigger conflicting contact and promises | Party–facility context and coordinated state |
| Cure | One facility cure is mistaken for customer cure | Explicit facility versus customer definitions |
| IFRS 9 | Staging, EAD and recovery relationships fragment | Governed party/facility context while preserving unit-of-account rules |
These connections extend Affordability Decisioning, Credit Limit Assignment, Behavioural Credit Scoring and Collections Prioritisation.
The customer view is infrastructure beneath decisions
- Source identities
- Entity resolution
- Canonical party
- Relationship graph
- Facility / account resolution
- Exposure aggregation
- Behaviour aggregation
- Point-in-time customer state
- Risk / affordability / limit / collections decisions
A governed canonical state can contain the party, active relationships and facilities, drawn and undrawn exposure, delinquency and behavioural risk required for the use case. It preserves field-level authority and uncertainty rather than copying everything into a new silo.
Who is this economic entity?
Which relationships and exposures belong to it?
What was true at decision time?
APIs connecting CRM, core, payments and collections do not resolve duplicate parties or relationship semantics. Banks may inherit several masters through migrations or acquisitions; non-banks may fragment identity across origination SaaS, PSP, bureau, collections and accounting. Newer technology changes the topology, not the identity problem.
Identity and relationship latency must be monitored alongside exposure freshness. A newly opened facility that has not propagated can make a decision technically current but economically incomplete.
The same applicant changes when the institution recognises the borrower
A fictional lender knows one borrower as origination ID A, servicing ID B, card ID C and collections ID D. The customer requests a new loan.
| Evidence | Fragmented architecture | Resolved customer state |
|---|---|---|
| Term-loan balance | €4,000 visible | €4,000 visible |
| Card balance | €2,500 missed | €2,500 linked |
| Card undrawn | €3,500 missed | €3,500 available commitment linked |
| Recent card delinquency | Missed | Cross-product deterioration visible |
| Affordability | Passes on incomplete obligations | Recalculated on complete approved state |
| Limit | Too high for observed relationship | Lower or controlled-review outcome under policy |
Applicant → Origination ID → One product → Decision
Applicant identity → Resolution → Party → Relationships → Exposure / behaviour → Decision
If the lender later merges duplicate histories, internal debt may jump from €5,000 to €12,000. Feature distributions and model outputs move even when borrower behaviour did not. This is infrastructure-induced drift, connecting directly to The Hidden Infrastructure Debt of Modern Lending and The Payment Is Not the Balance.
One foundation should produce decision-specific customer views
| Decision | Required slice |
|---|---|
| Affordability | Obligations + governed income |
| Limit | Exposure + utilisation + commitments |
| Collections | Delinquency + contact state + facility relationships |
| ECL | Facility-level risk + accounting context |
More data is not the objective. The objective is Correct relationships + Correct state + Correct time, using only necessary, governed data for legitimate decisions.
Credit Risk
Strengthen exposure aggregation, affordability, behavioural risk, EAD and monitoring.
Finance / CFO
Reconcile counterparties, customer/account mappings and balance lineage.
Decision Automation
Build identity-aware workflows and cross-product decision orchestration.
A Customer Identity & Exposure Resolution Agent can support decision readiness
A future bounded Agent could ingest approved identifiers, flag likely duplicates and false merges, construct explainable party mappings, link facilities and accounts, aggregate current exposure, detect missing or duplicated representations, reconstruct point-in-time customer state and expose confidence to downstream risk workflows.
Its role is identity resolution + relationship mapping + exposure integrity + decision-readiness support. It must not autonomously alter legal identity records or make adverse decisions from uncertain matches.
This prepares future Engineering research on entity resolution, party/facility/account/exposure models, golden records without new silos, joint borrowers, cross-system identity and point-in-time reconstruction. These are deliberate briefs, not fabricated live routes.
