Series: IBOR – The Investment Nervous System | Part 2 of 2 

by Senior Consultants Laurence Beine and Ashen Khosa

So you’ve seen the potential. But how do you get there? In Part 2, we dive into how to scope and implement an IBOR that actually works, covering the data, capabilities, and strategic alignment needed to bring it to life. 

Whether you’re assessing SaaS platforms, rethinking data flows, or designing your future operating model, this guide outlines what needs to be in place for IBOR to become your operational backbone. 

The Perimeter of IBOR 

The perimeter or scope of an investment manager’s IBOR should be aligned with their investment process and competitive strategy. The investment manager’s competitive strategy will define what data are required to support their investment, compliance, risk and reporting processes, and should be included in their position data sets. 

What transactions should be included? 

The first consideration is about what transactions should be included in the IBOR. Our automatic thinking is that transactions should be added to the IBOR post execution. This understanding though stems from legacy platforms widely using different position data sets for middle and front office.  

As several of the use cases described in part 1 of this paper require IBOR knowing trades before execution, including transactions from the first time they are simulated is required to leverage the position data set for the front office. Any “IBOR” that does not know of transactions before they are executed will require a duplicate Book of Records for the front office and will thus by definition not be an IBOR.  

What Data Should Be Included? 

The second consideration is about the amount of data that should be available as part of the position data set. The minimal data to define a position are portfolio, quantity, asset identifier and transaction status. On top of these core data, we can think of: 

• Price and valuations: so many functions within the company require valuations that it is hard to imagine they would not be part of the position data set. Considerations when selecting or implementing an IBOR would be whether different price hierarchies are required? Do they need to be static or dynamic? Is there a requirement to use specific settlement date to value holdings? Will the IBOR calculate or ingest accrued interests? Calculating accrued interests requires good static data and holiday calendars. Do prices follow a validation process with various statuses? Real time prices? 

• Investment strategies: if the investment process relies on grouping positions per strategy to keep track of investment decisions or measure the contribution of individual investment decisions to portfolio performance, the strategy is an additional position data. 

• Tax lots: if the investment process requires tax lot data, the IBOR needs to integrate with custodians to provide tax lot details (number of shares, cost basis and purchase date) as part of positions.  

• Weight: depends on the portfolio definition and requires knowledge of portfolio hierarchies if portfolios are divided in sleeves. 

• Cash forecasts: forecasting cash balances with absolute accuracy requires ability to calculate/estimate all sorts of cash movements, including corporate actions, fees and commissions, taxes… The scope and precision of cash flow forecasts performed by the IBOR will determine the level of precision of the cash forecasts. 

• Corporate actions: should the operations team at the investment manager duplicate the calculations of the custodian or ingest forecasts and confirmed corporate actions? If they duplicate the calculations, should they apply tax calculations? What will the process be to support voluntary corporate actions that require decision by the front office? 

• Fees and commissions: the investment manager is the source of transaction fees and commissions while accounting and custodian are the reference for portfolio level fees and commissions. To what extent does the investment manager want to duplicate and control calculation of fees and commissions? 

• Blocked positions: knowledge of what assets or cash have been collateralized or repoed is required in several processes. How does the IBOR become aware of blocked positions? Who should this be reconciled with? 

• Classifications: defined at various levels securities, issuers, portfolios, investment strategies, users… Classifications can be used to be displayed as such or as input parameters for various processes. 

• Analytics: does the IBOR calculate security analytics? Aggregate them? Can the IBOR support specific exposure calculations? 

• Benchmark and liabilities: in investment processes that focus on replicating or outperforming a benchmark or paying off a series of future dated liabilities, the position of interest is the position relative to benchmark or liabilities. Should the IBOR calculate relative positions to benchmark or liabilities? Exposure measures relative to benchmark or liabilities? 

• Book cost and unrealized P&L: Since an IBOR aggregates transactions to build positions and then supply position data, it might be the only place where book cost can be sourced if required as part of the investment process. 

• Share classes: is there a requirement for share classes to be represented in the IBOR? 

The scope of the IBOR should be defined to support the strategy of the specific investment manager. As a rule of thumb, IBOR is a prime candidate to produce any data that is derived from original transactions (eg. Book cost) and data that are required by several processes/systems and would have to be enriched in several other places if not in the position data sets provided by the IBOR (eg. Classifications). 

Implementing an IBOR-Centric Architecture 

Implementing an IBOR-centric architecture will increase the business’ agility but also requires a clear strategic vision. How does the investment manager differentiate from its competitors? How does technology support the company’s competitive advantage? As alignment with the organization’s market position and strategy is key to create value, there is no one size fits all technology architecture. In the absence of a clear strategic vision and capability to align technology, the benefits of an IBOR-centric architecture are unlikely to materialize and the Saas outsourcing model will likely be less risky. 

It also requires that the company retains skills in technology. Lots of players have long seen technology as a cost rather than an asset and been happy to offload as the trend toward Saas developed. Rebuilding internal technology skills will require commitment from players who have downsized their technology teams.  

Coming to a decision about the best solution also requires balancing considerations about plans for future growth, in house skills and culture, timing, budget… Liqueo has loads of experience with a significant number of solution providers in the market and a thorough understanding, not only of their current product capabilities and limitations, but also their client culture as experienced in various projects. Our advisory team is equipped to help your organization make a decision with clarity on the pros and cons of the various options available to your organization. Such clarity will also help leaders to motivate and embark the whole organization in the implementation and through the change management process. Here again, our consultants can help your organization manage and deliver the project in a controlled and timely way. 

Realising the Full Potential of IBOR 

We have defined an IBOR-centric architecture; one where the IBOR truly is the single source of position data supporting the whole investment management process. For this to be true, it will need to capture trades from the earliest simulation stage, when they are still only just a figment of the portfolio manager’s imagination. 

An IBOR-centric architecture will make an asset manager more agile by constantly providing accurate, complete and timely positions and transactions, customised to satisfy the needs of each function contributing to the investment process. It will also facilitate change by plugging new tools, integrating seamlessly with in-house and market applications as well as external entities. 

For the IBOR to be the only source of position data, it will need to provide data that are rich, customised and granular enough to satisfy the requirements of all position data consumers. The company’s business and investment strategies will drive the scope of data to be included in the various position data sets. 

While the benefits of an IBOR-centric architecture are clear, it cannot deliver value without a clear company business strategy, leadership to align the technology with the business, and capabilities to deliver on the vision.  

Need clarity on whether your IBOR is really delivering? 

At Liqueo, we’ve helped leading asset managers review and rebuild their data architecture around a real IBOR model, improving agility, reducing duplication, and supporting competitive strategies. 

If you’re rethinking how position data flows through your business, our team can help you cut through complexity and identify the right model for your needs. 

Read part one here.