Some interesting news for those following the world of Solvency II - Sweden to implement core solvency rules for insurers at year-end.
Setting up a governance program for effective management of investment product master data
This is part 6 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will briefly consider the importance of process and procedure documentation.
In my previous blog in this series, I highlighted why standards and policies are important to the task at hand. Similarly, process and procedure are also key elements of an overall program of governance for your investment product data.
If you consider the statement of your policies and standards as the clear communication of the strategy for your program, the explicit documentation of the processes and associated procedures speaks directly to the execution of the strategy.
A process is an operational workflow description that takes into account starting states, end states, resources, participant teams and individuals who interact at each stage or state in the process – a procedure on the other hand is a simply detailed set of instructions for carrying out a specific task, or part of an overall process.
If you consider the example I used in the standards and policies post:
- Policy: ”the policy in our firm is that all client requests for data must be signed off by compliance“
- Standard: “all requests from clients for bespoke client reports should be logged in the ‘reports-requested’ database by the client service team. Only users with a security role of ‘compliance authority’ will have the capability to approve a request in this database and no report shall flow to a third-party without reference to an approval record in the ‘reports-requested’ database”.
In this scenario we clearly need a detailed description of the process which starts with the event of a client request being received, ending with the delivery of the report to the client. In between the start and end points we need to clearly document the various valid paths or stages the process would need to pass through – for example, showing the logging of a request for compliance approval – this process document should call out the specific valid (and invalid) paths, stages, resources, systems and people interacting at each stage in the process. Typically, the document will contain a process flow diagram (there are tens of different diagram types) and related verbiage that explains in detail each step.
Within this process we will need a set of detailed procedure documents that explicitly call out the instructions for carrying out specific tasks – for example, you may decide you need to have a specific procedure for calling out how to log a client request into the compliance database.
From my own perspective, the definition of the processes that come under the remit of your program is a far more important task than the documentation of the procedures - get your processes down pat first, and only then start to consider the documentation of your procedures.
Next up I will explore the creation of a master data plan…
There is a really great article on the TechTarget SearchDataManagement site on data stewardship - Data stewardship program: Quality booster, but a hard step for many.
Interesting news on Solvency II Wire blog today Solvency II News: regulators consider easing Solvency II look-through.
Setting up a governance program for effective management of investment product master data – Part 5 – Standards & PoliciesFebruary 11, 2013
This is part 5 of a series of blogs on setting up a governance program for effective management of investment product data - in this blog I will briefly consider the importance of policies and standards.
So having dealt with the political hot potatoes of getting C-level buy-in, agreeing outline terms of reference and formulating a strategy, it is imperative that the governance team / tzar (depending on the level of autocracy in your firm) specify a set of clear and unambiguous policies.
Policies are required to set out the specific objectives across a range of areas, and they should be firmly rooted in the agreed strategy for the governance program.
For example – an element of the strategy could be “We will seek to apply more control to the process of publishing data into the public domain“. From this aspect of the strategy you may decide to specify certain policies that tie back to that strategic thread, for example “the policy in our firm is that all client requests for data must be signed off by compliance“. Clearly there is a relationship between the strategy and the policy…
The governance team/tzar should set out a range of policies to address the stated strategy. Be cognizant of the importance of achieving early and visible wins for the program i.e. do not spend time generating piles of documents to the detriment of delivering visible results. There will be plenty of time to broaden the program once you have some committed champions who not only believe in what you are trying to achieve but can acknowledge the actual accomplishments.
Once you have firmed up on a small set of policies that address the key elements of your strategy, the next stage is to start formulating the standards that will drive adherence to the policies – so following the above example – where ”the policy in our firm is that all client requests for data must be signed off by compliance“, one of the standards could be “all requests from clients for bespoke client reports should be logged in the ‘reports-requested’ database by the client service team. Only users with a security role of ‘compliance authority’ will have the capability to approve a request in this database and no report shall flow to a third party without reference to an approval record in the ‘reports-requested’ database”.
If you are struggling with discerning your policies from your standards there is a very good diagram here that helps communicate the differences.
The key takeaway here is to keep your initial set of policies small, and in particular relevant to the program strategy. Once you start to develop your policies into standards, and from standards into formalized processes and procedures the workload snowballs at a rapid rate and you are quickly in a place where you are just spinning your wheels and making no visible progress.
Next up I will briefly explain the movement from policies and standards, to process and procedure…
Model for Stewardship – Part 4 of “Setting up a governance program for effective management of investment product master data”February 6, 2013
The stewardship model for managing client-facing product data in an investment management business is a critical factor for success in your governance program.
If we consider governance the ‘strategy’, then stewardship is the tactical execution of that strategy i.e. the walk to the talk!
Traditionally, the mantra was to drive accountability and stewardship as close to source as possible, and while this is a good general principle to follow, you need to be careful not to apply it in a dogmatic fashion.
Asset management businesses have many layers of complexity, and the challenges experienced in the back-office can be very different to those in the middle-office, and often a million miles away from the challenges in the front-office. It is because of this diversity that Enterprise Data Management systems within an asset management business are often supplemented with niche solutions that tackle domain specific challenges – witness the change in strategy from the singular data warehouse approach for the whole business to a multi-layered EDM strategy with best-of-breed providers interacting across many interfaces.
There is also a shift in stewardship models towards a multi-tiered approach. Traditionally the best practice was to drive accountability and ownership as close to the source as possible, but this has now evolved to a multi-tiered approach. The multi-tiered approach recognizes that as information flows through a publication process that starts in the back-office and manifests itself in a client communication in the front-office, the data undergoes a metamorphosis along the way. At each stage in the process, the data is manipulated and aggregated with other streams of data into “new data” with new meaning, and the ability to handle data quality exceptions becomes more specialized.
The following (simplistic) view of the various tiers illustrates how they are often implemented.
|Tier||Business / Department||Example of interaction with the Data Quality Management (DQM) Process|
|1||IT||This steward is typically responsible for exceptions relating to timely delivery, file format and syntactical issues with the content.|
|2||Functional Team e.g. performance||This steward is typically responsible for issues relating to accuracy, completeness, consistency and staleness of data. They will be a subject matter expert for the data sub-domain in question. Note: there will be scenarios where the rule set/type is of a nature where it is not domain specific and is best handled by a product and/or portfolio specialist.|
|3-a||Product Management||Within your DQM you need to be able to direct product specific exceptions to an expert that is familiar with the product/range in question.|
|3-b||Portfolio Manager||As per the product management requirement – you will also need access to a portfolio specialist to deal with issues directly relating to the strategy and potentially specific intelligence on holdings / securities at the root of an exception.|
|4-a||Marketing Operations||Once data is brought together for publication you will need expertise to deal with layout / presentation exceptions.|
|4-b||Compliance||Finally, you may require input from a stewardship perspective for certain exceptions – for example, if you had a mandate breach, where specific knowledge is needed to move forward.|
The next blog in this series will focus on the importance of establishing standards and policies.
Setting up a governance program for effective management of investment product master data – Part 3 – Defining the StrategyJanuary 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:
- Stakeholders have all been identified and there is a broad (high-level) RACI matrix in place for each party
- C-Level engagement has happened and there has been formal buy-in that the program is needed
- Terms of reference have been drafted and agreed by all stakeholders and outline budgets and business cases documented in full
- 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…
As posted in Ignites Q&A of the week on 25th January, I thought I would share my response here
What is the potential impact on the industry now that some mutual fund firms are starting to disclose daily NAVs for their money market funds?
Scrutiny of money market funds has never been more intense, and the industry must prepare for further changes to the regulatory regime. Specifically, daily disclosure of money market funds’ net asset value (NAV) has become a reality, and that will have ripple effects throughout the industry.
Some of the key players in the money market fund business have taken a pre-emptive move to provide the transparency that regulators and investors have been demanding since the Reserve Primary Fund broke the buck in September 2008.
The daily NAV disclosures are obviously a step toward improving fund firms’ client services to investors. Clearly, it will benefit investors by increasing transparency and helping them to better understand money market funds and their risks. But there will be operational and compliance challenges coming from this trend that fund firms must consider. Some of the measures firms will have to implement include the following:
- Reassess existing investment processes. Fund firms will need to reevaluate their investment process to ensure that the daily shadow NAV does not materially deviate from the buck;
- Strengthen data-reporting process. They will need to ensure they have a systematic, auditable and repeatable process for distribution of the data to market; and
- Reevaluate communications strategy. Fund firms will need to reevaluate how they communicate the NAV to the market and gauge any potential impacts on their marketing and regulatory documents that are in the public domain.
Daily disclosure of the NAV for a money market fund gives investors the reassurance that the fund manager is committed to being transparent and open about the current state of the fund. In the past, most money managers were distributing this data monthly, which led to a level of investor angst that the fund manager was not always showing all their cards.
The breadth of securities that money market funds invest in means that each holding can have multiple levels of credit exposure, and so for many, transparency is a must.
In order to deliver the NAV daily, firms need 100% belief in their investment process. The shadow NAV must not deviate materially from the buck on an intra-month basis. Firms that are publishing daily NAVs will most likely guarantee redemptions at the buck if the shadow NAV drops below the buck.
Beyond daily NAV publication, I expect to see more announcements from asset managers on moves toward becoming more transparent in other areas as well. One of the key demands from regulators and investors is the timeliness of the publication of portfolio holdings.
Current practice sees most managers publishing data quarterly, with some publishing monthly. However, in nearly all cases, the data is embargoed or time-lagged to prevent front-running and free-riding. There is considerable pressure being brought to bear by institutional investors and regulators to increase frequency of publication to monthly across the board and reduce the embargo periods. Some asset managers are preparing for a situation where they believe ultimately a daily reporting of holdings will be demanded.
One of the biggest obstacles to becoming more transparent can be the exposure to manual processes. Fund product data comes from a variety of different sources and has to be checked and double-checked before the information can be released. An organization that validates its product data at the source and stores it efficiently can ensure it is always ready for publication. It is vital for fund firms to get their product data to market on a timely basis, ensuring it is always accurate and consistent. That includes daily money fund NAVs.
Firms must also consider the impact on marketing and regulatory documents that they distribute to the market, including their own website, in the context of any data reporting trends. Additionally, they should review how the external distribution networks, platforms, broker-dealers and other intermediaries will be impacted by any change to daily publication on short notice.
I am delighted to see this move toward transparency represented by the daily disclosure of money market funds’ NAVs.
We are going to hear more and more about investor and regulator demands for more information as the pressure to deliver transparency continues to grow. The overriding themes in asset management for the next 10 years will involve transparency and risk.
To adapt to the current environment, fund firms, especially those offering money market funds, should reassess existing investment processes, strengthen their data-reporting process and re-evaluate their communications strategy.
Welcome to my new blog - On Solvency II, Transparency and other Musings. This is my first post. Hope you enjoy it... John
The decade of regulation is amongst us – there are regulations coming at us from all angles – just consider everything from FATCA to Dodd Frank, Solvency II to UCITS V, AIFMD to EMIR, Basel III to UCITS V – we are literally being bombarded.
Basel Committee issues "Principles for effective risk data aggregation and risk reporting - final document"January 24, 2013
Today, 9th Jan 2013, the Basel Committee on Banking Supervision issued a press release announcing the final document "Principles for effective risk data aggregation and risk reporting.
I wrote two posts on the consultation paper, when it was issued in June 2012.