Hello, world
We're building a fund data platform from scratch and we're going to write about every decision, every dead end, and every hard-won lesson along the way. This is the build log.
I spent seven years building and running fund data infrastructure at an enterprise platform. Hundreds of asset managers. Thousands of data feeds. Millions of NAV records flowing through pipelines every day. I've seen what works, what breaks at 3am, and what keeps ops teams staring at spreadsheets when they should be home.
Now I'm building Kairo, and I want to do something unusual for this industry: write about it as it happens. Not polished case studies published six months after the fact. Not marketing copy dressed up as thought leadership. The actual, messy, real-time process of building a fund data platform in 2026.
Why write publicly?
Fund data is a niche industry. The people who work in it know it intimately. The people outside it have no idea it exists. There's almost nothing written about the practical reality of normalising an OFST010010 field across forty different source formats, or why your ISIN matching broke because someone sent you a SEDOL in the ISIN column.
That gap bothers me. The best engineers I've worked with learned from other practitioners writing honestly about their work. Infrastructure engineers have their blogs. Frontend developers have theirs. Fund data operations has... vendor whitepapers and conference slides. We can do better.
What to expect
This blog will cover the things I actually think about when building Kairo:
- Architecture decisions — why we chose Openfunds as our canonical schema, how we handle deterministic vs probabilistic processing, what our pipeline topology looks like
- Industry observations — what's changing in fund data regulation, where the automation gaps are, what asset managers actually need vs what vendors sell them
- Engineering specifics — error handling strategies, identifier resolution, AI-assisted field mapping with guardrails, scaling patterns
- Honest assessments — what we got wrong, what we'd do differently, where we're still figuring things out
Posts will be short. Most under a thousand words. I'd rather write something useful in ten minutes than something comprehensive in ten hours.
Who this is for
If you work in fund data operations, fund administration, or asset management technology, you'll probably recognise the problems we're solving. If you're an engineer interested in data pipeline architecture in regulated environments, there's plenty here for you too.
If you're looking for generic AI hype or blockchain-will-fix-everything takes, you're in the wrong place. We use AI where it genuinely helps — field mapping, anomaly detection, schema inference — and deterministic processing everywhere else. No magic. Just good engineering applied to a domain that desperately needs it.
A note on honesty
I'm going to be direct in these posts. When something in the industry is broken, I'll say so. When we make a mistake, I'll write about it. When a competitor does something well, I'll acknowledge it.
The fund data industry has enough polished pitch decks. It doesn't have enough honest technical writing.
That's the gap this blog fills. One post at a time. We'll be here tomorrow with the first real post: why we're building Kairo in the first place.