Ultimate guide to Investment Book of Record, IBOR

The term ‘IBOR’, for Investment Book of Record, was popularised a decade ago. In 2014, a consortium of Asset Managers published the Global IBOR Standard (referred to as the “IBOR Standard" in this article). At the time, no available systems could fulfil the entire Standard.

The Standard remains just as relevant today, and a few vendors have emerged that cover most of the requirements in the IBOR Standard, of which Limina is one (see a demo of Limina's IBOR). Such systems have been in production for a while now, and more and more Asset Managers are adopting them. But what benefits do such IBORs provide? Are there downsides? How do the various Investment Books of Records differ?

To answer these questions, we’ve created a series of 10 articles. It’s a comprehensive and hands-on guide to Investment Books of Record. The article series is co-authored by Kristoffer Fürst, CEO of Limina, which delivers IBOR solutions, and Doctor Ian Hunt, an independent consultant and IBOR expert. Ian was also the author of the 2014 IBOR Standard on behalf of the Global IBOR Standard group.

The Definition of an Investment Book of Record

IBOR Generation 1: Flush & Fill

IBOR Generation 2: Rolling Balance

IBOR Generation 3: Live Extract

Why Investment Books of Record Were Difficult to Build in 2014

How Does an IBOR Fit into the System Landscape You Have?

Some Investment Books of Record to Consider

This page summarises all the 10 articles about IBOR for asset managers, as an ultimate guide of sorts. We aim to give you the essential knowledge of Investment Books of Record and vendors' claims about them. You can find them all at the bottom of this guide if you wish to dive into any of the ten topics.

The Definition of an Investment Book of Record

In 2014, as the IBOR Standard was published, vendors got busy analysing what it would take to build a system that would adhere to it. At the time, the technology was immature, making it difficult to create software to meet the full requirements and design objectives of the Standard.

Instead, the industry experienced a widespread attempt by vendors to rebrand what they already had as IBOR Software conforming to the Standard. You can read more about the history of IBORs in our article about the Best Investment Books of Record.

The result is that an IBOR solution can mean one of three things today:

A live view of portfolios, positions and cash for the Front Office, built from an accounting start-of-day snapshot, often enriched with intra-day orders and/or trades;
A rolling balance of live positions, based on a NAV time series, with intraday orders and other portfolio movements added, to create a live view for the Front Office;
A stock and cash transaction engine can deliver any view of positions and cash for any use case, including front office, securities finance, reconciliation, accounting, etc. This was the intended definition in the 2014 IBOR Standard.

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.

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.

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. A true live-extract IBOR 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.

Another way to think about the live-extract IBOR, compared to the other approaches, is that it’s not batch-based but rather event-based. An event, be it an order, a cash payment or whatever, can come into the event-based IBOR at any point during the day. The event becomes another transaction available for the live-extract IBOR to use when building timely positions. If it’s an uncertain transaction, the state mechanism will treat it accordingly. There is no requirement for an overnight process to run for the transaction to make it into the position or cash balances.

Value Delivered by a Generation 3, Live Extract Investment Book of Record

Now that you know what a Generation 3, live-extract Investment Book of Record is, the next natural question becomes: what business problems are solved by an investment book of record? In other words: what value does it provide you as an asset manager?

1. Increase performance through operational alpha

Cash reserves affect your performance negatively; this is often called ‘cash drag’. If the average expected return of your portfolio is 10% per annum, then every 0.5% of uninvested cash leads to 0.05% forfeited annual performance. 5 basis points might not seem like a lot, but every basis point return counts in the competition for assets. Use our operational alpha calculator to see the impact on your AuM and management fees from deploying more cash.

An IBOR can help to reduce cash drag, by ensuring you can monitor cash in real-time intra-day. The cash ladder views T, T+1, T+2, etc., and can be seen based on any state, including open or executed orders. Since you know that all data is represented, you can confidently deploy more cash and deliver higher returns.

2. Enhance transaction lifecycle management

All transactions go through state changes in a similar way, from an elective corporate action that is first uncertain and eventually settles in cash, to a fee paid to a custodian. Consequently, our expectation of any transaction’s impact on our positions changes with time. Unfortunately, many portfolio management systems only model transactions at a fixed stage in their lifecycle, e.g. a coupon once it’s gone ex, or a deposit once it’s arrived at the custodian.

A generation 3, live-extract IBOR will capture all transactions from their first state to their last and will remember each time a state transition happened for each transaction. Furthermore, it will map all transaction states into 4-6 standardised states that hold for all transaction types so that any position and cash view you request is coherent and easily comprehended.

3. Better portfolio view, including cash

It’s important to understand history to make informed investment decisions today. This applies not only to performance attribution but also to how portfolios looked in the past vs. what we believed when we made trading decisions. In other words, we need to know if the portfolio turned out the way we intended. Investment processes can be enhanced over time based on the knowledge of outcome vs. intention.

An IBOR supports this use case by what is called “bi-temporality”, which is the support of two different lenses: A) the “as is” time series, including late adjustments for example and B) the “as was” time series, which is the portfolio as we believed it would look at each point in time, based on historic data.

4. Increase operational efficiency

Operational efficiency is in large part driven by being able to perform as many operational workflows as possible in as few systems as possible. When we say “system” here, we also refer to email and spreadsheets (i.e. “workarounds”). The more functional areas a system covers, the smoother investment operations generally become.

IBOR doesn’t solve this. In fact, a standalone Investment Book of Record Technology would worsen the problem by adding yet another system. The key to solving the issue is for the IBOR to be the core foundation of a broader system, such as the case with Limina’s Investment Management Software.

Why Investment Books of Records were Difficult to Build in 2014

Don’t get us wrong here, IBORs are still not easy to build. Back in 2014, it was close to impossible, but now technological advances have made it a lot more feasible.

The main technical challenges in building a live-extract IBOR are:

An IBOR requires a lot of storage space. Not only does it need to store every transaction, but also every version of those transactions as the transaction moves across states. At the very least, the database must track what parameters changed in every state transition, and when.
Fetching the right transactions in their right state is a search effort. When a request is made to the IBOR for a position view, it must first identify what transactions are relevant for that request, which can be a large number. The complication doesn’t stop there: the IBOR needs to keep state in mind and to find the right transactions in the state requested.
An IBOR is computationally demanding. A live-extract IBOR is a service, not just a data store. Since there is a close to an infinite combination of date/times and states for a position snapshot, an IBOR doesn’t store position views or time series. Instead, such positions views are created upon request. Users don’t want to wait for the position views to load, so the positions must be created very quickly. This is an extreme requirement, moving what used to be an overnight process into a calculation that happens in real time. To solve this, not only is computational power needed, but also a very clever, energy-efficient algorithm for position creation – which is key intellectual property of each live-extract IBOR vendor.

Since 2014, developments in technology have made these challenges easier to face and easier to resolve.

Database storage space was getting cheaper in 2014 but has reduced dramatically in price since. The emergence of the Cloud has made it possible to claim space as needed. Finding the right transactions and states from a large dataset cannot be solved without efficient indexation of the database; large-scale indexation is now an accepted part of data design (ref. Google) and ‘big data’ search tools are now readily available. Service architectures are now commonplace, and it is no longer unusual to treat data as a service, rather than as a data store. Compute power has become cheaper and much more performant, and, again, the Cloud makes it possible to claim additional compute as required.

It is now possible and practical to deliver an IBOR to the 2014 IBOR Standard, and compliant live-extract solutions are starting to emerge. To help you compare available IBOR solutions, we've create s simple RFI template that you can use for free:

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.

How Does an IBOR Solution Fit into the System Landscape You Have?

How does an IBOR fit into the overall system landscape you have? There are two ways to look at this: first, by comparing the different books of record and second, by comparing best-of-breed investment management systems with front-to-back systems. Let’s look at both.

ABOR vs IBOR and other BORs

The Accounting Book of Record (ABOR) was the first BOR. It was born as a type of accounting system tailored to investment portfolios. Since it served accounting, it had to be complete, and other systems could comfortably rely on it as a source of truth. Earlier in this guide, we explored the usefulness of this attribute of accounting systems to Investment Books of Record populated on a flush & fill basis.

The main difference between the ABOR and IBOR is that the latter only needs to be “eventually complete”. In contrast, the IBOR needs to have all information about all transactions to the degree it’s known at the current moment. In other words, an IBOR can replace the ABOR (but not the other way around), as one view that IBOR can deliver is an accounting view.

If you have a separate accounting system, then the IBOR software can provide an independent dataset for reconciliation against the ABOR, rather than replacing it.

Two other common BORs are the Performance Book of Record (PBOR) and the Custody Book of Record (CBOR). The PBOR and CBOR could be replaced with views from a live-extract IBOR; however, the CBOR is generally an external view maintained by the custodian. In this context, the IBOR settled view can be reconciled against the CBOR.

Acronym	CBOR	ABOR	IBOR	PBOR
Book of Record (BOR)	Custody	Accounting	Investment Lifecycle & Reporting	Performance
Built to Solve	Safekeeping or Custody Reconciliations	Financial Reporting & Valuation	Daily Trading & Investment Decision Making	Periodic Performance Reporting
Hierarchy	Legal Entity	Legal Entity	Legal Entity & Portfolio	Portfolio
Transaction State	Settle Date	Posted Date	Posted Date & Trade Date	Trade Date
Data	Assets Cash	Market Values Transactions GL	Orders Executions Valued Positions Analytics Cash	Open Positions Exposure Returns
Data Quality	Reconciled to Accounting	Complete As Posted, Reconciled to Custody	Intra-Day, Previous days reconciled to Accounting	Reconciled to Accounting
Reporting Period	Periodic / Closed	Periodic / Closed	Intra-Day / Live	Periodic / Open

IBOR vs Front-to-Back Office Platforms

Front-to-back (F2B) office systems 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? That question takes us to the final section of this guide.

Some Investment Books of Record to Consider

At Limina, we take a transparent approach to communication with our clients and prospects. As such, we’ve put a granular analysis of Limina’s IBOR capabilities online for you to look at any time. Dr Ian Hunt has independently validated this analysis, and there is no affiliation between Limina and Ian.

You will find more articles on our website explaining when Limina would be a great fit to your business, and also when Limina might not be the best solution for you. We make it clear who Limina is for, so you can make your own mind up about the fit. We also show pricing examples. We have more tools to help you to select the right solution for your needs. Please reach out, and we’re more than happy to help, even if we are not the best fit for your firm.