Marc Andreessen's line from 2011 was that software was eating the world. Fifteen years on the phrase has been stretched to cover almost everything, so treat this borrowed version of it with some suspicion. APIs are not about to swallow private markets the way the headline promises. Something narrower is happening, and the narrow version is the one you can act on.
Here is the honest version of it: the way parties in a fund exchange facts is changing shape. For a long time a fact travelled by being written into a document, sent, and typed into the next system by hand. Increasingly it travels as structured data that one system reads from another directly. The document doesn't vanish in that picture because it stays as evidence. What changes is that it stops being the thing systems have to open and re-key to get the number out.
That shift is real, it's already visible in the parts of finance next door to you (retail banking), and it will reach your operating model. What it rewards is whether the systems doing the reading already agree on what the data means and which record has authority over it. Connectivity for its own sake buys you nothing. Connect first and settle that later, and all you’re doing is automating your existing problems.
What Is Being Eaten
Start with the shape of the change, not the acronym.
In the past, private markets ran on documents. A capital call is a notice. A valuation is a figure in a report. A position is a line an LP's team copies into its own system. For the most part, the facts are right, but they move by being produced in one place, sent, and entered again somewhere else, and every re-entry is a place the number can drift.
So what is an API: an API is a defined way for one system to ask another for a specific fact and get it back in a form it can use, with no one opening a file and typing the number in again. The administrator's NAV, read by reference. The register's ownership position, read by reference. The executed LPA, the subscription agreement, the side letter, the capital call notice: these remain. They stay as the evidence an operational record is built from and checked against. What changes is that they stop being the layer systems pull operational data out of by hand. The structured record becomes that layer, and the document sits behind it as proof.
So "APIs are eating private markets" does not mean a platform that replaces your administrator, your fund accounting system, your custodian or your CRM. It means a much more subtle change in how facts get from one party to the next, and in what those parties are reading when they act.
This is the next step in a direction earlier pieces here have already traced: data gets structured, structured data gets authority, workflows produce evidence. What follows is systems reading those records directly, and that is the point at which the quality of the records stops being an internal matter.
The Move Has Already Happened Next Door
If you want to see the architecture, look at the part of finance that got there first.
Retail banking made this shift in public, at national scale. Under open banking a bank exposes account data and payment initiation through APIs, and a third party reads them with the customer's consent rather than scraping a statement. In 2025 UK open banking logged 24 billion API calls, processed 351 million payments, and reached 16.5 million active user connections by December, up from 12.1 million a year earlier, according to Open Banking Ltd.
Take the architecture from that example (but do not take the timeline). Open banking got there because regulation mandated it and a common standard was imposed on every participant. Private markets have no equivalent universal framework, no single body requiring your counterparties to expose their records in an agreed shape. So the same architectural shift, from documents and manual extraction to direct system-to-system access, will arrive here through a messier mix: standards that cover some of the ground, administrators building connectivity at their own pace, technology providers, LP demand, and regulatory pressure pulling in the same rough direction without coordinating. The destination is comparable, but the road to on the way there is definitely not going to be paved the same way.
Piping Isn't Really The Challenge
Connectivity is the visible half. Agreement is the half that decides whether it's worth anything.
It helps to separate three problems that an API is often assumed to solve together, because it only solves one of them.
The first is transport. Can system A get a fact to system B without a person carrying it across? An API solves this cleanly. This is the part everyone means when they say two systems are "connected."
The second is meaning. Do A and B understand the fact the same way? Does NAV here mean NAV there, does a commitment include the same items, does a distribution net against the same things? An API does not solve this. It will move a misunderstanding between two systems exactly as faithfully as it moves an agreement.
The third is authority. When the two records disagree, which one governs? An API certainly does not solve this. It has no opinion about which system is right. An API is how the agreed answer travels. It is not the agreement, and it is not the authority.
Cross-border payments show how far apart transport and meaning sit. Banks have moved messages to each other over a shared network for decades. The network was not really a problem there because it already existed. The generational task was agreeing a common, structured language for what a payment message contains. That language, ISO 20022, was first published in 2004, and the coexistence period for legacy formats in cross-border payments only ended on 22 November 2025, per SWIFT. Roughly two decades to agree on meaning, on a rail that already worked. The Modern Fund Is Becoming Data Native makes the same point at the level of one record: interoperability is a question about meaning before it is a question about pipes.
Connection Without Agreement Multiplies the Reconciling
Wire five confident systems together and you don't get one truth. You get five truths, side by side.
Here is the failure mode, and sophisticated operators walk into it with good intentions and a budget. You connect everything: the administrator, the fund accounting system, the CRM, the investor portal, the custodian. Each one is internally certain it's right. Connecting them doesn't produce agreement. It lines up the disagreements you were already living with, now visible on one screen and moving faster. That is all a reconciliation is: two systems that were each certain about their facts, meeting.
Notice how the didn't create the disagreement? The administrator's register and your internal books were already out of step, and the API just made the gap immediate and carried it downstream at speed. Connectivity is genuinely useful. It removes the re-keying, cuts the document shuffling, and lets systems act on each other's data. But in the same way, it also exposes the exact quality of that data, and an unresolved disagreement travels faster once it's wired.
Which is why the connection is necessary and, on its own, settles nothing. What settles things is a decision about authority, and here it doesn’t work to just say, "one system is allowed to be right about everything." Different records can legitimately govern different facts. The fund accounting system can be authoritative for the accounts, the bank for cash, the valuation process for valuations, the governing documents for terms. The question is which source has authority over each particular fact, with clean lineage between them. No single system has to win outright. Building a Single Source of Truth works through why the ownership and entitlement state is the one worth pinning down first, since nearly every investor-facing event has to resolve against it.
What a GP or COO Should Take From This
The trend is not "buy APIs." It is something more like, "settle meaning and authority before the connections arrive."
You don't need a lecture on APIs. You've lived the underlying problem for years: administrator versus internal books, register versus accounting platform, custodian versus administrator, spreadsheet versus system. The problem was never connectivity. Connecting those systems faster doesn't make them agree.
What makes this worth attention now is that the pressure is arriving from several directions at once. The adjacent-finance shifts above show the architecture is proven and dated - it is old news. LPs increasingly ask for data in a form they can pull cleanly into their own systems. Tokenisation puts the register on a shared ledger, which changes little if the records feeding it were never agreed. AI is only as useful as the structured, trustworthy inputs it can read. No one of these forces the change on its own. Together they mean your operating environment is becoming machine-readable from multiple sides at once, and each side reads whatever state your records are actually in.
So the practical implication is a sequence, not a technology choice. Before more systems start consuming your records, those records need to carry their own meaning and sit under a clear authority, fact by fact. Firms that do that work first will already be legible when the connections reach them. Firms that connect first will find that wiring up to a counterparty exposes precisely how much was never pinned down.
Where This Leaves You
APIs are the shape of the change, where meaning and authority are the substance.
"APIs are eating private markets" is false if you read it as a promise - it is a quip on an old phrase, but nonetheless useful in making my points. The document-exchange model is giving way to systems reading each other's records directly, and the evidence for that is very well documented and you interact with it elsewhere every, single day. What the phrase doesn’t do a great job of describing though is that connection was never the challenge. Agreeing what the data means, and deciding which record governs each fact, is the work that makes any of it hold. Get it wrong and the API becomes a faster way to spread a disagreement.
That's the premise Tranche:os is built on, and it's why the answer here is an authoritative record the systems you already run can consume, rather than another large system placed beside them. Tranche:source establishes that record for the state nearly every event resolves against: who holds which position, under which terms, with which rights and entitlements. Tranche:route lets it move through the systems you already operate, your administrator included, and orchestrates the work that acts on it. Reconciliation doesn't disappear, because independent parties and systems still exist. Its job changes. It stops being the process that decides what's true and becomes the check that confirms the other systems still line up with a record that was already authoritative.
The connections are coming either way, from the LP, the administrator, the regulator, the ledger. What decides whether they help you is whether the meaning and the authority were settled before the first one was ever pointed at your data.
