Why we're building Kairo
Fund data is a solved problem that nobody has actually solved. I've spent the better part of a decade watching smart people wrestle with the same issues, and the tooling still isn't where it needs to be.
Here's a scene that plays out every morning at hundreds of asset management firms. An ops analyst opens their inbox. There are fourteen files from six different data providers. Three are CSVs. Two are Excel workbooks with multiple tabs. One is an XML feed that changed its schema last week without warning. The analyst opens each file, checks whether the NAVs look reasonable, maps the columns to their internal format, and loads them into whatever system they use — usually another spreadsheet.
This takes two to three hours. Every single day.
The gap between what exists and what's needed
The fund data industry has tools, of course. Bloomberg terminals. Morningstar feeds. Internal databases built by IT teams who left the company four years ago. Enterprise platforms that cost six figures a year and still require manual intervention for anything non-standard.
But there's a gap. A specific, well-defined gap that I kept running into:
- Ingestion is solved — you can get data into a system. But normalising it across sources? That's still manual mapping, source by source.
- Storage is solved — databases work fine. But knowing whether the data in them is actually correct? That's still eyeball-and-spreadsheet verification.
- Distribution is solved — you can send files and API responses. But ensuring the outbound data matches what the recipient expects, in their specific format? That's still custom code per client.
Every layer works in isolation. The connective tissue between them — the normalisation, validation, reconciliation, and transformation — is where things fall apart. And that's where ops teams spend 80% of their time.
Why now?
Two things changed that make this the right moment to build something new.
First, AI got good enough to be useful. Not good enough to run autonomously — I'll write more about this — but good enough to do the grunt work of schema inference and field mapping. When a new CSV arrives with a column called Fonds_Waehrung, an LLM can figure out that's the fund currency field and map it to OFST020050 with high confidence. That used to take a human twenty minutes of reading documentation.
Second, regulation got complex enough to demand automation. PRIIPs. SFDR. EMT. EPT. EET. The alphabet soup of European fund regulation keeps growing, and each new template means more fields, more validation rules, more things that can go wrong. You can't keep throwing people at this problem. The maths doesn't work.
What we're actually building
Kairo is a fund data assurance platform. That phrase is deliberate. Not "data management" — that's too broad. Not "data pipeline" — that's too narrow. Assurance means: data comes in, we normalise it, validate it, reconcile it, and deliver it outbound with confidence scores at every step.
The architecture is simple in concept:
- Ingest — accept any format from any source. CSV, Excel, XML, API, SFTP. Don't make the sender change.
- Normalise — map everything to a canonical schema (we chose Openfunds, more on that in a future post). AI assists, human approves, deterministic pipeline executes.
- Validate — run business rules. Is this NAV within tolerance of yesterday's? Is this ISIN actually valid? Does this fund currency match what we've seen before?
- Deliver — push data outbound in whatever format the recipient needs. Their schema, their column names, their file format.
Each step produces an audit trail. Every transformation is logged. Every validation result is recorded. When a regulator asks "why did you publish this NAV?", you can trace it back to the source file, the mapping rule, and the validation that approved it.
The honest version
I won't pretend this is easy. We're building in a domain where a single wrong decimal place in a NAV can trigger regulatory action. Where data providers change their formats without notice. Where "the file didn't arrive" is a daily occurrence that needs automated handling.
The bar for reliability in fund data isn't high because the industry is demanding. It's high because the consequences of getting it wrong are real.
That's why we're building Kairo. Not because the problem is glamorous — it isn't. Because the problem is important, the existing solutions aren't good enough, and for the first time, the technology exists to do it properly.
Tomorrow: the build vs buy decision matrix in fund data, and why "just use Excel" works until it doesn't.