Over the past couple of years, the Investment Book of Record (IBOR) has been a topic increasingly seen in articles, interviews and conferences. The fact that it is still widely discussed, suggests that, although far from a new concept, its precise nature is not clearly defined.

Today the debate is perhaps more about how an IBOR will be delivered and how it will operate rather than what it will offer. Different business types will have different needs and this will govern exactly what practical implementation is needed, along with their size and operational model. However while the flavor of solution to be implemented may be debatable, the key elements of any solution are clear.

The benefit of an IBOR is in providing complete, accurate and timely investment and cash positions as and when required by consuming systems, whether these are front office trading, treasury, analysis, reconciliation, reporting and so on. While risk monitoring would be a beneficiary of such data an IBOR’s true benefit is about reducing the risk across a firm’s organization – the risk of getting something wrong.

One of the main drivers for an IBOR is that position data is not necessarily hosted all in one place within a firm. Data may be split by function or be held across multiple systems of the same type. The fund accounting system will hold position data but may not know about commitments such as stock loans or collateral positions, which may be handled by their own discrete systems; and a firm may have more than one fund accounting system through merger or acquisition. An IBOR must therefore be capable of handling data from a variety of different sources, in different formats and with each incumbent system’s differing capabilities to provide the data.

Even where the data is largely complete within a few systems, for example and typically, the fund accounting system, it may well not be available at the right time – that is it may be available at the right time for fund accounting but not necessarily for other uses of position data. In this case an IBOR would need to take data from systems other than fund accounting, earlier in the business day.

Collecting and aggregating position data will not give IBOR benefits without a way of ensuring its accuracy or reacting appropriately to inaccuracies when identified. As the prime investment record IBOR data can be reconciled to other data sets, for example custody and fund accounting and inconsistencies identified and corrected. A comparison of projections against reality, for example a projected settlement versus the actual settlement, could also be used. As well as identification and timely correction there is also a need to advise that previously provided data was incorrect and to provide a replacement. For example a valuation and transaction history provided for performance measurement may need to be re-stated to take account of a late, backdated trade.

The key ability of an IBOR is to provide whatever view of position data is required at the time that it’s needed. The time and the view of the data required is determined by the receiving system, not the IBOR. For trading, one fund manager may wish to see a position view including unconfirmed trades, while another, only fully settled positions, but both required on a near real-time or even real-time basis, while a reconciliation or reporting system needs perhaps a simple once-a-day feed of positions and transactions as at a point in time

The granularity of the underlying data and the flexibility of view suggest that an IBOR is more than just a data warehouse. If the required view includes a projection, for example available cash at a future point or the impact of corporate actions, then the IBOR must include the necessary business process functions to project these outcomes. This, in turn, implies the ability to access or hold appropriate reference data.

Whatever approach is taken, implementing an IBOR solution is not an end unto itself. The real benefit comes from other systems’ use of the data, which means that any implementation needs to include significant reference to those systems as well. For example, moving from an overnight position refresh of a front office system to an intraday, near real-time or real-time one may require development in the incumbent system to take those refreshes.

Having a clear understanding of what an IBOR function should offer and how it will fit into an organisation’s operations, will make an IBOR a key component in mitigating risk across many organisations.