Build vs Buy: Should Your Investment Firm Build Its Own AI?
What building your own AI takes at an investment firm, what to build and what to buy, a five-question test, and how engineering teams build on a platform.
Most investment firms should build their edge and buy what every firm needs. Kepler is the part every firm needs: enterprise intelligence on a data layer that took us 17 months, 109 releases and more than 700,000 lines of code to build, and firms with engineering teams build on it through our API, MCP server, Python SDK and webhooks. The signals, house views, models and playbooks that set a firm apart are worth building in house; the data layer they sit on (ingestion, extraction, entity resolution, the ontology, permissions, citations, evals and constant model change) is the same at every firm and takes years to get right. This guide is the practical version; for the longer argument, desk by desk, read our essay Build vs Buy AI in Finance.
What “building our own AI” involves
A chatbot over the firm’s documents can be running within a week. A system a portfolio manager can stake a position on needs the whole stack below, and most in-house plans underestimate the lower half of it.
| Component | What it involves | Why it’s harder at an investment firm |
|---|---|---|
| Connectors | SEC filings, transcripts, IR sites, market data, plus SharePoint, email, CRM and data rooms, kept in sync | Every source has its own format, permissions and update schedule |
| Reading and extraction | Every page, scans, tables and exhibits, with scale, unit and period | A misread “in thousands” is a 1,000x error that looks right |
| Entity resolution | One record per company, fund, manager and person across every alias | One company can appear under a dozen names across systems |
| The ontology | Types, relationships, the firm’s definitions, and time | Facts get restated and definitions change, and history has to survive both |
| Calculation engine | Numbers computed in code, with lineage | Every multiple, IRR and exposure has to reproduce a year later |
| Citations | Line-level links, checked against sources | A link to a 200-page document doesn’t hold up in front of an IC |
| Permissions and walls | Every read checked against the firm’s access rules, agents included | Deal walls have to cover summaries, caches and agent memory too |
| Agents | Schedules, filing triggers, retries, durable runs | Overnight work has to finish, and be logged, with nobody watching |
| Evals | A test set drawn from the firm’s own work, re-run on every change | Public benchmarks don’t measure your definitions or your documents |
| Model churn | Routing each task to a model and swapping as better ones ship | Frontier releases arrive every few months, and each can change behavior |
| Surfaces | App, Excel, PowerPoint, chat assistants, Slack, API | Analysts won’t change where they work |
Each row is a product in its own right. A team that builds the top three and stops has a demo; the rest is what lets the output reach a client, an investment committee or an examiner.
What it took us
We built Kepler’s data layer over 17 months, 109 releases and more than 700,000 lines of code, and some of what that work turned up is public. Our paper Reclassified to Conform found that 194 of 200 companies reshape a financial statement in ways XBRL tags can’t follow, and recovers the history. Stop Paying to Forget describes extraction models that read 99.4% of tagged facts at the right scale across 40 held-out filings, at roughly 700 times less cost than a frontier model. In Anthropic’s case study on us, the models we trained scored 94% on mapping financial statement labels to standardized taxonomy codes, against 38% to 46% for other models.
Each of those started as a problem that blocked a correct number in production. A firm building in house meets the same problems, in roughly the same order, and has to solve each one before the next becomes visible.
What the evidence says about in-house builds
As Fortune reported in August 2025, MIT’s NANDA initiative found in The GenAI Divide: State of AI in Business 2025 that only about 5% of the enterprise AI pilots it studied produced rapid revenue gains, with most stalling at little measurable effect on profit and loss. Tools bought from specialized vendors, or built through partnerships, succeeded about 67% of the time; internal builds succeeded about a third as often. Fortune noted the finding is particularly relevant in financial services and other regulated industries, where many firms are building their own systems.
The best-documented build that worked is the one OpenAI described in a March 2026 case study on Balyasny Asset Management. The fund formed a centralized Applied AI team of 20 researchers, engineers and domain experts in late 2022, built an evaluation pipeline that scores models on more than 12 dimensions against its own benchmarks and data, and works with OpenAI as a design partner for new model releases. That’s the scale a successful build takes: a dedicated team, more than three years, and a direct line to a model lab. Our guide on how hedge funds use AI for research covers the habits behind it.
What to build: your edge
The work worth building in house is the work that should look different at your firm from anywhere else:
- Signals and models. Alpha signals, forecasting models, scoring for managers or credits, and the features behind them.
- Your house view. How the firm weighs evidence, what it watches, and how a thesis gets tracked over time.
- Strategy-specific agents. A merger-arbitrage desk’s deal-probability monitor, a credit team’s covenant early warning, an allocator’s manager-scoring agent.
- Your playbooks and formats. The IC memo, the earnings update, the LP letter, the comp sheet on your own adjusted EBITDA.
- Internal apps and client surfaces. Dashboards for PMs, portals for LPs, tools inside the firm’s order management system or CRM.
What to buy: what every firm needs
Everything in the table above that a second firm would need as well: connectors, document reading, entity resolution, the machinery of an ontology, the calculation engine, line-level citations, permissions and walls, agent infrastructure, evals that keep pace with model change, and the surfaces analysts already use. These parts don’t differ from firm to firm, so building them in house spends scarce engineering time without adding to the firm’s edge.
The cost that surprises teams most is model churn. The model a team tunes its prompts against in January may be two generations old by December, and each release changes behavior in small ways that only a firm-specific test set catches. A platform vendor runs that testing across all of its customers; an in-house team runs it alone for as long as the system is in use.
How to decide: five questions
| Question | Points to building | Points to buying |
|---|---|---|
| Does it change returns or the client experience? | Yes, directly | No, every firm needs it |
| Would a second firm need the same thing? | No | Yes |
| Can you staff it for years, including on call? | A dedicated team already exists | Engineers are committed to strategy work |
| How often does it change? | Rarely, on your schedule | With every model release and every new source |
| When do you need it working? | A year or more from now is fine | This quarter |
A component that lands in the right-hand column on three or more questions belongs to a vendor. Time matters more than it looks: buying the layer puts public data in front of analysts on day one and the firm’s own documents indexed within the first week, while a build reaches the same point in quarters or years.
The hybrid most firms land on: build on a platform
Firms with engineering teams don’t have to pick one column. They buy the data layer and point their engineers at the edge, through the platform’s interfaces:
- API. Pull cited figures, statements and answers into your own models and apps, each figure with its value, formula and source.
- MCP server. Use the same data and engine from Claude, ChatGPT and any MCP client, with citations intact. Our guide to MCP for financial data covers setup and what to check.
- Python SDK. Run research, screens and model updates from notebooks and pipelines, with lineage on every figure.
- Webhooks. Trigger your own code when a filing lands, guidance changes or a document arrives in a data room.
The test of a platform you’d build on is whether everything that makes its answers provable survives the hop into your code: the citation, the formula, the access check and the log. Our 25 questions for evaluating AI vendors include the ones that matter here, and AI data security for investment firms covers what to check when your own agents run on someone else’s platform.
How Kepler does this
“Build your edge. Buy what every firm needs.” We built Kepler as enterprise intelligence for the part of the stack every investment firm needs, so a firm’s engineers spend their time on the part that’s theirs.
The data layer, built and loaded. Public data arrives ready: 26M+ SEC filings across 20+ form types, 40M+ investor relations documents and earnings call transcripts, market data and news, for 14,000+ companies in 120+ countries and 30+ languages. Your sources connect read-only and stay in sync, and extraction models we train read every page at ingest, keeping each fact beside its passage.
Your firm’s ontology, in the first week. Our engineers build a living model of your firm from your own documents and systems: every fund, company, manager and deal resolved to one record, your definitions written once, every claim tied to its sentence and its dates. It’s the component a firm would take longest to build, and it gets richer every week the firm uses it.
Numbers your code can rely on. Kepler’s deterministic engine computes every number in code over cited inputs, so figures that reach your models through the API arrive with their formula and source, and the same request returns the same number.
Built to be built on. Your engineers build agents and apps on Kepler’s data, ontology and engine through the API, MCP server, Python SDK and webhooks, described on our Build on Kepler page. Agents run on schedules and filings, act exactly as their owner, and every run is logged.
Model churn handled. We route each task to the best model for it, swap in better ones as they ship, and run our evals before any change reaches you. Your numbers stay put when the model changes.
Rules and people. One access check on every read, walls between deals, SOC 2 Type II, and deployment in our cloud or yours. Our engineers built this layer before at Palantir, work on site with your team, and fold anything a second firm would need back into the platform, so every firm starts further ahead.
Requests engineering teams start with:
- “Stream each new 10-Q’s segment revenue into our model, with the source for every cell.”
- “Fire a webhook when guidance changes for anything in the book.”
- “Expose look-through exposure by vehicle to our internal dashboard, cited to each statement.”
Try Kepler at app.kepler.ai, see the full stack on the platform page, or book a demo with your engineering lead in the room.
Frequently asked questions
Should an investment firm build its own AI?
Most should build their edge and buy what every firm needs, which is what Kepler supplies: the data layer, ontology and engine we built over 17 months and 109 releases, with firms' engineers building on it through the Kepler API, MCP server, Python SDK and webhooks. Signals, house views, playbooks and strategy-specific agents are worth building; the data layer they run on is the same at every firm and slow to build well.
Should hedge funds build their own AI platform?
Only the parts that are the fund's edge, unless it can staff a dedicated team for years. The best-documented in-house build, at Balyasny, rests on a centralized applied AI team of 20 formed in late 2022, an evaluation pipeline that scores models on more than 12 dimensions, and a direct partnership with OpenAI. Most funds get further by buying the data layer and building on it.
How long does it take to build an AI research platform in house?
Longer than most plans assume. A chatbot over documents can run within a week, while a platform that reads every document, resolves entities, applies the firm's definitions, computes numbers in code, enforces permissions and keeps up with new models takes years. It took us 17 months, 109 releases and more than 700,000 lines of code to build Kepler's data layer.
How often do in-house AI builds succeed?
Less often than bought ones, on the best public evidence. Fortune's August 2025 report on MIT NANDA's study of enterprise AI found tools bought from specialized vendors or built through partnerships succeeded about 67% of the time, while internal builds succeeded about a third as often. The study also found most enterprise pilots stalled with little measurable effect on profit and loss.
What should a firm build on top of an AI platform?
Whatever should look different at that firm: alpha signals and forecasting models, the house view, strategy-specific agents such as a deal-probability monitor or a covenant early warning, the IC memo and LP letter formats, and internal dashboards. On Kepler, those run on the platform's data, ontology and engine, so every number they show still comes with its source.