Look-through transparency for performance and risk-practical considerations, challenges, and opportunities
For many years asset managers have made use of their own managed (pooled) funds for implementing investment strategies. More recently there has been an increased use of other assets, such as ETFs, index derivatives, and other managers’ mutual funds for diversification purposes, exposure to additional markets and the need to provide additional sources of alpha. To be able to understand and analyze the full exposure of these types of portfolios there is a need to expand the underlying assets of the funds, or other entities held within the portfolio’s structure. This capability is known as either ‘fund-in-fund’, ‘look-through’, or ‘transparency’ analysis (for the purpose of this article, look-through will be used). Far from being a ‘nice to have’ requirement, look-through transparency is now considered as an essential and critical component of portfolio analytics platforms. But when is look-through required? What are the practical considerations, challenges, and benefits of look-through analysis? In detailed terms, what should asset managers be looking for from their vendors in terms of providing look-through transparency?
Look-through provides analysis of underlying exposures for both performance and risk, so the capability to provide this functionality for both purposes, based on a single source of data, would clearly be a benefit to many asset managers.
There are however differences between risk and performance look-through requirements, particularly in terms of the treatment of valuation dates of a parent portfolio and the underlying fund/asset data. For risk purposes, if data is not available for the same valuation date - at all levels, it may be acceptable to look-back a few days to obtain the relevant underlying valuation data (i.e. the requirement for look-through may effectively override the requirement not to look-back). For performance purposes however, it is expected that parent and underlying fund data would generally have the same effective dates – there is a need for a high degree of consistency, otherwise the differences will be manifested as a significant residual. There are specific cases, however, where the underlying fund's data actually applies to different effective end-dates (e.g. investment in overseas mutual funds in different time zones) – but how can the system know where this should apply? It is worth checking your vendors approach to such cases.
Periodicity of Data
For performance there is the added complication of the periodicity of data. For look-through there is a need to ensure that the periodicity across the full portfolio structure is consistent. This entails, in some cases, first chain-linking the underlying fund data to the periodicity of the parent portfolio (where this is for longer periods). Where underlying portfolio data is not available however (e.g. the parent portfolio is daily but the underlying portfolio is weekly), then obviously look-through can only be applied on the common dates.
For looking through an asset which is a fund managed by the asset manager themselves, this is then relatively straightforward as the data should be available for the fund and easily mapped. For other cases however, such as looking through an index future, there may be index availability or entitlement issues, which would make the use of a proxy, such as a similar ETF, a viable alternative. Therefore, it would be desirable to have some degree of flexibility in the selection of the underlying entities mapped to the looked-through assets.
Which assets should be looked-through? Whilst it is self-evident that only assets that are linked to underlying entities where data is available can be looked-through, there also needs to be an element of discretion to reflect the investment process. The solution should allow you to visualize the full fund-in-fund structure and allow the user to choose which assets to look-through.
Another challenge can be that it is in a more complex look-through structure; for example, the same fund may be held at multiple levels within a structure (i.e. including one or more recursive relationships). Whilst one solution would be to not look-through an asset that appears multiple times within a structure, this might not be desirable, as this is a perfectly feasible business case – so it is again worth checking your vendors approach to such cases.
For performance look-through there are a number of reasons why the total contribution of the underlying fund contributions, of a looked-through asset, may not match the contribution of the asset itself within the portfolio. This may be due to source data timing or pricing differences, fees, or currency conversion for example. As the asset manager may have little control of the underlying data, such changes may be unavailable and will inevitably result in residuals. How should these be reported and used within the analysis? Therefore, there should be options available to enable such residuals to be included or excluded, and to either be reported at the aggregated or pro-rated to the most detailed level.
When it comes to reporting there should be options for the presentation of a portfolio’s analytical results, either on a standard or looked-through basis, and as noted above, there may be multiple definitions of look-through for the same portfolio. How should the full set of expanded assets be classified and presented? Again this may be a completely different view or classification which is then applied to the ‘fund-in-fund structure’. However, there may also be the requirement to provide a view which keeps the reference of the underlying expanded assets to their parent funds. Flexibility is a key requirement.
A final challenge is more of a technological one. For some large look-throughs the resulting fund-in-fund structure may result in thousands of securities. Of course, in providing complex risk analysis or fixed income attribution on these structures a robust and extremely scalable technical platform to perform these calculations is required.