Ask an investment team a question about their own portfolio and watch what happens. Not an easy question, but the kind of question institutions actually need answered day to day: what’s our total exposure to a single company, across every fund, co-investment, and GP relationship? The data exists somewhere. Getting it out, reconciled, and in front of someone who can act on it is another matter entirely, often a multi-week exercise that pulls in several teams, several exports, and a spreadsheet nobody fully trusts by the time it’s done.
That gap, between the data existing and the institution that can use it, is the real problem. There’s no shortage of tools, but there’s no way to ask a question that spans systems and get a trustworthy answer back the same day instead of a project.
The current state
For decades, the answer to “how do we manage a complex portfolio” was the same: buy the best tool for each job and pay someone to stitch them together. An accounting ledger for the books, a separate system for document ingestion, another for data extraction, a different tool for analytics and reporting, a CRM off to the side to manage relationships. Each one is excellent at its job in isolation, but none of them share a data model.
That wasn’t a mistake. Each layer was hard enough to build that no single company could do all of them well, so specialization was the right call. What’s changed more recently is that the cost of not connecting them has grown faster than the cost of building each one separately ever did.
Stitching specialized systems together usually means building an internal enterprise data warehouse: a multi-year, multi-million-dollar project that becomes its own maintenance burden the moment it ships. Data hops from application to warehouse to another application to a reporting layer, with a quality checkpoint at every jump. When a position is missing, the whole loop restarts. The result is a pipeline that takes 12+ hours to produce a number your investment team needed that morning.
That architecture was built for a post-2008 world that prized accuracy above speed, and it was the right tradeoff at the time. But the questions institutions ask now don’t fit a batch model. What’s our total exposure to a given sector across every fund, co-investment, and direct deal? Answering that means traversing multiple systems, entity structures, and ownership layers, and it’s only useful if it arrives same-day, not next quarter.
Here’s the sharper version of that question, and the one that actually tests a platform: what’s our total exposure to a single company, across every fund we hold, including the ones we’re only exposed to two or three layers deep through a GP relationship? Most systems can answer the first question at the fund level. Almost none can answer it at the company level, across structures, without someone manually tracing ownership by hand.
The portfolios generating these questions are also changing shape. Public pension allocations to traditional public equities and fixed income have fallen from roughly 80% to 90% of the typical portfolio in the early 2000s to about 66% today, with the difference moving into private equity, private credit, real estate, and other alternatives (Reason Foundation, 2025 Annual Pension Report). That shift isn’t slowing down, and alternative asset classes keep proliferating on top of it. Each new allocation adds another seam to a stack already held together with exports, imports, and someone’s afternoon spent reconciling spreadsheets.
Part 2 looks at why the obvious fix, adding an AI layer on top of these existing systems, runs into a structural ceiling, and how Mantle Portal built a unified data model instead.
Learn more about Mantle Portal
If you’re interested in learning more about how Mantle Portal can help your investment operations, book a demo here.
Brendan Cahill is the Head of Product for Mantle Portal, where he leads product strategy and development for Mantle’s AI-powered platform serving institutional LPs, family offices, fund-of-funds, alternative asset managers, and more.