Defining the Investment Book of Record

Introduction

Investment managers, vendors, consultants, and the press differ on what Investment Book of Record (IBOR) means. This is a problem, because when buy-side firms ask consultants and vendors to help them solve their IBOR needs, those consultants and vendors can end up answering a different question from what is being asked.

Various definitions and themes that are emerging in the discussion via white papers, conferences, and the press are listed below, with the most crucial distinctions and decision criteria discussed. A bibliography listing several sources is available at http://www.barrychester.com/IBOR/reading.html.

Possible IBOR Definitions

A real-time positions database that serves everyone in the enterprise
Position keeping specifically for portfolio managers
A place to aggregate positions from different outsource providers

Themes

The main threads of IBOR discussion can be grouped into four high-level themes:

enterprise drivers,
portfolio management drivers,
control and flexibility drivers, and
technical strategy.

The "enterprise" theme is getting the most air time, followed closely by the "control and flexibility" one. The "portfolio management" theme lags far behind; this may be in part because much portfolio management technology is beyond the purview of most firms' IT departments, and in part because of the perception that it is less obvious how to address portfolio managers' needs. Among sophisticated asset management firms, there is a wide variety in the level of awareness of this theme.

Enterprise drivers: this is often referred to with the media-friendly sound bite "single version of the truth". Many investment firms find themselves with multiple trading systems and/or accounting systems. This obstructs coherent views of positions and trading activity across the enterprise, since the data is likely in a piecemeal state across several databases that probably have different structures, levels of detail, and process around them. Enterprise functions like pre-trade compliance, firmwide position reporting, and enterprise risk management have a legitimate requirement for such views.

Related to this is the desire on the part of these same stakeholders for consistent definitions of financial computations and risk measures, so it is natural to expect these to be built into whatever enterprise transaction and position repository is put in place. Whether those ex post facto definitions are the same measures an investment decision maker wants to use ex ante is another story, but nonetheless these definitions reflect a legitimate need.

Common to these two drivers (that is, pre-trade compliance and real-time enterprise risk management) is the need for all this data to be up-to-the-minute, or at least close to it. While people charged with oversight of the organization will typically look at all this data on an end-of-day or end-of-month basis, they need it to be available as it is happening, since market events, and even real-world events, mean the organization has to react at once, for which it needs to know what its exposures are now, not only at yesterday's end of day or today's start. It doesn't matter if this data is not bulletproof enough for accounting and financial statements. Having to take the time to pull extracts from a number of databases and combine them could easily put the firm at a disadvantage when others have instant access to their data.

All of these enterprise drivers ultimately come from the company's need for a holistic understanding of its positions and exposures as of any point in time.

Portfolio management drivers: portfolio management has needs for position data that extend beyond the needs of the enterprise, and sometimes may even conflict with it. Among these is the need to tailor views of the portfolios and their component holdings to the strategy being implemented. This can include the need to combine portfolios, or divide them into sleeves, for the purposes of modeling and order construction, which implies the need to maintain a "shadow" account structure that may not align cleanly with the accounting system. The records used by portfolio management for these purposes often need to be independent of the accounting system, in order to preserve these degrees of freedom. And portfolio management may need to model assets differently from the "official" view. In fact, such insights into the behavior of assets may be the "secret sauce" of a portfolio management strategy, and it is the rare accounting system that will accommodate these variations. Some asset managers allow and encourage specific investment departments to maintain their own versions of security masters for this very reason.

This implies that an IBOR that delivers these portfolio manager-centered requirements is a critical success factor behind the generation of alpha in an active portfolio, which is indeed what many people claim. Another way in which a well-designed and implemented IBOR is seen to improve investment performance in passive portfolios is by helping portfolio managers avoid tracking error, by giving them the most up-to-date intraday information available. Positions being sourced from an accounting system may struggle to include these.

A more subtle requirement of portfolio managers--and this would extend to some enterprise-level stakeholders as well--is the appropriate reflection of history. In addition to end-of-day snapshots, portfolio managers want to see corrections and backdated transactions applied as they actually happened, rather than as adjusting entries made at the time the problem was discovered.

Control and flexibility drivers: this theme involves two subthemes: keeping the IBOR and the accounting book of record--the ABOR--independent, and establishing control and oversight of an outsource provider.

Portfolio managers don't want to be tied to accounting system update cycles to have activity reflected in their portfolio data. Also, ABOR will generally not have open orders, much less orders that portfolio managers are considering but haven't placed yet (sometimes referred to as "simulated" orders). Many portfolio managers also see the separation of IBOR and ABOR, if implemented properly, as a good quality control on the ABOR.

If an asset manager has outsourced its accounting function to another company--or is considering doing so--it at a minimum needs a shadow book of record on its side to oversee that relationship and have something to reconcile to. This is widely recognized in the industry as a best practice. It further forces an architecture that enables arms-length, controlled separation of duties and therefore enables a smoother transition from one provider to another when the time comes.

Note that an enterprise also gets this benefit if it does its accounting internally and properly segregates its in-house platforms.

Also, in the situation where an enterprise has outsourced its accounting, it needs to know its positions and continue investing even if its provider goes down or it loses connectivity. An enterprise shouldn't be relying solely on outside providers for its position data.

Much of this was captured in a letter from the UK Financial Services Authority to asset management CEOs in December 2012. The FSA wrote, regarding possible failures of service providers:

"

Some firms rely on taking activities back in house. We are concerned that any transfer would take many months and we do not believe firms would immediately have the capacity and abilities required," and "Some firms rely on being able to transfer outsourced activities to another provider. We are concerned about the considerable operational challenges inherent in a transfer as well as the probability that this could not be implemented swiftly enough to protect customers if an outsource provider were to fail."

The FSA went on to say, "We believe that it is the responsibility of firms' Boards to ensure that they have in place an adequate resilience plan which enables the firm to carry out regulated activity if a service provider fails."

IBOR can obviously play an important role here.

The full text of the letter is available at http://www.fsa.gov.uk/static/pubs/ceo/review_outsourcing_asset_management.pdf.

Technical strategy: this refers to how the IBOR physically gets realized, and there are several fundamental decisions to be made here, all of which should be informed more by the business strategy than the technical one.

The first fundamental theme in this category is robustness, and consistency with an enterprise's data strategy. While the term may be new, IBORs have, in fact, been around for decades, developed by tech-savvy portfolio managers using spreadsheets and Microsoft® Access, often to compensate specifically for many of the shortcomings already mentioned. These IBORs -- whatever people call them -- are tailored to specific strategies, and may contain extensions to the core set of portfolio data coming from ABOR. This has clearly worked for a long time, and the question is, is it really the best way to fill the need? What is being questioned here is not the use of spreadsheets for analytical purposes, but for data management purposes.

Spreadsheets are not an ideal way of managing portfolio data because
(a) the company is paying portfolio manager salaries for what is in effect data operational work, and
(b) these solutions fly under the radar.

The implications of flying under the radar are many, and include (1) remedial, reactionary work when something these informal solutions connect to gets changed or decommissioned, and (2) poor business continuity planning for what are, truly, mission-critical applications.

The industry should be moving the Excel-based databases out of analytical spreadsheets and handling them in a way that is consistent with firms' standards for handling mission-critical data.

Technical Strategies

Possible technical strategies include:

Real-time versus on-demand projection
Independent versus refreshed from ABOR
A single database for ABOR and IBOR

The first two items are interrelated, and are the subject of much discussion in buy-side technology circles.

Real-time versus projection: The term "real time" means that events that impact a portfolio position are applied to the book of record the moment they are known. The need for that is obvious in a retail point-of-sale system. But in most cases, it is sufficient for portfolio managers' purposes to be able to project positions from a known baseline (like start of day) and known events, such as orders, fills, and corporate actions. This need may differ from the needs of traders, who do need to know moment by moment what is in flight and what has been executed. The design patterns that result from the real-time-versus-projection decision will be different, so it is important to be clear what the business is trying to achieve.

Similarly, process and organizational patterns will be markedly different as a result of the other axis: independent parallel books that reconcile versus periodic refreshes from ABOR. Independent parallel books means the IBOR and ABOR each consume and apply position-impacting events to positions, and get reconciled periodically. The alternative model is that the IBOR is wiped clean on some predetermined schedule and refreshed with positions from ABOR. What these two approaches have in common is that there are scheduled points in time at which the two are guaranteed to be the same, and between which the two may diverge. A key difference between these two approaches is in what kind of history is retained in the IBOR.

Finally, there is the debate about whether the IBOR and ABOR can simply be views on the same physical database. This is at the core of the "single version of the truth" tagline. Some accounting system vendors advocate this approach, and it is indeed possible in certain circumstances, but only if portfolio accounting:

Is on a single system;
Is performed in-house;
Is the basis of other systems (e.g., OMS, portfolio models, compliance);
Can handle specific requirements of portfolio management;
Has owners prepared to maintain data in a timely fashion;
Includes unexecuted orders; and
Can reflect history as Portfolio Management needs it.

This would imply an end-to-end single solution including everything from portfolio decision making through to accounting. If all of the above conditions apply, it may be possible to adopt this approach. These conditions probably hold in many shops. Our experience with larger, more sophisticated operations leads us to postulate that they probably don't remain tenable as you ascend the complexity food chain. Enterprises with multiple OMSs, portfolio management systems, and accounting systems or providers quickly hit a brick wall in terms of integrating it all in such a way that all users can live off views of one database while remaining agile.

Potential IBOR Patterns

All of this implies different potential patterns of how an IBOR--or multiple IBORs--can serve different sets of functions in an investment management organization. Some illustrations follow.

Here is a generic footprint of a sophisticated asset management company:

Fig. 1. Generic footprint of a sophisticated asset management company

Taking the "independence" concept to its logical extreme with the most degrees of freedom, a "centralized IBOR" emerges--in Figure 2, that's the orange box covering the trading and enterprise functions--that is separate from the ABOR. ABOR may be outsourced. And portfolio management uses portfolio management-centric books of record, and in fact different strategies can be using strategy-specific books of record:

Fig 2. Fully separated books of record

The portfolio management groups have the option of going the independent-and-reconcile route or the periodic refresh route, and could reconcile either to ABOR or the centralized IBOR. The diagram shows reconciliation being required between each horizontally independent stage. In the case where PM IBORs or the centralized IBOR are maintained via the periodic refresh method, those arrows would become leftward "refresh" arrows rather than "reconciliation" arrows. This pattern satisfies most of the drivers, but stops short of being a "single version of the truth".

If "single version of the truth" is what is really wanted, this pattern emerges:

Fig 3. Single version of the truth

If the accounting platform meets the criteria discussed earlier, this is something that can be considered. While it satisfies the enterprise criteria and provides a "single version of the truth", degrees of freedom for portfolio management tools and for changing accounting systems or providers are limited. The reconciliation burden is avoided, however.

The last pattern, below, shows an IBOR created by virtualizing the books in multiple trading systems. "Virtualizing" means creating composite views into multiple databases rather than siphoning off and persisting records into another consolidated store--that wouldn't be virtual, and is akin to a data warehouse solution:

Fig 4. Virtual IBOR

This pattern also satisfies the majority of IBOR drivers, with the same cost of having to ensure the horizontally separate books are kept in alignment.

Definitions Revisited

Here are some definitions of IBOR floated by different industry players, with varying emphasis and weight given to the themes just discussed:

"

Centralizing positions across all asset classes and as the centralized repository of financial calculations such as key ratios, market values, and so on." (Todd Healy, BMO Asset Management, as reported in the Waters IBOR special report in November)

" A source of position data that is continuously adjusted for orders, executions, and corporate actions, and trusted by the investment function for the purpose of portfolio construction" (Jon Rushman, ex-BGI, as presented at a SimCorp IBOR briefing in July 2013)

" A catch-all term used to describe how asset managers extrapolate well-defined start and end points…to enable more judicious investment decisions" (Waters editorial)

One recent white paper went for the all encompassing definition, before admitting that such was unobtainable for all but the firms with enormous IT resources:

"

The 'Ultimate IBOR': Imagine a system that updates all investment activity in real time, 24 hours a day, every day of the year. Positions, Profit and Loss, Cash, Income, Corporate Actions, and Capital Activity all recorded in real time on a streaming basis. This same system can generate all reporting and on-line views from the most granular account level detail up to a consolidated enterprise view. Error corrections are processed as discovered and any adjusting entries are identified allowing end users to easily recognize data that has been impacted by 'as-of' activity. The system also feeds downstream applications in real time or releases data sets on a scheduled basis. At any given time a user can 'turn back the clock', select any point in time and view the data for that given time. All Front, Middle and Back Office professionals have access to the same data, generated from the same sources, using the same accounting methodologies. The system will generate 'Accounting' records based on user defined time periods. Reconciliations are reduced to a comparison to custody records." (Beacon CGI white paper, October 2013)

But Julian Webb of DST got it right when he said, "While the industry is working toward a commonly accepted definition of IBOR, individual firm requirements and the implementation path to achieving those will be different in each case." (as reported in the Waters IBOR special report)

Conclusion

So the process an enterprise should follow is:

A good immediate step: realize who in the business is the driving force behind implementing an IBOR.
Clearly firms have functioning investment processes; devote some time and effort to considering what gaps exist in those processes from both a departmental and enterprise standpoint.
Then line up the various themes and attributes of IBOR covered above, and analyze which of them are underserved today and how your evolution may affect that (or be affected by it).

There isn't a standard definition or specification that people can point to, and which IT can rely on as a blueprint; any IBOR initiative needs the enterprise's active ownership and engagement.

Each enterprise must own its own definition of Investment Book of Record.

Download the PDF version of this page