The benefits of performance and attribution (P&A) reporting are well documented. What is less understood, are the operational and Information Technology (‘IT’) challenges that arise as P&A reporting becomes more sophisticated.
P&A reporting provides investors with insights on how their financial professionals have added (or subtracted) value and it provides the investment community with an important tool to improve their investment management processes.
Whilst straightforward P&A reporting has modest impacts on operations and IT, in our experience, there is an exponential increase in operational complexity as the complexity of P&A reporting rises.
An ‘unscientific’ analysis of operational challenges in performance & attribution
As performance reporting becomes more complex there is a geometric impact on operations and IT.
At some point operational / IT capacity is met and any further complexity decreases capability of the perrmance function.
Customer / gatekeeper expectations often do not recognise these constraints.
The Key Operational and IT Challenges
It’s all about the Data!
A common analogy used by consultants to describe the high reliance on data is to picture an immaculate bathroom with all the modern conveniences. This bathroom represents the latest and greatest P&A system. Now imagine the architect overlooked the need for plumbing! Still looks impressive but probably useless. In our analogy the plumbing represents the data.
Whilst plumbing is rarely overlooked in a bathroom renovation, unfortunately the same cannot be said for P&A solutions. In fact, in our experience, optimistic assumptions are made too frequently regarding external parties’ ability to deliver reliable, timely and accurate data causing data integrity to be the single biggest contributor to delivering a sub optimal outcome. Also, licencing restrictions regularly prevent the ability to re-use market data.
In short, the bathroom is designed either without the pipes or with incorrect assumptions about how the existing pipes may be re-used.
Attribution Gets Personal!
To be a successful active investment manager you need an approach that differentiates you from the crowd. It is very likely that this uniqueness transfers to your portfolio management and your requirements on performance attribution.
Whilst this requirement for ‘uniqueness’ is understandable it presents challenges to operations and IT who love to deliver standardised and scalable solutions. Like the data issue, the requirements for customised P&A are significant contributors to operational and IT issues, particularly where intimate understanding of the firm’s investment philosophy is required.
The days of using Microsoft Financials (aka. Spreadsheets) to generate these customised reports are numbered. Firms now need to demonstrate that attribution reporting can be produced independently from the front office using reputable systems and robust processes.
Being Transparent Isn’t Easy
There are many different ways to access a particular investment. This is great for diversification and can reduce the cost and risk of investing but it creates real headaches for P&A.
Traditionally, instruments are a wrapper for the underlying assets and therefore have little value to P&A, which usually focuses on those underlying investments. Consequently, ‘clients’ (investment manager, investor, regulator) now demand for a look through reporting which is almost impossible to operationally support.
Leaving aside the legal restrictions that prevent a manager from gaining access to the underlying assets’ details from external parties, many investment systems and operational processes are ill-equipped to support this level of granularity.
Further, additional adjustments, such as re-scaling of investments to reflect a fund’s correct asset allocations, are not very well supported within most operational environments.
So What Can Be Done?
Let me first acknowledge that many of these issues do not have immediate solutions and in some cases may be ‘unsolvable’. (i.e. the requirement exceeds the operational and IT capacity of the organisation).
However, the issue is not that the requirement cannot be met, it is rather that the expectation on the P&A function exceeds its capacity, causing at best frustration from the client or at worst operational and performance errors.
Through numerous client engagements to select and deploy P&A solutions, we have developed a process that we believe helps define operational limits and to manage customer expectations in the context of these. Predictably, this starts with a diagram….
Step 1 – Agree (and challenge) Business Requirements
I am constantly surprised at how the fundamental task of defining business requirements is overlooked. This is the most important aspect to understand and manage customer expectations, particularly when these will push or exceed the operational constraint of the business.
For complex requirements we suggest that a business case be prepared to explain why it is required and what would happen if the requirement could not be met. Further there should be a process in place to periodically re-validate these requirements to ensure they are still relevant. The old saying of you can have it “quick, accurate or cheap, pick 1 out of 3” is a useful means of managing customer expectations!
Once a suitable P&A solution that meets these requirements is identified, the stakeholders need to be briefed and agree on exactly what the P&A solution is going to deliver.
The key priorities may differ from some of the initial requirements but this could be due to unrealistic initial expectations being set.
Step 2 – Complete an Operating Model Design
Prior to implementing a P&A solution, the operating model should be formalised. Specific things to consider here are:
- What reporting will be produced by operations and the investment team. It may make sense to retain ‘decision support’ attribution within the investment team as this is often tailored to the investment managers’ process.
- Whether the opportunity exists to outsource some/all reporting to an external party such as a custodian or managed service provider that offers a ‘software as a service’ solution.
- What business processes are required to support the P&A function. In this context, process design is critical, especially regarding security benchmark & classification structure maintenance, exception processing for incorrect input data, etc.
Step 3 – Define the required IT architecture
Investing in IT architecture will ensure that the P&A requirements are matched against the organisation’s current or intended IT capability and that a plan exists to address both functionality and data requirements. In short, having a well defined IT architecture will ensure that you avoid, amongst other things, the problem of ignoring the ‘plumbing’ when constructing the ‘bathroom’.
In constructing an IT architecture we believe that multiple views are required:
- Application Architecture – A logical view of the systems required to address the functional requirements of P&A and the preferred deployment model (e.g. multiple ‘best of breed’ vs single integrated application)
- Data Architecture – A view of data flows required to support P&A (portfolio data, pricing data, benchmark data)
- Integration Architecture – Overview of intended integration model between P&A system(s) and other applications
The next challenge is to get to the right level of detail so that it provides the necessary guidance for implementation without being overly prescriptive.
A key guiding principle should be “Will this document/diagram help assess the feasibility (and cost) of the proposed solution, guide the implementation or improve the level of understanding of the solution?” If the answer to these questions is “no” then there is no value in producing it, regardless of what is ‘viewed’ as best practice.
Step 4 – Complete a Service Level Agreement
So business requirements have been gathered and operating models and IT architectures have been designed. Now what?
Preparation, analysis, delivery and management of P&A reporting to ‘clients’ can be considered a ‘service’ regardless of whether it is completed internally or outsourced. With respect to the latter, there is the general expectation that a service level agreement is implemented and our view is that this principle should also apply to internal services. This will ensure that the expectations of the clients are properly scoped and also assist with capacity planning and monitoring of service levels against agreed key performance indicators.
There may be less need for ‘formal’ service agreements between internal departments but this does not remove the need for service expectations being agreed, documented and measured.