Client data in banks is in better shape than its reputation suggests. Tremendous effort has gone into deduplicating client records, much of it on the back of expensive KYC and AML remediation, and by and large it has worked. Where things get complicated is one level down, at the account.

The standard set-up with asset managers in the major markets is to open the manager as the client and its funds as accounts. Under the principle of reliance, the bank can lean on the KYC the manager performs on its funds, alongside the KYC it performs on the manager itself.

Anyone working in client onboarding will be familiar with the pitfalls: account openings for funds often begin before the fund has launched, so the documentation essential to the set-up is not always there. This is a reliable source of tension between the bankers who need to bring in the revenue and the operations team working under the watchful eye of compliance.

Regulators have raised the bar as well, pushing banks to apply the same rigour to the associated parties: the custodian, the introducing broker, the executing broker, etc. Legacy client masters were never designed to hold these relationship-based representations, so complex operating models have been built around them to compensate. Another word for a complex operating model is brittle.

The volume of data and the bespoke set-ups, each reflecting one institution’s constraints and priorities, have created a challenge operations functions have been battling for years.

Now consider a fund trading with a bank through several asset managers, each using different custodians and intermediaries. Overlay different products, different settlement arrangements and different legal entities, and the traditional shareholder-based hierarchies, assembled at great expense to satisfy KYC and AML, are plainly inadequate. Some banks have considered moving these representations into a graph on a NoSQL database; the business cases have rarely been compelling, and the risk profile is intimidating even for an ambitious executive.

So what can be done, I hear you ask.

Start from three facts.

First, the complex web of relationships is already mastered somewhere: in the contractual documentation, which the data we keep trying to fix is straining to represent faithfully.

Second, entity resolution remains a considerable challenge, and too often ends in manual intervention, an escalation to the sales desk, or an outreach to the client — onerous in resources and in reputation (“I sent you this information twice already!”).

Third, large language models happen to excel at understanding contracts, and AI agents can navigate what a bank already holds: the master data, the collateral agreements, the settled transactions, even the open book.

These are the ingredients, and this is the data inversion of the opening essay applied: take the tools to where the truth is mastered — the contracts — instead of patching the records downstream. An architecture that puts the ingredients to work could look like this:

None of this needs an enterprise programme. It starts with one desk’s worth of contracts and a bounded slice of the master, and it can set you on the path to radical improvement without asking anyone to bet the estate on a re-platform.

This is merely an example of where one could start. Does it resonate with you? Is the bank you work for following a different approach? Tell me in the comments.