Setting up a governance program for effective management of investment product master data – Part 9 – Technology Frameworks

March 12, 2013

This is the penultimate post in a series of blogs on setting up a governance program for the effective management of investment product data, in this blog I will explore the importance of technology frameworks.

Investment product data quality is determined by: Completeness, Consistency, Timeliness and Accuracy – but to solve data quality  you need to consider: People, Process and Technology!

People Process Technology

Implementing a formal program of data governance and effective stewardship requires investment in supporting frameworks that empower people to apply the process.  While technology is not the solution to data quality– it has a really important role, and that is to provide a structured framework that empowers the stewards (people!) to apply the process!

Remember technology and your IT department cannot and will not solve your data quality problems – it’s role is to support and frame the process such that the people can do their job effectively.

The aspects of data governance, and of the data quality management process, where technology plays a key role are as follows:

  • Automation of data quality checks, ideally with a business intelligent rules engine. There are many generic DQM/EDM solutions on the market – think about a best of breed for the niche you are in though – they will deliver a greater ROI. Ensure your business rules engine is capable of schedule management, workflow structures, validation, reconciliation, transformation and derivation – ideally choose one with a Domain Specific Language that allows custom rule engineering
  • Effectively measurement of the process and reporting meaningful and actionable information – be that in the form of traditional MIS, KPI’s, Balanced Scorecards or bespoke dashboards. Operational oversight, trend monitoring and feedback loops are key elements in driving  a process to maturity (see next post in the series)
  • Assignment and delegation of ownership and accountability
  • Exception management, alerting, reminding and escalating data quality problems
  • Data mining and reporting
  • Critical to all processes under the remit of the governance program is that they are repeatable, automated and systematic – with a clear audit trail that ties stewards, to data exceptions, to historical temporal views of the platform

Remember though, the key role that technology plays is in providing a framework that empowers the stewards to apply the governance strategy, while allowing the governance function to oversee the application of the strategy.

In the last post of this series I will look at how to drive your governance program from day-care to maturity….


Setting up a governance program for effective management of investment product master data – Part 8 – Data Dictionary

March 6, 2013

This is part 8 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will explain why building and maintaining a data dictionary is probably one of the most important factors in the success of your program.

Like many business buzzwords, data dictionary means different things to different people. The common thread is that the dictionary is an inventory of the data items being consumed or produced within a specific defined business unit or process.

Why do we create them? Again, there are many reasons – but the most prevalent one is to bring a common understanding to play within a specific environment such that everyone is speaking the same language when it comes to data. Data management projects live and die by the quality of their data dictionaries because even within small teams you can have wildly different nomenclatures in existence for what seems at face value very simple, easily understood data items.

Before I get onto what makes up a data dictionary I would like to clear up a couple of misnomers I often come across:

- A data dictionary is not a document. Documents are two-dimensional, while data dictionaries work across many planes. They are best represented in a relational database, or if needs must, a set of interrelated Excel worksheets.

- A data dictionary is not a project resource – yes, every data management project needs a dictionary, but as a resource it has a life outside of the project. You do not create a dictionary to serve the needs of a project only – the dictionary is also required within the business-as-usual activities that come into play post a project delivery i.e. it is a resource that requires and demands constant attention, updating and refinement.

So what is commonly found in a data dictionary? As I mentioned earlier it is a centralised inventory of information on data items/fields that describes in detail the data items semantics, how the data relates to other data, where the data is consumed, where it is processed and from where it is sourced. The dictionary should also describe the correct format and syntax for each field.

So for each entry in the dictionary I would expect to find the following

- A specific unique name for the item

- A clear definition of the data items meaning, including references to other common/aka names for the item

- A list of all “consumer” entities and processes that consume/use this data item

- A list of all the “suppliers” or source systems that produce this data and deliver to processes downstream

- Specific mention of any master rules for choosing correct source system for specific situations

- A list of all business rules applied to the data item as part of any data quality management process that touches the data

- Reference to stewards or stewardship teams that are responsible for the management of the data

- Reference to subject matter expert(s) who can deal with questions about the data item

- Detailed syntax specification for the data item – including type, structure, format and example values

- Good dictionaries allow users enter and update specific notes and references à la a wiki

If you have constructed your data dictionary using a database then you can easily provide very helpful alternate views of the dictionary for example:

- Show all data items consumed by process X

- Show all business rules

- Show the data items touched by Rule Y

- For data item Z show all sources

- For data item R show all consumers

- and so on…

More advanced dictionary implementation have an integrated audit trail with the live system that can instantly show as-of  transactional views i.e. the dictionary and the real-world systems it relates to are integrated.

So how does one build the dictionary? In MoneyMate we build them out using a SIPOC process in reverse [COPIS]

- So we start off identifying all of the consumers of information

- From here working out what outputs are consumed by each consumer#

- From here working out which processes deliver the outputs

- From here working out which inputs are used in each of the processes

- Before finally identifying the source/supplier systems producing the inputs

A critical element of the COPIS/SIPOC analysis is identifying where certain data items have multiple source systems – in these cases we need to carefully specify the master data rules that indicate which source is correct for the variety of situations that dictate different usage of the data.

Examples of this problem would be:

- You could have multiple back-office providers which means your daily NAV could be flowing from multiple parties/systems

- You could also have different legal structures in play that have different statements of record for different data types e.g. for holdings you maybe using the accounting book of record for your mutual funds but for managed accounts you are taking data from your investment records.

- You could have standard source of performance for all in-house funds, but for sub-advised you take data from the sub-advisor

Clearly the dictionary needs to capture all of this information in a well structured manner and allow for specific notation of the master rules for each item which has more than one source.

So hopefully you have a better understanding of what a data dictionary is, what it contains and why it is needed.  If you have anything to add yourself – send me a PM or comment below.

Next up in the series is a review of the role technology should play….


Setting up a governance program for effective management of investment product master data – Part 3 – Defining the Strategy

January 31, 2013

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…


Data Governance – Terms of Reference

January 22, 2013

Setting up a governance program for effective management of investment product master data

Part 2 – Terms of Reference

So you have gone about the process of trawling your firm for the correct group to initiate a program of governance for your investment product data – what should the terms of reference be?

The first thing you must consider is the reason for the program’s existence and the purpose of the program.

Is your firm concerned about

  • Demands for greater transparency? Do you see this as a threat or an opportunity?
  • To what extent is increased regulatory change a driver?
  • Is Distribution demanding more timely and quality information?
  • Is the changing shape of  technology and data environments altering your viewpoints?
  • Are clients, whether institutional or retail, demanding greater depth and breadth of data on your products (their investments)?
  • Protecting USPs e.g. intellectual property rights (investment strategy) versus demands for more transparency?
  • Pervasion of manual error-prone processes and lack of systematic, repeatable and auditable data publication cycles.

Many of the drivers and the stakeholders which are leading to the fruition of data governance programs are at odds with each other – so it is important that the organizational C-Level backing, structure and balance is right to prevent the program being hijacked by singular viewpoints, or reaching a point of stalemate due to inability to find common ground and lack of strong leadership.

So, getting the scope and terms of reference is a key element in implementing an effective program of governance.

To move this forward – consider the following:

  1. From an organizational perspective – ensure you have a clear organization structure, with a published org chart to represent all of the stakeholders. Key questions to consider – do you have C-Level backing and participation? Is the group that will drive the program forward balanced and drawing on all interested parties within your firm? Do you have strong leadership in place to deal with conflict and prevent stalemate?
  2. Define a one sentence vision for the program – for example,”The vision of our program is to position our firm as a market leader in providing transparent, timely and high quality data to investors and regulators alike” – keep your vision simple and well understood.
  3. Outline 3 to 5 objectives for the program – these can be more tactical in nature but should align clearly to the vision – these can also change over time through agreement with the stakeholders – key here is to make sure your goals are concrete and measurable
  4. Clearly define boundaries for the program – where does the scope start and end? Specifically call out areas that are not in scope and make clear boundaries between this and other data governance programs in the organization
  5. Begin thinking about the core deliverables  required to deliver on the objectives - ensure you have quick wins identified to drive positive feedback loops early on in the program’s lifetime
  6. Ensure that  stakeholders have clear roles and responsibilities – a simple methodology to use here is construction of RACI matrices
  7. Set out a high level schedule
  8. Consider budgetary impact – will the program require its own budget, or will it draw on existing budgets?
  9. Set out the engagement framework – the frequency and format of meetings, accountability and oversight, reporting

The key thing here is to keep the initial terms of reference simple, precise and easy to communicate – 1-2 pages would be a lot better than 50-100 pages.


What do the regulators want? The do’s and don’t's of data management when it comes to pleasing the regulators….

August 31, 2012

As published recently in TabbFORUM

Understandably, regulators are now focussed very firmly on managing market stability and ensuring the industry is treating investors fairly.

From the “Know your product and know your client” perspective, asset managers and more specifically their distribution wings have to be seen to market and sell product that is specifically appropriate to each client and their specific circumstances.

The regulator (and I refer to them in general terms here) – is looking for accuracy, completeness, and timeliness – and – they are looking for appropriate and consistent use of data in all public communications with investors – be that – fact-sheets, web, RFP responses or institutional client reports.

Sales and marketing material for investment products is coming under increased scrutiny – the regulators are now treating such material as disclosure of material fact.

Additionally, certain specific clients or client segments – cannot be seen to be treated “more fairly” than others – particularly where there is a conflict of interest between retail and institutional clients in the same investment pool – and – the timeliness of disclosure to all invested parties.

From a management of market risk perspective, the regulators are starting to demand additional reporting and data – specific items of interest relate to;  leverage – liquidity – exposure to derivatives – and – concentration of risk – with strong initial focus on counter-party and,  region or sector specific exposure, hence the focus on the Legal Entity Identifier and identification of the ultimate parent.

So what are the DO’s and DON’T's of data management?
DO

  • ensure you have a governance program in place that covers publication of client-facing product data
  • deploy systematic repeatable processes
  • consider building audit trails into each process
  • empower your data stewards with the tools they need to do their job well
  • build a hierarchy of stewardship from upstream to downstream i.e. throughout the publication cycle process

DON’T

  • rely on excel and macros
  • use manual processes
  • expose your firm to key-man risk
  • employ the just-in-time operating model where data is amended by client reporting and marketing teams just prior to publication
  • underestimate the impact of publishing inconsistent, untimely, inaccurate or just plain bad data!

Webcast available for on-demand playback…

August 10, 2012

For those of you who missed the recent webcast on regulation and its impact on data management strategies in the investment fund world, it is available for playback here


Webcast: The impact of upcoming regulation on data management

July 18, 2012

I am hosting a webcast on “The Impact of Upcoming Regulation on Data Management” on Wednesday 25th July 2012, 3pm BST, 10am EST.

Regulation is a key challenge in the industry and in an unprecedented age of openness and transparency continues to be the no. 1 driver for asset managers investing in data and reporting initiatives. Companies want to mitigate the risk of inaccurate information being in the public domain and many are embarking on data management projects – which will save time, reduce errors and automate processes. The key themes we see center on capability to deliver a systematic, repeatable and auditable data publication process for client-facing data.

This webcast will be presented by myself, and will focus on how upcoming regulations will impact the industry and how asset managers need to prepare to ensure they stay ahead in a highly competitive market. Specific topics to be covered include: the latest version of AIFMD, the final throes of the Retail Distribution Review, the latest on KIID for PRIPS, UCITS V, how being important or “SIFI” is no longer so desirable, Volcker, FATCA and last but certainly not least Pillar III of Solvency II.

Finally, I will touch on what is around the corner and run through some recommendations with respect to preparing for the swathe of upcoming regulatory change.

To register for this webcast please click here.

I look forward to welcoming you online on July 25th.


Thoughts from TSAM (Part 2)

March 26, 2012

Following my most recent blog on the panel discussion held at TSAM in London recently, I thought I would add some further notes on the discussion. We had talked about buzzwords used and then about data governance… The theme of the discussion then switched to the risks you’re exposed to from miscommunication of information or data – the commentary is really as you would expect:

• Fines from regulators

• …which can lead to brand damage

• …which can lead to loss of clients and mandates

• …which does lead to outflows

• …which does directly impact your bottom line

Of course, the point was made that you do not need be fined by the regulator to incur the spectre of spectacular outflows – poor data quality in client communications is enough to trigger this alone.

I related a specific story I had been told by a director of institutional sales at a prospect I met in not too distant past, who earlier that month had got through the RFP process for a serious eleven figure mandate, which would generate many tens of millions in fees. So having got through the RFP process, this manager clearly had the right risk/performance figures to meet the minimum hurdle for inclusion in the beauty parade process. The deal was lost though on one critical point – the data presented at the beauty parade on the sales deck was completely at odds with the strategy performance as listed in the RFP response, and yes, they did not win the mandate. If you are handing someone billions and billions to manage you need to build a relationship based on trust and transparency and having inconsistent/inaccurate data leads to total breakdown in trust.

The topic switched again at this point to how can we get IT and business working together more effectively on data management projects. This topic generated lots of interesting viewpoints, which I have summarized here in bullet form:

• Business often gets involved too late – something specific to IT led projects

• There is general consensus that business-led projects are more successful mainly as the requirements are understood earlier in the process

• The project analysts and the project manager need to have strong business domain expertise with a really good understanding of technology to bridge the gaps between two teams

• It is not easy to find analysts with good understanding of IT and business – panelists agreed that the more successful people are those who start in IT and move over to business side.

At this point the discussion started to wrap up after a few questions from the audience and each panelist gave their final thoughts on overcoming the challenges. My own thoughts were that the driver of data management projects is changing, it is no longer fear of fines, it is sales and distribution demanding timely and accurate data. Another viewpoint was that we have to do a better job to remove artificial differences between IT knowledge and business knowledge, greater effort is required to try and get people to understand each other’s point of view. As data management projects are getting more complex, clear objectives and accountability are key success factors, we have to get the right stakeholders involved and use the right language. Finally, one of the panelists said we should not see data governance as a cost!

It was a great session, and I really enjoyed sharing views with the other participants on the panel. I look forward to the next one in New York on May 16th.


Thoughts from TSAM (Part 1)

March 21, 2012

I attended Osney Media’s TSAM conference last week in London – I always enjoy the event, it brings together senior level industry practitioners for thought-provoking discussion and debate. I participated in the panel discussion in the data management stream entitled “Overcoming the challenge of communication issues within data management”. My co-panellists were Shannon Walker, Business Architect – Finance Change, Deutsche Bank, Arun Sarwal, CEO Investment Management Solutions at DST Global Solutions and David Renn, Head of the Data Management practice at Citisoft. The discussion was moderated by Gary Pringle, Vice President, J.P. Morgan Asset Management.

There were a few areas covered in the discussion. First-up, we talked about buzzwords we use in data management … the theme quickly turned into – buzzwords that cause most confusion. There was fairly unanimous agreement that the expression “meta-data” was the most misunderstood buzzword being bandied about and the one that causes most confusion – so meta data is data about data – everyone clear on that – but then it splits into meta-content (data about the data content) and meta-structure (data about the structure and data container). Other buzz words the panel agreed caused confusion:

  • “Data-Warehouse” versus “Data-Mart” versus “Data-Store” versus “Data-Hub”; then, what about “silo”, “operational data store”, “historical data stores”, “as-of  / effective on data stores”.

One thing the panel unanimously agreed was that data warehousing is a toxic term at C-level! Maybe this is why so many different other expressions have evolved to describe data warehouse like systems….

  • Managed Data Services – a lot of vendors are in the market with data management in the cloud with value-added “managed data services” (yes I am one of them…..) but each vendor means different things when they bandy that term about – where the managed data service starts and ends on a vendor by vendor basis can be extreme..

The theme of the discussion then changed to ‘Governance’ and how strong governance could lead to lower risk – as expected no one had a contrary argument – but the views of the panel were quite clear on one point – many firms talk the talk about governance, they have appointed their Chief Data Officer or Tsar, but in general there is not enough bite or budget connected to the role to allow it operate efficiently. My own views are fairly black and white on this point – too many firms pay lip service to the application of an efficient stewardship function that actually walks the walk that the governance speaks to – governance (strategy) without stewardship (tactical execution) is a pointless window dressing exercise.

There were many comments in earlier discussions that mandates now routinely ask in-depth questions on the governance structures in place, expect these due diligences to extend into examination of the tactical application of the governance to expose the level of stewardship in the firm and its relative effectiveness in carrying out the governance remit.

My own views on governance and the reasons it remains an area for investment are simple

  • Governance with effective stewardship will drive costs lower and reduce risk exposure
  • It positions firms to take control of their own data
  • There are demands in the front-office from distribution to broaden the depth and breadth of data and demands for a more agile approach to product data publication cycles
  • Data is the oil in the sales engine – without oil the engine cannot run, with dirty oil the engine will run but eventually seize up.
  • The increased demands for data quality, depth and breadth is driving requirements for scale in compliance and audit
  • The cost of managing data is going up and firms not set to scale in this area are being left behind.

I will end this section of the blog here, as it’s getting quite long and I’ll post another one about the rest of the discussion in a few days time.


Where are you on the Data Governance evolution scale?

February 27, 2012
This post was recently published on TABBFORUM (21st February)

Just about every asset management firm now claims to have a formal data governance process in place – in fact if firms aren’t saying this we should be worried indeed. So while all data quality management governance processes may be created as equals, they are very rarely at the same point of evolution – with the bottom of the evolution scale being a million miles from the top-end fully evolved processes.

In the diagram below you can see that processes in the early stages of evolution start as chaotic processes, with often low levels of standards and formal operating procedures, with very little sign of an obvious ‘master plan’  or strategy.

Data Governance Evolution - from Chaotic to Predictive

The Data Governance Evolution Scale

In order to move to the next stage on the evolution scale, you need to establish standards, you need formal operating procedures for data stewards such that a semblance of an operating data quality management process starts to take effect with a strategy and master plan identified and communicated to the applicable stakeholders.

The mid-point in the evolution scale is achieved when the process can be accurately described as defined – that is where you have identified key performance indicators that show the health of your process, where you have documented artefacts such as a data dictionary and rules dictionary, where you can show you have stewardship operating across the breadth of the data creation to data consumption processes, with applicable technology frameworks in place to support stewardship of the governance with key processes like root cause analysis being tracked and measured.

Very few firms have moved past the ‘defined’ stage in the evolution process. Getting to the next stage ‘Pro-active’ requires serious attention and investment and very often monumental cultural re-alignment. Pro-active governance is achieved when you can demonstrate a cast iron continuous improvement cycle, with error feedback loops constantly leading to process improvement – very much in the model of six sigma – in fact many firms who have attained this level, do so under the auspices of an investment in ISO9000 or Six Sigma. At this point of evolution, the firm is applying automation across the board to root out the manual human errors that plague many firms today. Key to the approach is a unified governance approach to how data is managed across all of the data silos in the firm.

Finally, you have reached the nirvana point of evolution when your data quality governance has become what many refer to as ‘Pre-dictive’. At this point of evolution, not only is the process fully automated, it also has a fully demonstrable audit trail that fosters accountability and ownership. The top-down strategy is fully in tune with the bottom-up application of the strategy, with complete cultural alignment across the breadth of the firm, effectively with the people, the process and technology all working in harmony. At this point, your process feedback loops are fine tuning, rather than fixing.


Follow

Get every new post delivered to your Inbox.

Join 26 other followers