As an investment manager, you're probably familiar with the debate between best-of-breed systems and all-in-one solutions. Both approaches have their advantages and disadvantages, and it can be challenging to determine which one to choose.
In this article, we will explore the history of best-of-breed systems in investment management and the advantages and drawbacks that they offer. We will also discuss how integrated solutions came to be. Finally, we’ll offer some thoughts on what we think the future might hold and why.
For full disclosure: we started Limina in 2014 to solve the challenges with best-of-breed systems. Hence, Limina’s Investment Management System is a holistic front-to-middle office solution. But this post isn’t a pitch for our solution. Instead, as former investment managers, we want to share honest and transparent information which we've found hard to come by. Hence, we created this article, part of a series about IBOR in Asset Management.
Best-of-breed refers to selecting and implementing specialised, discrete software solutions for each business area of investment management. For example, an asset manager would use three different systems for portfolio, order, and risk management.
As the name suggests, ‘best-of-breed’ implies that individual business areas can choose the systems that are considered the best for their specific function. This approach contrasts front-to-back systems, also known as ‘integrated’ solutions or platforms, which attempt to provide a single, all-encompassing platform for investment workflows. While best-of-breed solutions can offer superior functionality and customisation, they can result in fragmented workflows and integration challenges.
Best-of-breed is not to be confused with the best investment management system.
In buy-side best-of-breed architecture, different internal functions choose the most suitable platform for them. The primary advantage of the best-of-breed approach is that every user group gets to choose the system which, in their view, offers the most appropriate functionality for their needs.
There was a significant challenge in data design for the creators of these best-of-breed platforms. The vendors could not rely on the uniformity, completeness, or integrity of the data environments where their platforms would be deployed. The data context of each deployment would be unique.
As a result, each best-of-breed platform was required to build its own self-contained functionalities for handling and storing market data, transaction data, position data, and similar information. Consequently, asset managers frequently found themselves managing multiple redundant data repositories simultaneously. Dealing with the resulting inconsistencies and inefficiencies resulted in a costly and disorganised technical framework.
The multiple platforms and data stores in a best-of-breed stack are interconnected through an integration architecture. To enable this platform interaction and to consolidate data from the different sources, integration systems such as Markit EDM emerged, as well as data warehouses like Eagle and Netik and reconciliation tools like SmartStream and AutoRek.
The inclusion of these data platforms in an Asset Manager’s technology stack brought about their own set of issues. Integration emerged as a critical and intricate aspect of the asset manager's technological infrastructure, becoming a significant dependency in every project involving system modifications. Data warehouses, positioned at the tail end of the data flow, proved inadequate as real-time data sources for business operations and were primarily designed for reporting rather than operational support.
With the rising number of platforms and the expanding network of data dependencies within the integration layer, identifying the root causes of issues and failures became increasingly challenging. The complexity of the resulting architecture placed a significant burden on IT operations teams, whilst commercial management colleagues had to navigate the task of overseeing a multitude of vendors, adding to their workload.
There are direct functional drawbacks to using multiple systems. For example, if cash management is not part of the portfolio rebalancing software, it becomes challenging to project cash movements during a rebalancing session. The portfolio manager may want to see simulated cash impacts, such as scaling coupon payments, fees, or dividends, resulting from an order. If future corporate actions are not integrated into the order management system, would the portfolio manager be obliged to switch between systems? Furthermore, does the cash management system even possess simulation capabilities? Additionally, what about the requirement for conducting formal pre-trade compliance checks on the entire portfolio?
The counter-reaction was the creation of integrated systems. By consolidating front, middle, and sometimes back-office functions in a suite of solutions, these platforms create a single source of truth for data, reducing the need for manual processes and data reconciliation.
These F2B platforms are not generation 3 live extract IBOR Platforms. They provide powerful business functionality, but their rolling balance position management limits the use cases they can support. They can’t reap the full benefits of an IBOR that meets the 2014 Global Standard. Hence, most of their capabilities are restricted, even if they have broad and deep functionality.
The illustration above highlights the best-of-breed system landscape to the left where for example Front Office would use an EMS, OMS and PMS as separate applications. Then there is a grey scale going to the right, with fewer and fewer systems as we approach the front-to-back setup.
A generation 3 live extract IBOR can create any view of positions required by a user or a requesting process. For example, it can include those coupons, fees and dividends resulting from the hypothetical trades that a Portfolio Manager is contemplating. At the same time, and from the same underlying transaction data, the IBOR can produce a view of the NAV as of 4 days ago, including late adjustments.
To enable this, an IBOR must be connected to all data sources and all data consumers. For a standalone IBOR, this involves many integrations. Some consuming systems won’t be capable of consuming position data in real-time from another system (the IBOR). Systems built on a daily upload cycle will suffer from this limitation.
Hence, at Limina, we believe that the future is a world with one core system, including at least IBOR, OMS, PMS and compliance, with a 3rd generation IBOR at the core and at least some functional applications in the front and back office around it. We believe this because
Over time, Limina will add more capabilities beyond OMS and compliance. Ultimately, the platform may become a front-to-back system based on a live extract IBOR instead of today’s wide-scope platforms that generally operate on a 2nd generation rolling balance IBOR.
At Limina, we’ve built a front-to-middle office solution around a 3rd generation live extract IBOR. The functional capabilities cover order management, compliance, risk and more. We call it Investment Management Software.