Most platforms in our industry sell themselves on cleverness. A proprietary risk model, a unique allocation engine, a domain-specific language for compliance rules. Each one a small monument to the brilliance of the team that built it.
The cleverest stack rarely wins. The most open one usually does.
A short history of vendor lock-in
Asset management technology has been through three rough cycles. In the late nineties, the prize was the spreadsheet replacement — the first generation of position-keeping systems that lived alongside the trading desk. In the 2000s and 2010s, it was the integrated PMS — Aladdin, Geneva, SimCorp — promising to absorb everything from order management to risk to reporting under one roof. We’re now in the third cycle, where the assumption that one vendor can credibly own the whole stack is being questioned for the first time in twenty years.
The reason isn’t ideological. It’s empirical. The integrated stack failed at one specific job: surviving change without an enterprise-grade engagement.
Three things every stack survives
If you’re building or buying technology for an asset manager, the test isn’t “does it work today?” It’s “will it survive the next three things that always happen?”
The next regulator. Every five to seven years, a new directive lands. NCG 507. UAF. SBS. MiFID II. The systems that survive these are the ones with explicit data models, open APIs and the kind of audit trail you can hand to a regulator without a translator.
The next custodian. Mergers, country expansion, a new family-office mandate that demands Pershing. The systems that survive these are the ones whose connector layer is a library, not a one-off integration each time.
The next CTO. People change jobs. Roadmaps shift. The systems that survive these are the ones whose code lives in your repository, whose data lives in your database, and whose operations the next person can pick up without a six-week handover.
The cleverest stack is rarely the most open. But the most open is almost always the one that’s still running ten years from now.
What “open” actually means
It’s a fuzzy word. We’re specific about what we mean by it. Three properties, in order of importance:
- Open data. Your data is yours. Schema documented. Exports trivial. No proprietary binary formats. No vendor “holding” historical positions.
- Open APIs. Every action a user can do, an API can do. No “you have to use our UI for that.” Audit trails are themselves an API.
- Open process. The roadmap is visible. Disagreements happen in the open. Your team can read the issue tracker.
We’ve found that managers who insist on these three properties end up with technology that compounds over time — even when individual pieces of it are less impressive than the alternatives. The engagements we walk away from are usually the ones where a vendor (or sometimes a manager’s own internal team) is fighting one of these three.
A confession
We’ve built proprietary tooling. Of course we have. Our connector library is a real piece of intellectual property, and we charge for access to it. Our compliance engine has rules in it that we figured out the hard way and didn’t give back to the rest of the industry for a year.
But every piece of software we’ve shipped that survived more than three years has been the more open option than the one we initially designed. Every piece we’ve watched die has been the cleverer one.
Closed systems are seductive. They feel like ownership. They feel like a moat. In practice, they’re a tax — paid mostly by the operators who inherit them.
Open beats clever. Build accordingly.
Santiago Fuentes is a founding partner at finnerve. This is one of an occasional series of notes on what we’ve learned from building investment management technology with operators across Latin America and Europe.