Conceptual Data Model for E-CLM
Client Lifecycle Management is not just about collecting client data.
It is about structuring how the bank engages with clients, so that business can be conducted safely, consistently, and at scale.
The conceptual data model defines that structure.
How the bank structures and governs client business
Purpose
It provides a shared, system-independent view of:
who the client is
how the client is structured
how the bank engages with the client
what business is being conducted
under what conditions that business is permitted
This creates a consistent foundation for onboarding, lifecycle management, and ongoing activity across multiple entities, jurisdictions, and platforms.
Conceptual Model
The conceptual model below shows how client relationships, business arrangements, roles, and execution are structured across the bank. It provides a simplified view of the core elements and how they connect.
At the centre is the business arrangement, connecting client and bank through roles. Surrounding this are the structures that define, enable, and execute client business.
The model is based on a simple principle: parties participate in business through roles and are connected through defined relationships (often referred to as Entity–Role–Relationship, or ERR).
What the conceptual model represents
Client
The bank’s relationship is with a client group, not a single legal entity
Legal entities act as counterparties
Individuals act through representative roles
Additional connected parties (e.g. beneficial owners) provide structural and risk context.
Business Relationship and Arrangement
The bank manages a business relationship with the client over time
That relationship is expressed through business arrangements
Arrangements define:
what business is being conducted
which parties are involved
how those parties participate (roles)
how the arrangement is formalised (contracts).
Roles
All parties—client, bank, and external—participate through roles
On the bank side, roles are separated into:
Coverage (relationship ownership)
Servicing (operational interaction)
Booking (balance sheet and risk)
This reflects a broader Entity–Role–Relationship (ERR) approach, where entities take on roles within specific contexts and are connected through defined relationships.
Products, Permission, and Enablement
Business arrangements define the products and services involved
The model distinguishes between:
Product permission (what is allowed)
Product enablement (what is operationally established)
This creates a controlled layer between relationship and execution.
Execution (outside of CLM)
The bank’s relationship is with a client group, not a single legal entity
Legal entities act as counterparties
Individuals act through representative roles
Additional connected parties (e.g. beneficial owners) provide structural and risk context.
Risk
Risk is not embedded in a single object
It is a view across the structure
The model supports:
Local risk (per legal entity and jurisdiction)
Global risk (across the client relationship and all arrangements)
Why this matters
This model enables the bank to:
Operate consistently across entities and jurisdictions
Separate control from execution
Scale client lifecycle processes globally
Maintain a single, coherent view of the client
Align business activity with risk and regulatory expectations
Without this structure, client data becomes fragmented, relationships are inconsistently defined, and risk cannot be understood holistically.
What the conceptual model is not
The conceptual data model is not:
a system design
a KYC schema
a representation of transactions or accounts
It does not describe how systems process activity.
Instead, the model defines how client business must be structured so that systems can operate correctly.
A different way to think about CLM
Traditional CLM approaches focus on:
collecting data
completing KYC
opening accounts
This model reflects a different perspective:
CLM is the enterprise capability that defines and governs how the bank does business with its clients.
The conceptual data model is the foundation of that capability.
When the structure is clear, onboarding, servicing, risk, and execution can operate consistently. When it is not, complexity and inconsistency creep in.