Recurring challenges in investment calculations prompt the need for an investment calculation layer, evident in various client contexts and software architectures. Drawing from experience, implementing this layer offers distinct advantages by efficiently handling basic, pre-calculated, and missing facts, enhancing system responsiveness and data consistency. Ultimately, the investment calculation layer bridges domain-specific precision with the agility of a BI tool, a synergy elaborated in the article.
What are investment calculations?
Financial investors need to know many facts about the investment portfolio. Facts are the basis for their decision-making. Important facts are about performance, asset allocations and risk metrics. Professional investors also relate most facts to benchmarks.
Some of the facts are basic, for instance the number of shares held of a certain company. Others are calculated, for instance the year-to-date portfolio return or the percentage of USD-bonds in a balanced portfolio. In this blog post, we care mostly about calculated facts, which are the result of investment calculations.
Investment calculations in reporting
All book of records systems (and portfolio management systems) provide basic facts and a variety of calculated facts. Experience shows that for reporting purposes, additional calculations are needed. A simple example is a breakdown into buckets of time to maturity, or some special kind of net return.
These additional calculations are performed by the reporting system itself. Therefore, it is fair to say that every reporting system deals with three types of facts: basic, pre-calculated, and self-calculated facts. Even though it has no control over the former two, it must consider all three types in a consistent manner.
There is also the problem of combinatorial explosions: For instance, it is unmanageable to pre-calculate contribution figures for every time period and every possible aggregation level (especially for money weighted returns). The calculational load would burden the system unnecessarily or might even be impossible to carry out.
The question arises: How to deal with investment calculations? Ideally, where should they be located?
What about portfolio management software ?
Looking at possible answers, a portfolio management software (PMS) may seem the appropriate place. After all, a PMS is meant to keep track of portfolios and is often able to calculate most of the figures required for investment reporting. But a PMS is optimized for portfolio managers who need both a current and an ex-ante view. In investment reporting, however, an ex-post view is required. This involves extensive past time periods and therefore a lot of data. For a typical PMS, these calculations are way too intense. Furthermore, portfolio management systems often cannot handle pre-calculated data from other sources or corrections in the past, to name but a few additional shortcomings.
What about business intelligence tools?
Looking further, a business intelligence (BI) tool may seem to be an appropriate choice for investment calculations. It easily operates on data marts, slices and dices our data cubes and delivers many pieces of analysis within only a few clicks.
However, BI tools specialize in ad-hoc analysis. They were never intended for long, recurring investment calculations. Nor can they excel at non-linear functions like performance measurement. But most importantly, they are not geared towards the investment domain (nor any domain, for that matter). In fact, they lack the typically needed investment calculations.
This is why you need an investment calculation layer
Addressing the need for investment calculations seems to be a recurring problem, found with many clients and software architectures. We have built both, reporting solutions with and without an investment calculation layer. From that experience we can definitely say that implementing such a layer offers clear advantages.
Naturally, this special layer supports both basic facts and pre-calculated facts from source systems. But most importantly, it pre-calculates missing facts or calculates them during report creation. Efficiency is key (especially for online applications), as some facts cannot be pre-calculated (due to the combinatorial explosion). Through transparent caching, the investment calculation layer adds to system responsiveness even further.
Another key requirement is data consistency. Remember, basic facts and pre-calculated facts must be accommodated in a consistent manner, without redundancy. A good example for this is aligning signed-off portfolio returns with bottom-up returns.
In summary, with an investment calculation layer you get the domain specifics of a PMS and the speed of a BI tool. How to make that layer both consistent and efficient will be explored in a future blog post.
Get news on client reporting,
trends, white papers and more.
Subscribe to our blog articles.