What your IBOR salesman won’t tell you...

He won't tell you that "IBOR" (Investment Book of Record) is just a buzzword coined to help his offering through its midlife crisis — a fresh coat of paint for the old Studebaker on his lot. Also, that he has no firsthand experience with IBOR, or with the investment process in general (but hey, he has a winning personality). 

IBOR is a hot topic for the vendor-consultant industrial complex. Not to be left behind, the ‘industry experts’ have also lapped it up. I couldn’t tolerate the cacophony of bloviating pundits any longer, so I decided to improve the signal to noise ratio on the subject.

In this two-part blog series, I will debunk the hype around IBOR. In this first part, I will introduce a framework that helps customers understand their level of requirements and benchmark vendor offerings against those needs. I will do this by breaking IBOR down into its components: data, abilities, and asset-class considerations and stratify requirement levels within each component (high/medium/low). 

Practitioners (the buy side) are encouraged to use and extend this framework. Consultants however, are forbidden from plagiarizing or bastardizing it.  

What is IBOR and why do we need it

IBOR – Investment Book of Records can be roughly described as ‘real-time positions for the front office’ (FO). Accurate, timely positions are essential for the front-office to perform its functions. All good investment managers have been using IBOR concepts since the dawn of time.

This topic is gaining importance as investment managers are increasingly outsourcing their middle and back offices. As more back office functions are handled outside of a fund's walls, investment managers are finding that the outsourced providers don't offer the same functionality, accuracy, and timeliness that their internal back offices once did. With IBOR, they look to regain some of the functionality they used to enjoy with their in-house solutions of yore.

The Framework

In simplistic terms, FO needs positions, returns, and risk measures for analysis and portfolio management. The IBOR can be described along 3 dimensions -- namely datasets, functionality and asset specific needs. 

Not all front offices require the same degree of complexity from their IBOR. For that reason, I have segmented the datasets & functionality category into minimal, intermediate, and advanced usage patterns.  Factors that influence how complex an IBOR a FO requires include:

  • Strategy: are they a basic mutual fund or benchmark tracking portfolio, or are they a quantitative, global macro investor?
  • Trading Frequency: do they simply rebalance monthly, or do they trade with high frequency from multiple global trading desks?
  • Investment Types: do they trade just basic equities, or more complex instruments like OTC interest rate swaps, collateralized loan obligations, or asset backed securities?


The typical datasets needed for a functional IBOR are:





Accurate view of held and in-flight trades.

Note: Often the front-office positions are more granular than back-office.

Historical positions

Hypothetical trades, scenario analysis.



Greeks, key rate durations.

● Advanced risk metrics: VaR, position covariance (both historical and forward-looking).

● Scenario analysis: curve shocking, event simulation.


Attribute daily, MTD, QTD, YTD, inception to date risk, returns to

● Book/ sub-book, strategy

● Static security terms (Industry, geography, ratings etc.).

● FX, dividends, interest accrual and price breakdown

● Attribute at sub-taxlot level

● Attribute based on dynamic properties of security (like OAS Duration buckets, correlations to other assets, conceptual markets)

Attribute to ‘factors’ (for example using MSCI Barra models).


Cash ladder for each currency that accounts for

● Settlement proceeds for open trades.

● Dividends, accrued interest.

● Financially settling futures, options.

● Swap fixed and floating leg cashflows.

● Initial and variation margins on OTC trades.

● Handle REPO roll, inception, maturity

Cash buffers; projected cashflows based on probabalistic factors.


The features that use the datasets:





● Allow for easy slice and dice of data. Linked charts and tables (like a standard BI tool)

● All data is available to programs, Excel.

● Dynamic calculated KPIs (like Sharpe Ratio, betas to markets) for selected slice(s) of data.

● Views that can be used for investor reporting.

Discover hidden patterns in data (correlations, regressions)

Front-office Interface

Effortlessly consume

● In-flight, historic trades

● State change on orders, corrections on trades.

● Market Data, Security master


● Internal reference data

● Internal valuations

Handle global trading. For example, loading tomorrow’s Asian market targets while US is still trading the current day.

Keeping positions consistent across day-roll, corporate actions while ADRs are actively trading requires pretty intelligent systems.

Back-office interface

Reconcile position, trades, cash with:

● Outsourced back office

● Internal Accounting system

● Act as data hub for back-office (export allocations, cancel/corrects)

● Data enrichments for back-office (commissions, fees, margins etc.)

● Intelligent reconciliation, auto correction of data issues

● Data quality metrics


We have categorized assets based on the typical complexity in position management and valuation.





Equities, ETF, Indexes

Futures, Options


FX Spot/Fwd/SWAP, Govt/Corp Bonds

Repos, Syndicated Loans, IL bonds, Emerging Mkt Debt (sinking, capitalizing)

Converts, ABS/MBS

OTC Swaps/Structured

Total Return Swap, CFD


Interest Rate Swaps, Variance/Correl Swaps, CDOs, CLOs

In the next post we’ll examine the following options using the above framework:

  • In-house IBOR
  • Vendor IBOR based on an Accounting System
  • Vendor IBOR based on an OMS