Client lifecycle management solutions: build or buy?

Mark Bands, iMeta, offers a word of caution on building the CLM platforms

Mark Bands, head of product & regulatory intelligence, iMeta Technologies: When speaking with prospective financial institution customers of our client lifecycle management (CLM) platform I am surprised at how often an “in-house” build solution has either already been chosen or is being seriously considered as an option. Surprised, that is, that firms’ in-house technology functions are confident that they are able to quickly and at a reasonable cost build, deploy, manage and maintain a platform that will meet the many needs of the client onboarding and lifecycle management function.

As a technology professional who has previously held the positions of head of reference data IT, global head of reference data operations and regulatory data management programme lead at various large financial services firms, I’d like offer a word or two of caution in this context. A good place to start is to define what constituent parts and capabilities a fit-for-purpose platform needs to have before claiming that it is an effortlessly do-able thing.

1. Data connectivity: Financial institutions now require a plethora of client and counterparty data that needs to be collected, consumed, aggregated and utilised; both for the conduct of business and for the purposes of remaining compliant with the many regulations that now govern their activities. Serving this content requirement, the marketplace is filled with an ever-evolving ecosystem of data vendors, service providers and content utilities. For those of us that have managed operational data functions within banks, it is now clear that in order to effectively utilise the offerings of the various service providers, a rules-driven data connectivity tool is imperative. The only sustainable solution is for firms to deploy data interface capability that is able to manage the required connectivity to multiple sources. Not only must the interface manage the connectivity, but it must also detect and remediate data discrepancies by applying, in real-time, data completeness and quality rules. The cost, time and risk overhead of doing any of this manually is now untenable, meaning that automation is both urgent and vital.

Even for firms whose technology teams are able at a point in time, to develop, test and deploy Application Programme Interfaces (API’s) to the existing sources, the ongoing overhead of maintaining these API’s, over time, needs to be seriously considered. The interfaces to the sources will change with the advent of new content requirements, not to mention the coming of entirely new sources or service provision applications themselves. From any firm’s perspective, creating and maintaining a technology team specifically to manage this context is an undesirable burden, especially in times of ongoing funding cuts and capability downsizing demands.

2. Rules based policy driven workflow: Client lifecycle management processes are undertaken by financial institutions to meet the regulatory and operational requirements of transacting business with their customers globally. These processes are comprised of high-level activity groupings, such as Onboarding, Maintenance and Offboarding. Each one of these activities has distinct but interdependent functional components; where each function requires a combination of client requests, documentation and information to be collected, aggregated and interpreted. These already convoluted Front and Middle Office processes are governed by a complex and rapidly expanding set of legal and regulatory requirements, which brings into the mix the inclusion of Legal and Compliance oversight of the process.

It becomes obvious quite quickly, when contemplating this scenario, that these processes can only be executed and managed in an operational context that employs a rules based, policy driven workflow engine. This is because rules based process management engines can be configured to automatically prioritise and drive required onboarding activities based on relevant criteria; customer, product, geography and risk rating. Configurable onboarding workflow allows for the assured support of specialised policies and procedures across a matrix of both jurisdiction and product, while enforcing common operational best practices across multiple lines of business and geographies.

3. Audit: Onboarding and lifecycle management is about the collection, maintenance, support and control of both data and documentation. Previously document focussed, the processes are becoming more data driven. Links between data and underlying documentation need to be captured and maintained for regulatory purposes. Audit trail is required to address the existing challenge in knowing where content was originally sourced from. This needs to take the form of fully viewable and referable, time-stamped audit history of manual and automated steps taken during onboarding, including related documentation. Additional to the data / documentation dimension is the need for an audit trail of all system changes, including policy rules and workflow changes.
4. Data mastering: Systems managing this level of complexity require a single shared data model spanning the database model itself, code and relevant interfaces. The data model needs to be flexible allowing for entity types, reference data types and attributes to be added in extension to each of the platform components core data model. Model extensions need to be configured by means of flexible configuration files, while a centralised Data Management Engine is required to apply workflow processes and invoke the rules engine to apply business rules to entity data, regardless of the source of the data (inbound internal message, external data provider, or manual data input etcetera).
5. Management oversight: Both a real-time dashboard and out-of-the-box reporting on key operational risk metrics; including timeliness, volumes and process trending, are required components of a strategic CLM system. The management dashboards and reports must be customisable and support complete drill-down to the detail of each and every case. The system will also, within its rules, deploy configurable service-level agreements (SLAs) to ensure that processes are managed within regulatory and internal control time-frames. The dashboard and reports will also need to record and report on SLA metrics for the proactive management of all onboarding cases.

An enterprise CLM platform needs to be a modular case management workflow platform that, combined with a rules engine, is able to deliver robust regulatory compliance and active operational process management. This is a complex space where the need to streamline client onboarding, account opening and client data management activities is coupled with a requirement for automated enforcement of compliance across both standard client due diligence processes (KYC/AML), and industry tax and trading regulations (Dodd Frank, EMIR, FATCA and CRS), across product lines, business silos and geographical jurisdictions.

In this context, custom development will be exceedingly hard work. Build will require large amounts of diverse but exacting specifications, delivered by teams with both specialised architecture design and programming skill sets. Build will need years of development time with significant expense to the firm, combined with the risks associated with the ongoing maintenance of custom code over a 10 year lifespan period; during which time staff will turnover and code can become outdated. Firms need to seriously consider all these elements, especially the timeframes involved, when making the crucial build or buy decision.