An Investment Book of Record, defined according the 2014 Global IBOR Standard, can provide many benefits for an Asset Manager. Such benefits include solutions to common problems that stem from existing systems, for both best-of-breed or all-in-one / front-to-back system setups. In this article, we explore 5 business problem that well-designed IBOR Software can solve, categorised in two areas.
This article is co-authored by Kristoffer Fürst, CEO of Limina and Doctor Ian Hunt, independent consultant and IBOR expert.
For full disclosure: Part of why we started Limina back in 2014 was our recognition of the challenges in trusting and accessing position data. Hence, Limina’s Investment Management System has a core which is a live extract Investment Book of Record. This post isn't, however, a pitch for our solution, or any other solution. Rather, as former investment managers, we want to present a coherent business-level view of the topic: we’ve found this difficult to access to date. Hence, we created this article which is part of a series about IBOR Solutions. If you want to explore how Limina compares to the Global IBOR standard, you can access the line-by-line Limina vs IBOR comparison here.
An Investment Book of Record is sometimes said to be a single "correct" version of positions. If so, the resulting portfolio view of positions and cash would be a indisputable truth. This, however, is an oversimplified view.
Position "correctness" depends on the perspective of the consumer of the position. Different investment roles require different position views.
How many buy-side firms have the ability to support their teams with the right portfolio data and position data? In a survey of asset managers, 82% of respondents indicated they don’t have sufficient overview of positions.
This is what a “live extract” IBOR sets out to solve, as defined in the 2014 Global IBOR Standard created by a consortium of Asset Managers.
The primary goal of an Investment Book of Record is to deliver accurate, complete & real-time portfolio data (i.e. position and cash views) to all users of portfolio views. The last part can’t be emphasised strongly enough: your team members are the ultimate beneficiaries of an IBOR, empowering them to carry out their responsibilities, including investment decision-making, with confidence that they can:
To be able to get here, an IBOR solution must be able not only to create such data, but also to feed it to trading systems, risk systems, reporting systems etc. It must also be the basis of any reconciliation.
A key IBOR benefit is downside protection: it minimises the risk of getting something wrong.
The start-of-day (SOD) is the portfolio state (positions and cash levels) that results from the previous day’s accounting close, enriched with known movements overnight. In a flush/refresh architecture, the SOD portfolio state is loaded into a Front Office system (e.g. an Order Management System) every morning. Typically, the SOD snapshot comes from an accounting system or an outsourcing provider. This approach is fragile, as the snapshot may suffer from delay or missing information. When this happens, the Front Office system can’t function effectively, causing frustration or impaired performance at best, and compliance breaches at worst.
Another issue with the start-of-day load is that the Front Office system can’t be relied upon for a duality check against other systems. A ‘duality check’ is a control where two systems or service providers produce portfolio views and/or calculations, e.g. P&L or NAV, independent of each other. Both views are then compared and any difference is investigated as a reconciliation break. We all know Back Office mistakes inevitably happen, which are at best found a day later when it’s too late to address, or at worst never found, and neutralised out as an adjustment. These could be caught (earlier) if the IBOR, and therefore the Front Office system, wasn’t dependent on start-of-day snapshots.
The third problem with start-of-day data is that the accounting system might not have all data, such as future corporate actions, cash payments, accruals etc. As a direct consequence, systems that depend on a start-of-day data load can’t effectively be used for future projection, e.g. projecting cash or exposures.
A live extract Investment Book of Record resolves all these three problems caused by a start-of-day position load.
The IBOR Global Standard outlines position data that might today be missing in conventional Front Office systems:
With part of the data above missing in the Front Office system, investment teams can’t make precise decisions. With missing data, targeting a low cash level becomes impossible which, over time, will cause a cash drag on your performance. This can be critical in, for example, a tracker portfolio, where imprecision in cash leads to tracking error at best and an overdraft at worst.
With one view of positions, for example, a view based on accounting postings, you’re severely limited. Examples or problems related to data inaccuracy include:
IBORs provide a flexible definition of positions for all users, including Front Office, by maintaining a centralised and accurate record of all transactions. As the Investment Book of Record extracts live views of the portfolio and positions from the transactions, this enables Front Office users to make informed investment decisions based on real-time, complete, and accurate portfolio data.
The important thing for an Investment Book of Record is not that it should deliver a single version of the truth, but that it should deliver consistent views of positions, based on the same underlying transaction data, and crafted to meet the diverse needs of users.
This might at first glance seem like it will create more work for your operations team, to “maintain many position views”, but the reality is the opposite. The current operating model causes unnecessary reconciliation issues, and often shadow positions are also maintained on spreadsheets etc to give managers more control over, and more confidence in, their position data. With one place (the IBOR) that has the complete time series of all transactions, you don’t maintain positions at all, just one series of the underlying transaction data. Positions are then created on request.
For this second section of the article, we’ll explore two complications with operating models that lack a live extract IBOR and how it’s causing inefficiencies.
The first era of systems on the buy-side were dominated by ‘best-of-breed’ approaches. Under best-of-breed, different business areas in the asset manager would select the platforms which best suited them, and the platforms were then strung together across an integration architecture.
For the manufacturers of best-of-breed platforms, there was an obvious design issue: they couldn’t rely on the structure, completeness, or integrity of the data environments into which they would be implemented. It would be different in every context. As a result, every best-of-breed platform had to carry its own self-contained capability in market data management, transaction data management, position data management etc. The consequence was that asset managers commonly maintained, in parallel, multiple stores of overlapping data, and had to manage the inconsistencies (and live with the inefficiencies) that this implies.
The second, and current, trend is towards outsourcing and front-to-back or front-to-mid platforms, like SimCorp Dimension, Blackrock Aladdin IBOR and Limina. Such platforms however will never be the only software that an investment manager relies upon. Hence, ease of connectivity is still key. While broader systems reduce integration complexity, they don't magically solve the challenge.
There are various ways in which an Investment Book of Record can approach integrations to other asset management systems and service providers.
To “glue systems together”, large asset managers often rely on Data Management platforms (like Markit EDM) or data warehouses (like Eagle and Netik), that serve as an integration layer. Systems like these typically have exception-based workflows to manage data issues that inevitably arise through multiple system interconnectivity.
For mid-sized asset managers, either
For Middle Office and operations, an Investment Book of Record could deliver the needed portfolio data management capabilities. This means fewer systems and more powerful, exception-based workflows, spanning a broader segment of the middle office.
We believe that an IBOR can help to address all of these problems, if:
As you can see, the primary goal of an Investment Book of Record is to deliver accurate, complete & real-time portfolio data, and it should unlock both scalability and flexibility by providing a single source of truth. It’s our hope that this post was informative around the problems that an IBOR sets out to address.
If you’d like to explore the concrete day-to-day use cases of an IBOR, contact us to arrange a demo.