Published on
12 October 2026
Most CLM data problems aren't about volume. They're about competing client hierarchies that never reconcile. Here's what they are and why they matter.
By Mike Pszenicki who works with banks and financial institutions across the UK and Ireland to redesign their CLM operating models and deliver a more efficient, compliant, and client-centric onboarding experience.
Ask five people inside a bank to describe the same corporate client's structure and you will likely get five different answers. Not because anyone is wrong, but because each of them is looking at a different hierarchy. The relationship manager sees a commercial group. The Know your Customer (KYC) analyst sees an ownership chain. The risk team sees a rating history. The account system sees a tree of legal entities that doesn't map cleanly to either.
This is the problem that sits underneath almost every Client Lifecycle Management (CLM) programme we see, and it rarely gets named directly. Everyone talks about “data quality.” Very few talk about the fact that a single client is being modelled four different ways at once, by four different systems, none of which were built to agree with each other. And that’s assuming your institutions systems are broadly connected (this natural person who is a client is also a director of a legal entity client… did we know?).
Why Do Ownership Structures Differ Across Systems?
Beneficial ownership chains routinely run multiple layers deep, crossing jurisdictions with different registry formats, disclosure thresholds, and definitions of “control.” A holding company in one country, a nominee arrangement in another, a trust structure layered on top - each layer sourced from a different register, updated on a different cycle, and interpreted slightly differently by whoever last touched it. The result isn't a wrong answer. It's several plausible answers, none of which has been reconciled against the others.
Why Is There Rarely a True "Golden Source" For Client Data?
Most institutions can name their “golden source” policy. Far fewer can point to a client record where every system actually agrees. Data fragmentation is a common challenge. The same legal entity may exist under different names, different identifiers, and different "last verified" dates across the CRM, KYC platform, and account system. While each system maintains its own version of the truth, those versions are rarely reconciled.
When a migration or an audit forces the question of which one is correct, the honest answer is often that nobody has checked in years. The rise of the Chief Data Office(r) has meant that mature organisations have critical data elements listed, ownerships of slices of data, but again these need to be updated regularly since personnel change.
What Happens To AML Risk Ratings When The Methodology Or Platform Changes?
Every regulated institution (or regulated area within a broader group) has an anti money laundering (AML) risk rating methodology, and most of them have changed it at least once without fully re-rating the historical book. A platform migration, a merger, or a new supervisory expectation triggers a shift from one scale to another, and the mapping between old and new is frequently improvised under time pressure rather than governed as a proper methodology change.
Regulatory attention on this is only increasing. In November 2025 the FCA published findings from a multi-firm review of risk assessment processes, which found limited or no testing and review of risk assessment processes when firms made enhancements, upgrades or automation, and risk assessments that were not dynamic enough, leaving outdated risk profiles. Good practice included detailed documentation of methodologies, logged changes, formal review processes, and regular updates to risk assessment models. The EBA's risk factors guidelines likewise expect firms to keep their ML/TF risk assessments under review so that they remain up to date and relevant. The direction of travel is clear: a risk scale is expected to be governed like a model, not inherited like an artefact.
A firm that treats its risk scale as a fixed historical artefact, rather than a model requiring ongoing governance, is the one that scrambles when asked to defend it.
Moreover, within financial institutions where acquisition of companies has been significant, sometimes there is no single Compliance/Financial Crime lead (or at least one with teeth!). The result is sometimes a lack of globalised risk approach and regional or divisional risk approaches that don’t match. These can create a significant and complete maintenance headache (and further complicate the modelling for the back-book).
Why Doesn't The Commercial Client Hierarchy Match The Account Hierarchy?
The commercial view of a client group often differs from the structure defined in compliance and reporting systems. Relationship Managers understand who introduces whom, which entities trade together, and how relationships are managed in practice. Yet that reality frequently bears little resemblance to the account hierarchies enforced by internal systems.
Onboarding a new entity into an existing client group can create unexpected issues. It may inherit the wrong risk profile. It may sit outside the group's aggregated exposure view. In some cases, it can even trigger due diligence as though it were an entirely new relationship.
The root cause is often a mismatch between systems. The platform managing the relationship and the platform managing the account were never designed to describe the same structure.
Why Do CLM Data Hierarchy Problems Matter For AI?
None of these problems are exotic. Every institution running a CLM programme has some version of all four (and maybe more), running quietly, at the same time, on the same clients. What makes them dangerous isn't any single one, it's that they compound. A client with an unreconciled ownership layer, a disputed golden source, a stale risk rating, and a relationship hierarchy that doesn't match the account tree isn't a data quality footnote. It's a client nobody in the institution can currently give a single, defensible answer about.
That matters more than ever as AI starts disrupting the CLM conversation. Every AI use case in this space, automated risk scoring, entity resolution, augmented due diligence, depends entirely on which of these hierarchies it's been trained to trust. Get the foundations wrong and you don't get a wrong AI answer. You get a confident one, which is worse.
That's the thread running through data challenges: before any institution can meaningfully talk about what AI can do for CLM, it needs to be honest about which of these hierarchies it can stand behind today.
How Delta Capita Can Help
Find out which of your client hierarchies you can defend to a regulator, and fix the ones you can’t. Delta Capita’s CLM data healthcheck reviews how your ownership, golden source, risk rating, product and relationship hierarchies line up across your systems, benchmarked against industry best practice. You receive a report with defensible observations, clear recommendations, and a high-level roadmap for change.
The healthcheck shows you:
- Where your hierarchies conflict, and which conflicts create the most regulatory and operational risk
- Whether your golden source exists in the data or only in policy
- How far your risk ratings can be justified after past methodology or platform changes
- What needs to be in place before AI use cases such as risk scoring and entity resolution can be trusted
Our CLM Experts have run CLM operations themselves, so the roadmap is built for delivery, not just for a slide deck. If you want support afterwards, the same team can help design your target data model and governance and carry the programme through delivery.
Which of your hierarchies could you defend to a regulator tomorrow? Delta Capita's CLM data healthcheck gives you a clear answer.
Book a conversation with a CLM expert today.
Frequently Asked Questions
What is a golden source in CLM?
A golden source is the record an institution designates as the authoritative version of client data. In practice, many firms have a policy naming one, but multiple systems still hold conflicting names, identifiers and verification dates, so the golden source exists on paper rather than in the data.
Why do beneficial ownership structures differ between systems?
Ownership chains can span several layers and jurisdictions, each with different registry formats, disclosure thresholds and definitions of control. Systems capture these at different times and interpret them differently, so each can hold a plausible but unreconciled view of the same client.
Why does a change in AML risk rating methodology cause problems?
Migrations, mergers and new supervisory expectations often trigger a move to a new risk scale. If the mapping between old and new scales is improvised rather than governed, the historical book becomes inconsistent and firms struggle to justify why a client sits at a particular rating.
How do client data hierarchies affect AI in CLM?
AI use cases such as automated risk scoring, entity resolution and augmented due diligence depend on which hierarchy they are built to trust. If the underlying hierarchies conflict, AI outputs can appear confident but be wrong, which is harder to detect than an obvious error.
What is a CLM healthcheck?
A CLM healthcheck assesses key CLM domains with a pre-defined methodology and benchmarks your approach against industry best practice. Within the data domain we review data hierarchies (ownership, golden source, risk rating, product, relationship etc.) It typically runs for 6 weeks and provides an output report with defensible observations, recommendations and a high-level roadmap for change.
