Banks can spend years refining KYC operating models, data architecture and control frameworks while leaving a more basic problem unresolved: whether the organisation has one reliable identity for each client.
A bank may hold a great deal of information, collected through costly processes and held in capable systems, yet still be unsure whether different records describe the same person or organisation.
That uncertainty becomes more serious as banks move towards greater automation and introduce AI-assisted models.
How identity gaps become control gaps
Technology can collect information, prepare assessments, screen connected parties and trigger work when circumstances change. But it can only do that reliably if the bank first knows which person or organisation the information, relationship or event relates to.
Without that foundation, the same legal entity may be reviewed more than once, while analysts ask a client for information the bank already holds. An ownership change may update one record but fail to trigger a review elsewhere. Screening, risk ratings and approval decisions may use different versions of the same client record.
The workflow can still show every task as complete, even though the bank cannot show that the right entity and all relevant owners and controllers were assessed.
For banks operating in the EU, the AML Regulation applies from 10 July 2027, putting greater weight on keeping customer information current and understanding beneficial ownership. The obligations become difficult to operate consistently if an owner, event or record cannot be linked reliably to the right client across the bank.
One party, several legitimate views
Identifying the client involves more than cleaning up KYC data. Legal, Credit, the front office, and other teams each need a view of the client, and those views are structured for different purposes. Legal focuses on the contracting entity and its agreements. Credit may group entities by economic exposure. A relationship manager looks across products, booking locations and revenue. KYC needs the legal entity, its ownership and control structure, the supporting evidence, its risk rating and the events that should trigger a fresh assessment. Shared facilities and agreements add another layer, because the same arrangement may connect several legal entities that each need to remain identifiable in their own right.
Problems arise when these different views cannot be linked to the same person or organisation, or when nobody can explain how one view relates to another. KYC does not need to own every item of client data, but it does need a say in the information on which its controls depend. That includes the definitions of owners and controllers, the rules used to match records, the sources that take priority and the changes that require further due diligence.
Responsibility therefore has to cross functional boundaries. Legal must maintain reliable contracting information; the front office must provide accurate relationship context; Credit must own its exposure groupings; and Data teams must run the standards and technical processes that keep party data usable.
In my experience it often falls to the KYC leader to define what an acceptable match looks like when resolving entities, how disagreements between sources are handled and whether an unresolved case can be accepted. Where another function provides essential data, the owner, standard and evidence of the hand-off should be explicit.
A trusted core, not a universal definition
The answer is not to make every function use a single definition of the client or to build an enormous golden record containing every fact anyone might need. A workable design starts with a small, shared core: one resolved identity for each person or organisation, common identifiers, agreed matching and survivorship rules, and lineage back to the original sources.
The different business views then sit around that core. Legal structures, beneficial ownership, controlling relationships, economic groups and commercial coverage groups do not have to be forced into one hierarchy. Each can retain its purpose, as long as every relationship records what it means, where it came from and who is responsible for maintaining it. In practical terms, the core answers 'who is this party?'; the surrounding relationships answer 'how does this function need to understand it?'
For KYC, this approach has concrete value. An analyst can confirm which legal entity is being assessed, identify the relevant owners and controllers, see how they connect to other customers and trace the evidence used in the decision. If an owner changes or a connected party produces a screening hit, the bank can identify every relationship and assessment that may be affected.
Master data management, graph-based entity models and entity-resolution services can all support this design, but none of them removes the need for judgement. Someone must decide which source takes priority, what level of confidence is acceptable and how ambiguous matches will be investigated.
Change programmes often reveal the gaps
Problems often come to light during KYC change programmes, because they depend on reliable party identity throughout. A remediation may reveal that separate teams reviewed the same organisation and reached different conclusions. A move to perpetual KYC may show that external events cannot be linked confidently to the customers they affect. Centralising KYC work may expose inconsistent identifiers and relationship data from different businesses. These are different signs of the same unresolved problem.
When signing off a migration, remediation or operating-model change, the KYC leader needs evidence that the controls worked across the client and its relationships. That means checking that the correct legal entity was reviewed, all relevant owners and controllers were identified, and material changes reached every affected file. These checks should form part of the evidence used to confirm completion.
Testing should track the data through the control. Take a sample of ownership changes and check whether they reached the right customer files. Compare the treatment of connected parties across products or booking locations. Review unresolved matches and the exceptions handled outside the normal process. These tests reveal whether the shared party view is working.
A firm foundation before automation
A shared party view proves its value when it improves decisions and makes them easier to defend. A practical starting point is to identify the party and relationship information each KYC control uses, set out who owns the relevant decisions and data, and test what happens when records change, sources conflict or a relationship cannot be resolved. The results of those tests should determine whether the foundation is ready for further automation.
If the bank can show who the client is, automation has reliable identities, relationships and evidence to work with. If it can’t, new technology will only produce wrong answers faster.
