Four systems and a spreadsheet: why the total portfolio view still eludes most firms, and what AI does not change

By Gus Sekhon, VP Strategy, FINBOURNE Technology

Large asset owners and managers have spent the last decade buying systems that promised a single, real-time view of their positions, known as the investment book of record (IBOR).

Yet at many of those firms, what sounds like a simple question is still hard to answer: what is our total exposure, across the whole fund, right now? The answer is usually a team effort, arriving days later, hand-cranked in Excel from four systems, with caveats on page three.

We wrote recently about why the IBOR so rarely delivers what it promises.

The gap now matters more, because more is being asked of the record. Private allocations have risen, and private assets do not behave like listed ones: they are valued quarterly, called unpredictably and reported late. America moved to T+1 settlement in May 2024, and Britain and the EU follow in October 2027. The share of derivatives margins held as non-cash collateral is at a record high, and externally managed funds are growing more complex while the asset mix as a whole becomes less liquid.

The industry has never agreed what a total portfolio view requires, so let’s start with a definition in six parts. Then we look at the five ‘solutions’ you typically see and what part AI is playing and will play in those solutions. Finally, we set out what you should test before committing to any of them.

Why the problem persists

Firms did not buy badly. They ran rigorous selections and chose competent systems that do what they were built to do. The trouble is that each platform is built around a data model dedicated to its own function, and until now a total portfolio view has not been one of those functions.

Portfolio construction, order management, accounting, risk and private-markets administration each have a system shaped to do that one function well. A total portfolio view sits across all of them, and across the custodians, fund administrators, general partners, external managers, data vendors and spreadsheets that feed them. Each platform sees the estate only from its own records.

The analytics are largely solved: models that span public and private exposures already work. What remains unsolved is whether positions arriving from many sources, on different cycles and with different degrees of certainty, can be held in one record that states what is known, and when it became known, for every report the firm must produce.

What a total portfolio view requires

Our definition involves six criteria, and we would consider a system that meets five to represent a partial view.

First, the system must hold listed and private assets in the same position record. A listed equity holding and a private credit commitment should appear in the same answer, as at the same date, and both should remain correct when either position changes, especially if the change is backdated.

External and internal managers must have the same footing. Where an external mandate is represented as just a single record and value, the firm cannot correctly state its exposure by sector, counterparty, currency or issuer. At a minimum, the system should hold external positions at whatever level of detail the manager provides and record that level as an attribute. The firm can then say how much it knows at holding level, how much at fund level and what information is therefore missing.

The system must support several books at once, without over-weighting any one of them. Large asset owners run an investment book, an accounting book, regulatory bases, and usually an internal view for the investment committee. Each answers a different question, so each looks different, and each is correct. The system should produce all of them from a single event history, so differences between the books are explained by the basis rather than chased as breaks. Reconciliation against custodians and administrators carries on regardless. That is a different job.

Every input must show how fresh it is. If the listed book is intraday and the private book was last valued at quarter-end, the total is a quarter old, even if it looks live. The record should state, for every value, when it was struck, where it came from and when it arrived. That way, if your risk is stale, you know it’s stale. And when the investment committee stands behind a number, it knows what it is standing behind.

Corrections must append rather than overwrite. Valuations are restated weeks after quarter-end, capital-call notices arrive late and trades get rebooked. A system that overwrites erases what it originally reported, leaving the firm unable to reproduce or defend reports it has already issued. So every event needs two dates: the date it applies to and the date it became known. This is bi-temporality, and it is very hard to retrofit, which is why buyers should test it first, on a real restatement.

Finally, the firm must own the data model. If extending it requires a vendor feature request, the firm can respond to a new asset type or reporting obligation only as fast as that vendor’s roadmap allows. And heaven forbid there are multiple vendors involved. Ownership also means the firm decides who may change the model, under its own approval rules. Those rules can be as strict as the firm likes, but the change itself should take minutes, not a release cycle. And if it changes provider, the firm should be able to bring its full history along, in a form that can still be reconstructed as at any past date.

The five answers the market offers

Firms are typically offered one of five approaches. We are asked about the fifth more than the other four combined.

The first answer is consolidation. The firm retires its point solutions and runs everything on one front-to-back platform. Architecturally, this is the most coherent answer: a single data model removes the aggregation problem altogether. But that data model is always fixed, needing the firm to consume and operate from an entirely new, inflexible taxonomy. It also asks the firm to migrate off systems that work, at least in isolation, and the migration rarely finishes: in SimCorp’s 2026 survey of 200 large buy-side firms, 58 per cent named vendor consolidation their top priority, yet only 20 per cent have a unified platform. The firm ends up with a view that is complete for the part of the estate that migrated but with workarounds for those parts that simply don’t fit. Check how loan facilities, PIK’d coupons and collateral fit into the single model.

The second is an overlay. The firm keeps its underlying systems and places an integration, analytics and reporting layer over the top of them. It is the quickest route to a usable picture, and nothing has to be decommissioned. But the numbers produced are difficult to defend without reference to the sources and the problem compounds when the query is historical. Buyers should also ask what the overlay picks when the custodian and the administrator disagree.

The third is a managed service. The firm hands ingestion, mastering and governance to a provider and consumes the result. That hands the data model to the provider, which runs a normalised setup built for all its clients. It works until the firm needs something the normalisation did not anticipate. Which is usually anything new.

The fourth is to start with accounting. The firm replaces or modernises the accounting engine, on the argument that no reporting layer can be more reliable than the accounting book beneath it. A modern accounting engine is a real improvement on many incumbents. The trouble is that it sits downstream of the data, so it changes how the firm processes its inputs without changing the inputs themselves. And the accounting book is only one of the bases the firm needs.

The fifth is the big one. ‘With AI to assist, why wouldn’t we build it ourselves?’ The firm puts everything in a cloud data platform and designs the investment data model itself. Of the five, this is the only one that guarantees the last total view requirement, ownership of the data model, because the firm designs the model itself. But a cloud data platform is storage and compute. It is not a head start on the model. Bi-temporality, tax-lot aware position construction, corporate actions, look-through and state management all have to be built. Then maintained, for as long as the firm exists.

Build-it-yourself programmes usually get the warehouse up and running, and AI will now return something that looks like a credible data model alongside it. Cue the fanfare. But who designs the glossary, the rounding, the partial failure states, the supported bond conventions, the closed period management, the result dimensions, the property timelines, the identity cross-referencing and the thousands of other choices that have to be made and then owned? Every one of those has been designed before. Rebuilding them is like writing your own Office.

And the test for success is simple. Restate a valuation after the quarter’s figures have gone out, then ask the warehouse what was reported before.

What we built instead

FINBOURNE started with the data model, not the functions. The model is designed to hold an entire estate, and the components sit on top of it. Building in that order matters, because a model built for one function rarely stretches to cover the rest. The record holds positions from sources the firm does not control, produces several books over one event history, and records every event against two dates: when it happened and when the firm learned of it. That is how the core platform works by default, so any past report can be reproduced exactly. Downstream systems query it rather than take extracts, because an extract starts to drift the moment it is taken.

It does not make private valuations arrive more often, because a quarterly valuation is quarterly whoever holds it. What changes is that the record says so, and keeps what was reported before any restatement. Nor does it require a firm to replace its accounting engine, risk model or order management system. Where a firm keeps an incumbent system, we master and unify the data beneath it and feed outputs back into it where execution has to happen.

Four questions to ask your provider

Firms being told that a total portfolio view is available should ask their provider four questions.

First, can you ingest and unify positions from the systems, custodians and managers we intend to keep? A good answer names third-party sources that are in production today and queried as a single record. A weaker answer describes integration as a project, and arrives with a statement of work.

Second, what happens to our history if we change providers? A good answer sets out what leaves with the firm, in what form, and whether past positions can still be reconstructed afterwards. An export of current positions is not history.

Third, who controls the data model, and can we change it without a vendor project? The right answer is short: the model belongs to the firm, and extending it does not need a release.

Fourth, when a private valuation is restated, what happens to the exposure we reported last quarter? The answer to listen for is that the restatement is appended and the earlier figure can still be reproduced exactly as it was reported. Any system can claim to handle corrections, but only one that records both dates can tell a firm what it said before the correction arrived.

To see how FINBOURNE answers these questions on a real multi-source estate, ask us for a demonstration.