Increase operational efficiency
Ultimate guide to Investment Book of Record (IBOR)
Definition, generations, value delivered, other BORs and systems to consider
You can think of the 3rd-generation of IBOR as a position view that looks different depending on what perspective you’re looking at it from.
Unfortunately, knowing which generation is meant by a simple “IBOR technology” claim is impossible. It’s our job to educate you so you can tell them apart. Let’s explore the three generations next
- Generation 3
- Generation 2
- Generation 1
IBOR Generation 3: Live Extract
The final destination in our journey through the generations of IBOR technology is the “live extract” IBOR. This 3rd generation technology builds up portfolio views on request, including real-time views, based on a complete time series of transactions in multiple states.
The below graphic illustrates three examples of consumers of position data:
The main difference between a rolling balance and a live-extract IBOR is that the latter can support an infinite number of views in both time and state. A live-extract IBOR doesn’t even store inventory at all. It doesn’t keep positions or cash balances. Instead, the underlying transactions and cash movements are held, including all amendments made.
Therefore, the live-extract Investment Book of Record lets you create a portfolio view (or portfolio book of record) based on any transaction data, at any time and in any state.
IBOR Generation 2: Rolling Balance
A rolling balance is essentially the same as the flush & fill approach, but the snapshots are internal to the system. The rolling balance builds today’s position view from yesterday’s view plus changes since.
The rolling balance model is better than flush & fill because it overcomes the dependency on an external system, reducing operational risk. The best rolling balance solutions seek to achieve completeness over transactions, including cash and accruals.
However, one fundamental issue remains: the rolling balance can only support one time-series, and therefore one perspective on positions. So, the question is, which time-series should that be? Should it be for settled trades or include open orders? It can’t be both in a single balance. Often, systems delivering a rolling balance will model the time-series based on an accounting view, which means transactions before posting aren’t represented.
IBOR Generation 1: Flush & Fill
A Generation 1 IBOR builds an intraday view of positions and cash from a start-of-day snapshot, taken from another system or service provider: typically, this may be an accountant or custodian. The approach is called flush (positions and cash are deleted during the night) and fill (positions and cash balances are loaded from an accounting view in the morning). The start of day snapshot may be enriched with intra-day orders / executions.
The illustration shows what the process looks like.
The advantage of this approach is that it’s low in maintenance since the middle office doesn’t need to process corporate actions, deposits/redemptions, audit fees, etc. The downside is that the position data isn’t complete, and it’s often unclear for portfolio managers what is potentially missing, especially in the cash positions. This uncertainty and incompleteness are real concerns, leading to cash reserves which diminish returns due to cash drag.
Other issues with the flush & fill approach include:
- No or limited ability to project cash and exposures into the future (T+1, T+1, etc), which again leads to cash drag on performance.
- Since the flush & fill approach is based on an external position source, it can’t serve as a duality-check of that source (e.g. accounting system or fund administrator). The lack of duality checks increases operational risk as errors won’t be caught.
- Since the position records are incomplete, they are of no value for any other purpose, including reconciliation, and are junked at the end of each day.
The flush & fill model is the most common for Front Office systems. If you want to dig deeper into these systems, we have articles that cover more about what Order Management Systems are and more explanations of acronyms used on the buy-side.
When you make a request to the IBOR system, it creates a portfolio view (or time-series) on the fly. Your request will include a transaction state, and the IBOR will fetch all transactions relevant to your request, and create a real-time aggregated position as at the time selected. Here is an example of how it works:
How data quality controls complements an IBOR System
Data quality is achieved by delivering data that is complete, accurate and timely. For an IBOR, “data” refers to transactions, i.e. anything that affects positions or cash. It could be a deposit, a coupon payment, an execution in the market, a bond RFQ, etc.
An Investment Book of Record is data-hungry since it requires all transactions, of whatever kind or source, in order to achieve completeness. This sounds very demanding, but is actually exactly the same requirement that is key to an investment accounting system. Without complete data, the accounts would be wrong, which isn’t acceptable.
In an accounting system, T-1 data, or even T-2 data is often sufficient: so long as each transaction is posted at some point, then the accounts are complete. This isn’t the case for an IBOR, which requires transaction updates in, or close to, real-time.
To control data coming into the IBOR, it makes sense to have a layer that controls that data automatically and flags suspicious data points, e.g. if a fill is far off the last price, or if a deposit is much larger than usual. We refer to this functionality as exception-based workflows or data quality controls.
Exception-based workflows aren’t a necessary part of an Investment Book of Record, but they are a beneficial addition to empower investment operations with automated issue identification. At Limina, we bundle this functionality with our Investment Data Management Solution.
IBOR vs Front-to-Back Office Platforms
Front-to-back (F2B) office platforms are a different type of proposition than an IBOR, but the two have similar objectives: to simplify data management. They do this in different ways:
- IBOR: a position engine that enables any view on positions, empowering any system or person that consumes the data with more accurate portfolios.
- F2B systems: a holistic platform that negates the need for system integrations, ensuring that data isn’t lost in translation and doesn’t require you to intervene manually.
An F2B system needs one type of IBOR as its core, either Generation 1, 2, or 3. Most systems available today that are Front-to-Back or close to it, are generation 2 IBORs: they ruin one or more rolling balances to deliver position data.
The main opposition to a front-to-back system is a best-of-breed setup, where multiple specialised systems are chosen across the front, middle, and back offices. Various hybrid options are also available, so in practice, it’s a greyscale. We illustrate some examples here:
The ultimate solution would be an F2B system built on a Generation 3, live-extract IBOR, wouldn’t it?