What’s New & In Development
Ideas, emerging work, and recent additions to the site.
The site is intended to evolve as new questions, ideas, technologies and practical experience create new areas to explore.
This page brings together recent additions and selected work in development, providing a simple way to see what has changed and where the thinking may be heading next.
Some ideas will develop into substantial sections of the site. Others may remain as perspectives, propositions or areas for further exploration. As with the wider site, the thinking may change as it is tested, challenged and developed further.
For returning visitors, this is the place to see what is new, what is being explored and what may come next.
What’s New
Recent additions to the site
The website is being developed progressively rather than as a finished body of material. This section highlights significant additions so that returning visitors can see where new thinking or content has been added.
October 2026
Identity
A new page explaining why banks need one authoritative entity identity before applying KYC, Credit and other risk requirements.
Relationships
A new page exploring how connections between entities create value, dependency and risk, and why banks need to make the relationships that matter visible and manageable.
Roles
Roles explores how the capacity in which an entity participates shapes relationships, risk, eligibility, contracts, permissions and the actions the bank must take.
Business Arrangements – A new page exploring how financial arrangements enable economic activity, connect participants, distribute risk and give substance to client relationships.
Contracts
Contracts explores how legal agreements govern business arrangements, create enforceable rights and obligations, and connect into product permissioning and the wider client lifecycle.
Entities
A new page exploring what constitutes an entity, why consistent recognition matters, and how entities remain distinct from roles, relationships and identity.
Ideas being explored
Material may appear here before there is enough content to justify a complete page.
The purpose is to capture ideas while they are being developed, provide an indication of areas that may be explored next, and allow the thinking to evolve without requiring every subject immediately to become part of the formal website structure.
Some subjects may eventually become full pages. Others may be incorporated into existing material, develop in a different direction, or remain as individual ideas.
Operating Model Engineering
Exploring the proposition that an operating model should be understood and designed as a system rather than as a collection of processes, organisational structures, controls and technologies.
The central interest is how those components interact in practice and how operating models can be deliberately designed to work in design, in execution and in practice.
AI-Enabled CLM
AI creates opportunities that extend beyond automating existing CLM activity.
It may change how information is collected, interpreted and maintained; how decisions are supported; how exceptions are identified; how knowledge is applied; and how work is divided between people and technology.
The more important question may therefore be not simply where AI can be added to today’s CLM, but what operating-model approaches become possible that were previously impractical.
Enterprise Participation Architecture
Developing the concept beyond its initial proposition.
The emerging question is how a Financial Institution can identify, understand and control the different ways in which it participates in the economic and financial system — through clients, counterparties, markets, products, funding, infrastructure and other relationships.
CLM and the Changing Risk Environment
Further exploration of how geopolitical change, financial stress, sanctions, market disruption and other external events affect clients and the networks around them.
The focus is particularly on the information and operating capabilities a Financial Institution requires when the time available to understand and respond becomes compressed.
Modular CLM Architecture
Exploring how CLM can be designed as a set of modular, interoperable capabilities rather than as one tightly coupled platform or end-to-end application.
The objective is to separate capabilities such as entity and relationship management, due diligence, screening, workflow, decisioning, document and evidence management, product permissioning, identifiers and downstream integration so they can evolve independently while operating as part of a coherent CLM architecture.
A more modular approach may make it easier to replace ageing components, adopt new technologies such as AI, accommodate different business or regional requirements, and avoid large-scale platform replacement becoming the only route to significant change.
The key question is how to gain that flexibility without fragmenting the operating model, data or control environment.
Organisation, Ownership, Accountability & Governance
Exploring how CLM should be organised, who should own it, where accountability should sit, and what governance is needed for a capability that cuts across business, operations, risk, compliance, data and technology.
CLM often spans multiple organisational boundaries, yet responsibility can remain fragmented. That creates an important design question: who has sufficient authority to bring the capability together and be accountable for how it performs as a whole?
This includes questions such as whether CLM requires a recognised senior accountable role, how responsibilities should be divided between the Front Line and specialist functions, how decision rights should work, and how governance can provide effective control without creating unnecessary complexity.
The broader question is whether the organisation structure itself needs to evolve when an enterprise capability becomes too important and too interconnected to be managed successfully through conventional functional ownership alone.
CLM Demand, BAU, RTB & CTB
Exploring how CLM teams receive, prioritise and execute work across Business as Usual (BAU), Run the Bank (RTB) and Change the Bank (CTB).
CLM teams rarely deal with a single, predictable source of demand. Work can arise from onboarding and lifecycle activity, regulatory and policy change, operational issues, risk events, data problems, technology releases, business change and remediation activity — often competing for the same specialist resources.
The challenge is therefore not simply how work is allocated, but how the CLM capability responds as a whole. Some demand must be executed immediately, some requires controlled remediation, and some should result in structural change to prevent the same problem recurring.
This raises questions about demand intake, prioritisation, capacity, ownership and the relationship between teams responsible for running the service and those responsible for improving it.
The broader question is how to create an operating model in which BAU, RTB and CTB reinforce one another rather than becoming separate competing agendas.
Critical Response Capability
Exploring how effectively a Financial Institution can respond when a client, market, jurisdiction or external event suddenly becomes critical.
A crisis places very different demands on CLM from normal operating conditions. The institution may need to identify affected clients and entities, understand exposures and relationships, locate relevant products and transactions, assess restrictions or legal obligations, coordinate decisions across functions, and act quickly across multiple systems and booking locations.
The key question is not simply whether the required information exists, but whether the institution can assemble, interpret and act on it quickly enough when time matters.
This raises questions about information architecture, ownership, decision rights, escalation, crisis governance, operational resilience and the ability to restrict or exit activity rapidly where required.
The broader question is how to assess whether a Financial Institution has the capability to respond coherently and at speed before a crisis exposes weaknesses in the operating model.
Stakeholders & Their Expectations
Exploring who the key CLM stakeholders are, what they expect from the capability, and how those expectations differ or conflict.
CLM sits at the intersection of the Front Office, Operations, Risk, Compliance, Data, Technology, Finance, Legal, Audit and senior management. Each stakeholder views the capability through a different lens: growth, control, cost, quality, speed, resilience, regulatory compliance, data integrity or strategic change.
Those expectations are not always aligned. A faster onboarding process may increase pressure on control functions. Tighter policy can increase operational demand. Cost reduction can reduce resilience. Technology change can improve capability in one area while creating disruption elsewhere.
The challenge is therefore not simply identifying stakeholders, but understanding what each one needs from CLM, where expectations conflict, and how those tensions should be managed explicitly.
The broader question is how CLM can be designed and governed so that stakeholder expectations are visible, balanced and translated into clear performance, control and design requirements.
Data in CLM
Exploring the role of data as a core part of the CLM operating model — not simply as something captured during onboarding or stored within a KYC platform.
CLM depends on being able to identify entities and relationships accurately, understand ownership and control, maintain current client information, connect products and services, support risk decisions and distribute trusted information to the systems that enable the relationship across the Financial Institution.
That raises questions about data ownership, quality, lineage, identifiers, master records, conflicting sources, recency, validation and distribution. It also raises architectural questions about which information should be held centrally, which should remain within specialist systems, and how changes should propagate across the wider technology environment.
Poor data design can create duplicate entities, inconsistent client views, broken downstream mappings, repeated remediation and weak crisis response. Good data design should make the operating model easier to control and easier to change.
The broader question is how CLM can move from collecting data for individual processes to managing trusted information about clients, entities, relationships and business participation as an enterprise capability.
Work in Progress
The material listed here should not be interpreted as finished doctrine.
Design is iterative. The external environment changes, technology develops, practical experience produces new evidence and different perspectives expose assumptions that may need to be reconsidered.
An approach that works well today may not be the best approach tomorrow.
Some ideas on this site will therefore change as they are tested, challenged and developed further.
The objective is not to defend a particular design. It is to continue looking for the approach that works best for the circumstances that exist at the time.
Entity Management
(added 6-Sept-26)
Client Lifecycle
(added 6-Sept-26)
The Client
(added 6-Sept-26)
Client Groups
(added 6-Sept-26)
Client Group Lifecycle
(added 6-Sept-26)
CLM Team Operation
(added 6-Sept-26)
Governance
(added 6-Sept-26)
Who Owns KYC
(added 6-Sept-26)
Who Owns Compliance
(added 6-Sept-26)
Entity, Relationships & Participation Model (1)
(added 11-Sept-26)
Entity, Relationships & Participation Model (2)
(added 11-Sept-26)
Product Mapping in CLM
(added 11-Sept-26)
Identifier Mapping in CLM
(added 12-Sept-26)
CLM Components
(added 12-Sept-26)
Constructing CLM
(added 12-Sept-26)
Engineering CLM
(added 15-Sept-26)
Engineering CLM Identifiers
(added 15-Sept-26)
Identifiers & Business Enablement
(added 19-Sept-26)
AI Initiative Lifecycle
(added 19-Sept-26)
Engineering Deferred into Production
(added 23-Sept-26)
The Debt Spiral
(added 23-Sept-26)
Business Requirements to Working Platform
(added 25-Sept-26)
Business Requirements to Under-Engineered Platform
(added 23-Sept-26)
The important roles in achieving a properly working CLM platform
(added 23-Sept-26)
The importance of RTB / CTB change capability
(added 23-Sept-26)
Onboarding Governance
(added 05-Oct-26)
Onboarding Governance
(added 05-Oct-26)
Regulatory System of Record
(added 05-Oct-26)
Regulatory Executable Logic
(added 05-Oct-26)
Universal Prioritisation Process
(added 05-Oct-26)
Business Enablement Identifier Lifecycle
(added 05-Oct-26)
AI & Robotics Prioritisation
(added 07-Oct-26)
Personal Research & Development
The ideas and materials recorded on this page form part of my personal research and development work for this website.
This website is a personal side project and is not a commercial venture. The material is developed independently and may subsequently inform my professional thinking and work.
The views, concepts and materials presented here are my own and are not produced for, endorsed by, or representative of any current or former employer or client.
Publication dates also provide a visible record of when ideas and materials have been introduced or developed on the site.
No confidential or proprietary information belonging to any organisation is intentionally included.
Different Perspectives Are Welcome
The purpose of publishing developing ideas is not simply to record them.
Different experience, evidence and perspectives can reveal weaknesses in an argument, challenge assumptions or suggest a better approach.
Where that happens, the thinking should evolve.
Good design is not about being right first time. It is about continuing to learn enough to make the design better.