On Investment Data Quality Matters…

If you have been following the previous parts of this 10 part blog on a blueprint for rolling out a data governance program for investment product data, you will be aware that I have covered aspects such as Organization and Terms of Reference  – to this point just about everything I’ve talked about could apply to any data governance program – now I am talk more about what is specific to the investment product master domain.

Based on the terms of reference for your program, you will have briefly analyzed the drivers within your firm that led to the decision  to apply governance to your client-facing investment product data - and ideally, you will have worked with your stakeholders to construct a simple vision statement that outlines what the program is setting out to achieve.

Defining the strategy is merely adding meat to the bones of the vision statement!

I would expect that before you start exploring the strategy in any detail the following has happened:

1. Stakeholders have all been identified and there is a broad (high-level) RACI matrix in place for each party
2. C-Level engagement has happened and there has been formal buy-in that the program is needed
3. Terms of reference have been drafted and agreed by all stakeholders and outline budgets and business cases documented in full
4. C-Level executive/committee has signed off the terms/ straw-man budget

If the above has not happened, then I would politely suggest you’re wasting your time and that of many others proceeding any further.

It is likely at this stage you will have conditional approval/buy-in from the executive committee and that to progress they will want to see a detailed strategic plan on what the program will bring to the business.

From a product data perspective, it is likely your firm is facing some (or worst case all) of the following challenges which probably led to the initial discussions around …”we really need a governance program to oversee the management and publication of our investment product data“

• A desire from a client servicing perspective to up the game when it comes to client communications so that investors have access to more timely data, more relevant data and a greater breadth and depth of information than is currently available today.
• A realization that Dodd-Frank, Volcker, FATCA, AIFMD, UCITS IV / V, KID, Solvency II, the FSOC, the ESRB – all have a common thread – a demand for more transparency, a demand to share information that has not been shared before.
• Demands from institutional investors to open the lid on reporting holdings in a timely manner (with not so veiled threats to pull mandates)
• Demands from the sales/distribution team to deliver more timely and consistent information about products to just compete with competitor firms
• High costs and lengthy lead-time to deliver technology solutions due to the evolution of a cottage industry of silos based on Excel macros and Access databases
• Compliance team observation that certain investors have access to data about products which other investors in the same product did not receive – an issue for treating customers fairly
• A concern that data is available to too many people who do not understand what they are “handling”, be that the sensitivity of the data, or the compliance and handling issues that could be connected to the data
• Operations view that the process of sourcing, cleansing, storing and distributing client facing data is inefficient and error-prone
• Compliance view that the client-facing data process is manual, non-systematic and has no audit trail
• Challenges in the sourcing and maintenance of complex or very large data sets
• A lack of oversight and general understanding that is leading to poor practises evolving un-checked
• Increased regulatory change is changing the architecture of entire data environment

So, the program drivers along with the views of the stakeholders should form the evolution of the initial business requirement that will go on to form a clear strategic view of what the program is setting out to achieve.

There are many ways to express / communicate the strategy – think of how you would present a business plan – outline the goals and objectives clearly, break the goals down into stages and set them to a prioritized timeline.

Think about all of the activity that will need to happen to create a structured framework that can set about delivering the strategy:

• Establishment of domain-specific working groups
• Identification, agreement and documentation of the strategic business goals for the program
• Identification and documentation of the policies that set the strategy in stone
• Specification of the standards that will need to be agreed
• Plans for how you will bring together the people, process and technology to deliver
• Complete understanding and documentation of the data architecture for the data domain in scope
• Requirements for oversight and control
• Building out the processes and procedures for data quality management
• Agreeing and delivering the KPIs that will allow you monitor the data quality management activities
• Evolution of a data dictionary to ensure understanding of the data domain end-to-end
• Identification of the Target Operating Model and the steps along the way to the future-state

So hopefully, now you will appreciate why you could be wasting a whole load of time and effort if you engage fully without having really clear buy-in at C-Level.

Next up I will discuss models for stewardship…