Most fund COOs have tried to build a single source of truth - or perhaps aspire to. One place the real number lives, so nobody has to work out which spreadsheet is right. The projects tend to go the same way: connect the systems, pick a central platform, pipe everything into it. A year later, the reconciliations are still running, and the single source of truth has turned into one more screen to check.
This piece is about why that keeps happening. The short version: a single source of truth is a decision about which system is allowed to be right, and a lot of firms have never made it.
Connecting Systems Exposes Disagreement
Start with the thing nobody says explicitly: each of your systems is already sure it's right. Your fund administrator's records are internally consistent. So are your accounting platform, your CRM, the investor portal, the custodian's record. Each one is a complete, confident version of the truth inside its own walls.
Wire them together and you don't get one truth. You get the disagreements you were living with (living with, not loving), now lined up on one screen. That is all a reconciliation is: two systems that were each certain, now meeting.
This is the flaw in the usual fix. A central data platform that reads from every system but can't overrule any of them is only a mirror. It reflects the disagreement; it can't settle it. Gresham Technologies, which builds this kind of software for banks and asset managers, lists exactly this among the common challenges: even when a firm stands up a central repository, it frequently becomes just another stop in the data chain rather than a genuine source of truth. A copy that can see everything and correct nothing is still a copy.
Nobody Decided Which System Wins
Here is a more usable way to frame it. You cannot automate an operating model while no system has been given authority over the state it runs on. Automation has to trust something. If nothing is designated as correct by definition, every automated step still ends with a person checking it against something else.
So the goal is not one store that holds everything. It is clear authority over each piece of state that matters, with clean lineage between them. For each domain, one system's answer wins, and the others are required to respect it.
This is where the usual instinct goes wrong. Firms tend to treat the system where the final number appears as the authority for everything behind it, and the fund administrator is the common example. Under the service agreement, the administrator may well be authoritative for the accounts, the NAV, the capital accounts and the investor statements, and often it should be. That does not make it the authority for the ownership and entitlement state those calculations are built on. Being the place a number is produced and being the source of the state behind it are two different jobs.
Making the State Authoritative As A Start
If you make one part of the fund authoritative before the rest, make it the ownership and entitlement state: who holds which position, in what structure, what rights and entitlements attach to it, and the transactions that change it over time.
But we have to be very specific about that claim because it is very easy to overstate. Ownership does not produce your NAV; the valuation process and the accounting do that. It does not produce a distribution either; that comes from realised proceeds, the waterfall, available cash and the terms. What the ownership and entitlement state does is resolve who is entitled to the result once it exists. Almost every investor-facing event, a capital call, a distribution, an allocation, a statement, a transfer, has to resolve the same underlying state: who holds what position, with which rights and entitlements, under which terms. That is why this state is worth pinning down first. It sits underneath the answers, not on top of them.
Note what this does not claim. An authoritative registry does not need to become the source of truth for every fact in the fund. The administrator can stay authoritative for the accounts. The bank stays authoritative for cash. The valuation process stays authoritative for valuations. The governing documents stay authoritative for terms. One system holds the authoritative ownership and entitlement state, the others hold their own, and each respects the one whose domain its work depends on.
Why This is Still Rare
If the fix is clear, why is it uncommon? Not for one dramatic reason. For a stack of ordinary, boring and simple ones: legacy systems that were never built to defer to anything, data models that don't agree, contracts that split responsibility across parties, the cost and risk of integration, and plain inertia around a process that currently 'works'. Underneath all of them sits the hard part: deciding which system should win when two disagree.
There is a governance edge to that last one. The moment a record is authoritative, someone owns being right or wrong about it, and accountability is uncomfortable to accept. You can watch the whole industry avoid it. In a 2025 survey of 272 capital markets firms by The ValueExchange, ISSA and Broadridge, most respondents said they want central securities depositories to hold a single official record, a "golden record", of event data, so the market stops reconciling the same facts by hand. The firms want the authoritative record to exist, and they would rather a neutral party hold it than fight over whose own record wins. Deciding who is allowed to be right is the hard part, not building the database.
The same survey attributed up to 67% of asset servicing errors to data issues rather than technology faults. That is a capital markets figure, not a private markets one, so read it as the shape of the broader problem: across the industry, most of what gets fixed after the fact is not a broken system. It is two records that were never told which one wins.
What Building It Involves
Treated as a question of authority, the work is but three decisions:
- Decide which system is authoritative, domain by domain. Ownership and entitlement, accounting, cash, valuations, terms: for each, name the system whose answer wins. Many have never made this call in the open, which is why the disagreements have nowhere to resolve.
- Make the ownership and entitlement state authoritative first. It is the state nearly every investor-facing event has to resolve against, so it returns the most for being pinned down. This is the job Tranche:source is built for.
- Connect the rest with lineage, and keep it in step. Other systems read the authoritative state and stay authoritative in their own domains. This does not end reconciliation. It changes it. The category that disappears is the internal one: does the administrator's investor register match our own spreadsheet? What remains is cross-domain and exception-based: does the cash that left the bank match the distribution calculated from the authoritative state, does the administrator's record still agree with it? Those controls are worth keeping, and they run against one reference instead of against each other.
A word on timing, because authoritative is not the same as real time. Private markets run on deliberate cycles: valuations strike at set points, NAVs close, calls and distributions have dates and approvals, accounting periods end. The point of an authoritative state is not that every downstream process fires the instant something changes. It is that the state is current, controlled and traceable, so each process knows exactly what it is acting on, and when.
Where This Leaves You
Private markets do not need one giant database. They need clear authority over the state that drives the operating model, and clean lineage between the systems that hold it. Get that in place and growth stops multiplying the mess: a new fund, a new investor, a new jurisdiction adds data under a known authority, instead of another copy for someone to keep in line.
That is what Tranche:source is built for: the authoritative state of ownership positions and the rights, entitlements and transactions attached to them, held as a record other systems can read and rely on. Not a better investor register, and not a warehouse trying to mirror everything else. Tranche:route propagates that state through the operation and orchestrates the work that acts on it, across the systems you already run, your administrator included, with reconciliation left to confirm the pieces stay aligned. The administrator stays. The accounting platform stays. What changes is that one record is finally allowed to be right about the state everything else depends on.
The technology to connect your systems has existed for years. What has been missing is a decision: which system is allowed to be right about what. Start with the ownership and entitlement state, because nearly every investor-facing answer has to resolve against it.
