Front-to-Back System vs IBOR Platform: Which one should you adopt?
While both systems solve investment data challenges, understanding the difference between a front-to-back-office platform and an Investment Book of Record is crucial for asset managers to effectively investment operations, streamline processes, and ultimately: to make the most informed investment decisions.
Co-authored by Kristoffer Fürst, CEO of Limina and Doctor Ian Hunt, independent consultant and IBOR expert, this article aims to contrast and compare the decision to adopt a front-to-back-office platform and/or a live extract Investment Book of Record. We’ll ground the comparison in reality, i.e. base it on what vendor solutions are available today and might soon be available.
For full disclosure: Part of why we started Limina back in 2014 was our recognition of the challenges in trusting and accessing real-time position data. Hence, Limina’s Investment Management System has an Investment Book of Record core. But this post isn’t a pitch for our - or any other - system. 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 complete guide on IBOR Software. 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.
What are IBOR and Front-to-back-Office Platform
A front-to-back-office platform has capabilities spanning most functional areas and users involved in the investment management process. It covers users in the front office, middle office and back office. For example:
- Portfolio Manager
- Trader
- Compliance
- Risk Manager
- Trade Processing Team
- Operations Staff
- Accounting
At the same time, the goal of an IBOR Platform is to deliver complete, accurate and timely (including real-time) positions. By ‘positions’ we mean any components of a portfolio, i.e. holdings of all types, including securities, derivative contracts, cash and accruals.
From these two descriptions, we can conclude that an IBOR and a front-to-back-office platform are not mutually exclusive, which is conceptually correct.
A front-to-back-office platform has to have position management as a central component of its functionality. While there have been some improvements in position management, there is no F2B platform whose position management capabilities meet the IBOR Global Standard.
In this post, we’ll investigate the appeal of an IBOR, as well as the appeal of front-to-back technology (and we’ll discover it’s sometimes the same!). We’ll also look concretely at some of the current vendors and what the future might hold.
Front-to-Back-Office and IBOR Platforms both solve data management issues
- An IBOR solves data management challenges by enabling higher-quality data. I.e. complete, accurate and timely (including real-time) portfolio data. However, to make the high quality data useable, it needs to be integrated into your investment systems.
- A front to back-office platform solves data management issues by covering a wider set of business functions within the same platform, thereby reducing the number of integrations between your investment systems. However, the position data shared across business functions might not be as complete, accurate or timely as we would wish it to be!
Wouldn’t it be great to have both? It would, but that solution doesn’t exist - yet. We’ll list some vendors further down in the post, but first, let’s look at common position management approaches that don’t adhere to the IBOR Global Standard.
ABOR (Accounting Book of Record) vs IBOR (Investment Book of Record)
The Accounting Book of Record (ABOR) was created to serve one position management use case: the general ledger. There is a significant difference between middle office vs back office requirements.
The ABOR has some of the functionality that the IBOR Global Standard outlines, such as the accommodation of back-dated amendments. However, it generally has no visibility of investment strategies, since these don’t affect accounting. Most importantly, however, it only includes transactions when they are posted, and doesn’t reflect state changes in the transaction before or after posting. This is illustrated below:
A useful way to think about the Accounting Book of Record is:
- It’s a subset of the IBOR capabilities; and/or
- It’s an input source to the IBOR.
For example, if accounting is outsourced to a service provider, then the Accounting Book of Record is maintained by that provider. In this case, the IBOR might read some of its data from the ABOR as input (e.g deposits, redemptions. fees…). The IBOR and ABOR might also be reconciled against each other, to ensure that the ABOR hasn’t missed any known movements coming in from e.g. trading activities or corporate actions of which the IBOR will have early visibility.
The rolling balance approach deployed by-Front-to-Back-Office platforms
Rolling balance approaches adopted by modern (or less dated) front, middle and back office platforms took back responsibility for completeness from accounting. This approach set out to deliver an earlier, coherent set of positions which was generally a near real-time, constantly updated position.
In the rolling balance approach, position changes are based on a set of posting rules, determining when positions would be updated. Positions are maintained as a constantly updated inventory, rather than derived live from transaction history or as an enhanced accounting snapshot.
Position management operating on a rolling balance basis is limited in its ability to represent multi-state and bi-temporal views of position data. Furthermore, there is a limit to how many separate balances it is practical to maintain. Regardless of the number of time series stored, access to historic positions depends on snapshots of balances being persisted in a data warehouse which limits the data that users can extract.
Forecasts aren’t supported by rolling balances (at least not natively – these generally depend on external systems, such as treasury), and rolling balance solutions struggle to answer questions about positions based on earlier versions of transaction data.
Read about more Investment Book of Record use cases here.
Investment Book of Record platform doesn't need to have business functionality
An interesting risk management perspective is that:
- A risk system is a beneficiary of IBOR because it can be fed accurate and complete portfolio data, in whatever state, and with whatever data timing and effective timing it requires. Concretely, such data can include adjustments and/or be the view that portfolio managers saw when planning and placing an order.
- At the same time, the operational risk of a mistake is also reduced by a Generation 3 live extract IBOR. By being able to trust positions, through a complete view that makes most sense to them, portfolio managers are less likely to make mistakes grounded in data errors.
For the latter to really work well, however, the IBOR must integrate fully and in real-time with all business level applications. This is not as straightforward as it might sound and we discuss this topic further down in the vendor comparison section of this article.
A Front-to-Middle-to-Back platform simplifies integration
Current trends in buy-side architecture favour outsourcing and front-to-back-office platforms, like Simcorp IBOR and Blackrock Aladdin IBOR. Before this, technical architecture in asset management was dominated by ‘best-of-breed’ approaches. Under best-of-breed, different business functions in the asset management firm select the application which best suits them, and the applications are then strung together across an integration architecture. Data management platforms (like Markit EDM) and data warehouses (like Eagle and Netik) sprung up to facilitate this integration, and to bring data together from disparate sources; they were integral components of best-of-breed technology.
As asset managers’ functional barriers have gradually been broken down (for example, risk and compliance now being an integral part of investment workflows), best-of-breed architectures have resulted in increasingly fragmented workflows. The front-to-back-office platforms offer a simple approach to resolving this, by integrating most functionality within a single system.
However, if the position management of such a platform doesn’t fulfil the IBOR Global Standard, it will still struggle to provide accurate, complete, and timely position data for all use cases.
Furthermore, a single platform can’t be the “true” source record of all data. For example, the custodian will be the prime record of some transactions, particularly in cash. Any platform or IBOR must accept this fact and should be designed accordingly, i.e. to integrate with the primary data source of each record, and to have the functionality to highlight if any data is suspected to be delayed or missing.
Vendor examples
Below we detail some examples of vendor solutions categorised by type to help you understand which combination of solutions will meet your needs:
1. Front-to-Back-Office Platforms with rolling balance IBOR
Large-scale front-to-back-office platforms typically operate position management on a rolling balance basis. With such platforms, you alleviate much of the fragmentation and integration overhead.
However, the offering becomes sub-optimal because it’s limited by the rolling balance constructs itself, and inevitably fails to deliver to the full set of standard IBOR requirements.
2. Front-to-Middle-Office Platform (F2M) with rolling balance IBOR
These are “transaction-based” trade order management software, for example, Bloomberg Asset and Investment Manager (AIM). Compared to the previous category, these systems are typically somewhat narrower in scope (not including back-office capabilities) and the price tag is hence lower. Depending on the overall setup of the business, there may be no need for full back-office capabilities, and hence a front-to-middle-office system might be adequate. This would be the case, for example, where back-office operations are outsourced.
3. Live extract IBOR technologies, with limited business functionality
This category is relatively new emerging from 2014 when the Global Standard was released, and onwards.
Finbourne is an example in this category who started as an IBOR initiative and have hence added more generic investment data management capabilities. They describe their solution as: “a consolidated book of record that ingests, calculates, extends, and distributes your investment data throughout your entire organisation and your investors, clients, and third parties.”
Aprexo, now owned by Carne, took a related approach.
These solutions offer many of the benefits outlined in the IBOR Global Standard but haven’t solved the problem of integration to business/workflow systems, or at least haven’t to our knowledge at the time of writing.
4. Front-to-Middle-Office Platform with live extract IBOR
Such a solution is designed to be a live extract IBOR at the core, fulfilling most or all of the Global Standard requirements. Business level functionality has been built leveraging the IBOR module in real-time.
An example of a vendor in this category is Limina, which covers order management, portfolio management, compliance, risk, and shadow accounting functionality.
Note: The scope of a Front-to-Middle-Office solution is sometimes also categorised as an Investment Management System (IMS). An IMS could have an IBOR at the core (and hence fall under category 4 here) or a rolling balance (and hence fall under category 2).
5. Front-to-back platforms built on live extract IBOR technology
No platform combining front-to-back capabilities with live extract IBOR exists to our knowledge, nor does any seem likely to emerge in the near future.
Why platforms are more common than live extract Investment Books of Record
Live extract IBORs are yet to see mass adoption by asset managers globally. The current drift is away from best-of-breed towards monolithic applications (e.g. Aladdin IBOR and Simcorp IBOR), which at least reduces the number of overlapping position and transaction databases to be maintained and reconciled.
The main reasons that live extract Investment Books of Record are not more common are:
1. Lack of best-of-breed applications that can leverage an external Investment Book of Record
This is a catch-22.
There is no “standard” or well-established live extract IBOR out there, so no provider of a best-of-breed application will want to invest to make their application dependent on a hypothetical future state of the industry that they’re not in control of.
At the same time, since no best-of-breed applications exist that work well with a standalone live extract IBOR, there is little incentive for managers to implement such a standalone IBOR.
2. Lack of front-to-middle-office/front-to-back-office platforms that have a live extract Investment Book of Record
For a front-to-middle office platform to be a suitable solution, it must cover all the functional areas, workflows, and asset classes of existing solutions. This is a large scope that legacy providers have spent decades building out. Any new entrant must not only build a live extract IBOR but also all the expected scope within front office and middle office.
Until in the last few years, with the emergence of solutions like Limina, no such system has existed.
Reduce costs and operational risk, focusing on investment returns
As outlined at the beginning of this article; front-to-back systems and live-extract Investment Books of Record both solve (different) data management problems:
- Front-to-back-Office Platforms have fewer integrations.
- IBOR has better quality data at the core.
At Limina, we believe the future will be an offering that has a live-extract IBOR at the core and front-to-middle / front-to-back-office platform functionality built on top as a tightly-integrated business layer. We are a platform solution and built to deliver to the full set of Investment Book of Record capabilities, outlined in the IBOR Global Standard.
With such a solution, costs will be kept at a minimum and operational risk will be reduced. Different users will benefit from position views that are appropriate to them, and constructed to support their specific business functions. The whole platform has multiple functions without complex integrations required. Hence, your team will be able to focus more closely on investment returns.
If you’d like to learn more about how Limina please don't hestitate to reach out:
.svg)
