INVESTMENT BOOK OF RECORDS: establishing a single source of “truth” for buy-side firms

  • 1049

    INVESTMENT BOOK OF RECORDS: establishing a single source of “truth” for buy-side firms

    Firms are discovering that there is a strong business need for accurate real-time positional data across their organizations. Access to such data would maximize investment opportunities, ensuring that a firm can be fully invested. For some, an Investment Book of Records (IBOR) addresses that need. Gaining considerable attention in the investment management industry, particularly within more retail-focused firms, an IBOR provides real-time portfolio visibility through the synchronization of frontand back-office systems and can be implemented in a variety of ways. Duncan Cooper discusses the fundamental patterns these options present and considerations for each.

    Traditionally, an investment manager has a front-office system covering a portfolio management system (PMS), an order management system (OMS) and possibly an execution management system (EMS), such as Charles River or the Fidessa Buy Side solution, partnered with a back-office accounting system, such as SimCorp Dimension (SCD). Linking and integrating these systems is typically performed by various extraction, transformation & load (ETL) solutions. Historically, these were custom solutions, but today, the trend is toward off-the-shelf data management solutions, such as Markit EDM.

    Each morning, the back-office system produces the current positions for the start of day. These are then passed through to the front-office PMS/OMS. Throughout the day, trades are executed within the OMS, and at the end of the day, a trade file is extracted from the OMS and sent through to the accounting system for processing.

    Corporate actions, subscriptions, redemptions and general cash movements are manually adjusted and entered into frontoffice systems (typically by portfolio managers themselves) or into back-office systems by an operations team. As a result, the front office and back office would only be “in synch” at the start and end of the day. The rest of the time, they are running their own separate processes and do not have a consolidated “picture in time” of positions, including cash across portfolios.

    Figure 1: A Typical Data Flow through Various Systems.

    IBOR Market Drivers

    Consolidating the front office and back office into a synchronized real-time system requires considerable time, expense and effort, and doing so may not deliver the business benefits that will make it worthwhile for all organizations. Investment managers who have high volumes of subscriptions and redemptions, large equity portfolios or fixed income funds with the associated derivative instrument mix will have heavy cash flow-sensitive instruments. They must bear the operational cost of manually updating and synchronizing, along with the missed opportunity cost of being fully invested or missing a market opportunity because their portfolio managers must spend time performing administrative tasks in order to get an accurate view of where they are in the market. For these firms, the traditional approach requires too much time and effort to update and synchronize. Therefore, an investment in IBOR may be well worth the implementation and design cost.

    As the industry in general moves towards a more 24×7 operation with multiple global sites handling issues such as “passing the book,” a single global position and consolidated regulatory compliance view is more imperative than ever. It is no longer sufficient to operate as separate organizations or silos under one common brand. Firms must now function as a unified organization with a single view of the world, able to react to changes in each market with speed and agility.

    To do this, firms need data—and not just data in various systems and databases separated by regions, assets and processes. Instead, firms need a single source of accurate, timely and clean data that can be used throughout the organization as “the truth.” Those with access to this data and the ability to use it to gain a competitive advantage will be most successful.

    The Options for Establishing an IBOR

    As with any problem, there are a variety of possible solutions. Each has its strengths and weaknesses. The one to choose, however, is the solution that best fits into the existing ecosystem and solves the associated business problems better than any other option.

    Single System from Front to Back
    The key point for an IBOR is to have all information in a single location. Therefore, the obvious solution is to utilize a system that handles front-office PMS/OMS/EMS duties, as well as the back-office settlement, accounting and NAV creation.

    There are two vendors in this space who offer a single solution. SimCorp Dimension is an established market leader, while Murex is gaining traction in the buy-side arena, which is a new area for the company. While SimCorp is strong in back-office functionality, it is quickly building PMS/OMS functionality and is comparable to some of the market-leading OMS providers. Murex is a front-to-back solution that is typically viewed in the derivatives and complex instruments space, but is not presently known for its functionality in the vanilla cash equities and fixed income arena.

    Using a single system ensures that all corporate action changes, cash adjustments and amendments, subscriptions, redemptions and reconciliations happen within a single system or database. This system acts as the golden copy for all operations, trading and portfolio management. For many firms, a complete out-of-the-box “single, stop system” is a compelling solution.

    While a single solution sounds appealing and straightforward, there are challenges to this approach that should be considered. First, by selecting a single system, firms are inherently tied to one vendor, with that vendor’s product roadmap, features list and strategy. As one of many clients, a firm may find that what is important to its business may not be important to the software vendor. Second, the simple technical concerns of scalability and reliability can be mitigated to a certain extent with careful technical planning, but there is always a risk of this with a single system layout. Third, the systems may not have all of the necessary functionality. For example, more exotic or complex workflows in the PMS/OMS space may be a challenge for a particular vendor solution, while equity workflows can stretch the capabilities of another. Fourth, if a firm’s portfolio managers and traders are attached to their current workflows, they may find the capability and functionality of such a system difficult to adopt. Finally, it’s important to consider the diversity of the firm’s locations and operations. A single system in one office may be a sensible approach, but could be a challenge for a global operation with multiple sites, given that the impact and challenges around a 24×7 operation and single database/system are complex— with a very real single point of failure.

    Enterprise Service Bus
    An enterprise service bus (ESB) is a centralized architecture solution for synchronizing many systems within a firm’s ecosystem. All systems (PMS/OMS/EMS, accounting, risk, PMA) connect into a centralized bus which transports, transforms and certifies data delivery from one system to another on an event basis—as opposed to batch delivery systems. This results in all systems having the same information at the same time. When an order is created, the trade moves through the OMS/EMS system. When its lifecycle in the OMS/EMS is completed, the order is automatically extracted to downstream systems.

    As a solution pattern, an ESB is very scalable. Systems involving many millions of messages a day are routinely in operation without issue. An ESB can be distributed and scaled up and out. As the ESB takes care of delivery and reconciliation of the systems, the positions and information in one system will be in synch with all other consuming systems. It reduces manual processing and double key entry, thus minimizing operational risk. In addition, an ESB provides a federated distributed golden copy of securities to all systems, a common pain point for asset managers. Using an ESB allows firms to select best-of-breed systems for PMS/OMS/EMS, accounting, risk and PMA. It also enables rapid implementation and the decommissioning of systems; therefore, a change of OMS is no longer a multi-year project.

    Figure 2: A Logical Enterprise Service Bus Reference Architecture.

    An ESB sounds like a compelling solution, but it too is not without challenges. It is a companywide initiative that takes resources from all areas and requires niche technical skills to implement. Complex implementations can last for many months and there is limited visibility into the actual business value that an ESB delivers; it is often seen as a cost reducer and not something that creates a competitive advantage. Finally, there is no “single system of truth,” unless an investment is made to also introduce a data warehouse or data store at the same time. As the overall timely data picture is now federated among many systems within the business, finding all aspects of what has happened, for example, in a trade lifecycle, still requires many checks to many systems. As a result, an ESB will not help alleviate the reporting requirements of the various regulations coming into play for the investment management industry.

    Where an ESB really excels, however, is its ability to link together multiple dissimilar systems that are globally distributed. If a firm needs to verify what was traded on its portfolio in London and what its traders are trading on in New York, then an ESB might be a good solution. The firm can link to each OMS in each region and ensure that books and records are updated. Instead of re-implementing the global business to a single system, an ESB establishes a data integration layer that ensures synchronicity, allowing each geographic unit to use its preferred solution while at the same time providing a single picture for the whole organization.

    Centralized Data Warehouse
    The most commonly used design pattern to solve data consolidation issues within the investment management industry is the data warehouse. This is a technically simple solution through which, once a data model is derived, only ETL and traditional system integration issues need to be addressed. Much has been written about various data warehouse concepts— from data federation and data marts to de-normalized and star schema—but the concept is a single storage and access location for all trade, market and client data, which then becomes the “truth” in your organization. The database will be designed for online analytical processing (OLAP) as opposed to online transactional processing (OLTP), meaning it can retrieve data quickly, but it is not as quick to store data from a transaction.

    A data warehouse is a solid concept. Nothing has radically changed in the design or delivery of data warehouses since the turn of the century. They are mature, reliable and scalable, with a number of vendors and resources that can design, deliver and support their use. A well-designed and accessible data warehouse can be the bedrock of an organization supporting not just the PMS/OMS/EMS front-office world, but also making available trading trends, cost of trade and a whole gamut of useful operational statistics to analyze various costs within an organization. But databases are slow in data terms. To get information from several systems into the database requires ETL functionality, which is typically used for large volumes of records on a minimal-frequency basis.

    From a business perspective, there are benefits to a data warehouse. It uses mature, low-risk technology to deliver a single location for investment positions. However, when timely updates of the positions into the system are needed, the centralized location does not allow for quick reaction times. Nor does it add any additional business functionality into the processes like a single system would. As such, it is a low cost—but also low value—solution.

    Distributed Data Fabric
    The typical design pattern of a data fabric is an in-memory cache of operational data. Data fabrics are common in the sell side, but are rarely seen within the buy side. They mitigate the issues of OLAP versus OLTP that can affect the data warehouse. Firms can load each transaction into the data fabric quickly without impacting performance or replication. Positions within the system are constantly updated with each trade, cash movement, dividend and corporate action. The data can be used on the fly to perform Portfolio Management Systems (PMS) what-if analysis. It can also be passed to risk calculation engines or used in real-time compliance checking or PMA.

    As a transactional data fabric, the operation can be likened to a data warehouse without the data warehouse’s weaknesses. Data is added on a transactional basis and interfaces from external systems (like FIX) can also update the positions. Ultimately, the view is like a database in a single location, but in near real-time operation on a distributed grid. Data fabrics are gaining a great deal of traction as a sell-side risk solution and are well suited to buy-side IBOR challenges.

    Data fabrics are cutting-edge technology for enabling an IBOR. As such, there is the inherent implementation risk of finding quality resources able to design and deliver an optimized solution that provides the needed operational value. Because data fabric and ESB solutions are seen as purely technical, the key issues with implementing them involve project cost and duration, combined with the perceived value to the business. They require deep knowledge within a technical niche area, so resources are more expensive to find and projects are more complex to plan. While they may be the best “technical” solution, the business requirements need to be explicitly defined so as to justify the expenditure to solve the problem.

    But data fabrics do provide business value. As a single computation grid, the scalable risk calculation engines can leverage the data fabric to create slices for risk, PMA and what-if scenario analysis, making results available in real time to the business. Instantaneous calculations feeding into the PMS could be a major competitive advantage for some investment managers.

    Off-the-shelf Software Products
    As with all technical problems, some firms prefer off-the-shelf software packages that will solve the problem quickly and easily, thus reducing the project and operational risks involved with change. Because this is a new market, some of the leading software vendors have not yet developed solutions to this problem. The notable exceptions (outside of the single system vendors like SimCorp) are Fidessa and GoldenSource. Fidessa is taking an approach akin to a data grid/cache solution, while GoldenSource is approaching this problem from their core product base and utilizing a data warehouse approach.

    Conclusion

    While the concept of an IBOR has existed for some time, the maturing investment management market, coupled with the need to use the latest tools and information to adhere to mandates in this space, has now made IBOR an issue that needs to be addressed. Ultimately, the key factors in choosing a solution involve the market a firm operates in, the impact that a lack of an IBOR is having on the business and the speed in which a firm wishes to gain a competitive advantage in the market. In the end, the most successful firms will be those that strategically align their choice of solution with their business objectives for growth.

    The Author

    Duncan Cooper

    Leave a Comment