Build vs Buy AI in Finance

Couldn’t we just build this ourselves?

Some version of that question comes up in nearly every conversation we have with an investment firm, and over the past year we have had those conversations with hundreds of them: hedge funds large and small, private equity and credit managers, allocators, family offices and banks. It is a perfectly reasonable thing to ask. These firms employ smart people, the tools for building with AI improve every month, and nobody likes paying a vendor for something they suspect they could make themselves.

The words have stayed the same all year, but a year ago the firms asking them meant something quite different.

One question, three meanings

Late 2025: “Can the model just do this?” When firms first asked, they were really asking about the model. Most had rolled out ChatGPT Enterprise or Copilot, and the working assumption was that each new release would close whatever gap remained, so building anything seemed premature. The assistants turned out to be very good at emails, summaries and first drafts, and almost nobody trusted them with a number. By spring we had stopped hearing “ChatGPT does this” on calls altogether.

“Every few months the model got better, so the plan was basically to wait for the one that could do the whole job. That was a year ago. We’re still waiting.”

— Head of Research, Long/Short Equity Fund

Spring and summer 2026: “We’ll build it ourselves.” Then the tools changed. Coding assistants like Claude Code, along with connectors that plug a model straight into your drives and data feeds, turned an AI analyst into a weekend project, and nearly every firm with an engineer started one. Firms that had never hired a technologist hired an AI lead, and wherever we went the plan looked much the same: connect a frontier model to the filings, the shared drive and the research inbox, then build the workflows in-house.

Fall 2026: “What should we build, and what should we buy?” Since September the conversations have sounded different. Firms now arrive partway through a build. They want to keep their own AI workflows and their own agents, and what they are looking for is the layer underneath. The technology lead at one investment bank told us they had considered standing up a search index for research, another for deals and so on, and decided it wasn’t worth the effort. His comparison was the CRM, which no bank would now think of building for itself.

“Nobody here would build their own CRM. Once we looked at it like that, the question became whether this is where we want to spend our time.”

— Technology Lead, Investment Bank

That third version is the right question. Answering it properly means starting with the people who want to build, because at the top of the stack they have a point.

The case for building has never been better

Firms of every size can now build things that would have needed a dedicated team two years ago.

At a fund with no engineers at all, an analyst who has never written a line of code can build an earnings-prep workflow in Claude over a weekend: a reusable set of instructions that reads the transcript, pulls out the changes in guidance and drafts the note in the house template. At a fund with a handful of engineers, the same weekend goes further. On Friday an engineer connects EDGAR, the shared drive and the research inbox, on Saturday a coding assistant writes most of an earnings-preview agent, and on Sunday evening the team watches a demo that handles its first ten questions well. At firms with large engineering teams, the range of what is possible is striking. One private equity firm we know has hundreds of people building internal tools with Claude Code, and their lead told us the technical barriers were now close to zero.

All of this sits at the top of the stack: the screens, the earnings prep, the IC memo in your format, the agent that knows which three questions your PM always asks. It encodes how your firm invests, it is now cheap to build, and it is just as cheap to change. When the PM decides the preview should open with the margin bridge, your own team can change it on Monday morning.

“Our analysts built an earnings-prep agent in an afternoon, and it’s the most-used thing we’ve shipped all year. I just wouldn’t let anyone put its numbers in a memo.”

— COO, Multi-Strat Hedge Fund

The same logic makes buying the top of the stack the weakest choice on offer. Each model release absorbs another thin AI product into the model itself. Chatting with a handful of filings, AI search and packaged investment workflows were all sold as products two years ago, and today most of them come with the model. A vendor’s generic earnings workflow is, at best, a slightly worse version of one your team could build this week, designed around somebody else’s idea of how to invest.

Monday morning

The weekend build usually meets reality the following week, when someone asks a harder question than the demo did. The failures are remarkably consistent from firm to firm:

• The wrong period. Fiscal Q3 is not calendar Q3, and the model quietly picks one.
• A stale number. Last year’s figures were restated in this year’s 10-K, and the model quotes the original.
• No source. The PM asks where a figure came from, and nobody can say.
• Two answers. The same question on Monday and Tuesday produces two different totals.

Private markets have their own versions. The capital account statement doesn’t tie to the GP’s quarterly letter, “Fund IV LP” and “Fund IV-A” turn out to be different vehicles, and the unfunded commitment the model reports is two quarters out of date.

“The letter said one thing and the capital account statement said another, and it just went with whichever document it read first.”

— Head of Operations, Asset Manager

We once asked a frontier model where the share counts in a dilution model it had just built from a 10-K had come from. The model had looked perfect. Its reply was “Honestly, I estimated those.”

Better tooling fixes some of this. A harness that does its arithmetic in code gets the sums right, but it can’t tell whether it was handed the right inputs. It is also tempting to assume the next model will fix the rest. Models will keep improving, but several of these problems don’t go away with scale, and they can only be solved underneath the model, in the part of the stack that never appears in a demo.

Most of the stack is hidden

A demo shows two layers, the workflow and the model, and a system people can rely on needs a good deal more underneath them. Every source has to be connected, with its permissions intact, and kept in sync. Every filing, transcript, deck, fund document and spreadsheet has to be read in full, scanned PDFs and footnotes included. Every company, security, fund and vehicle has to be resolved to a single record across systems that disagree about names. Your definitions have to be written into an ontology, a map of your firm’s entities, terms and relationships that the system applies the same way every time. Restatements have to be tracked so a figure means what it meant on the day you used it. And every number has to be pulled and computed by code, with a citation back to the line it came from.

Each of those is a hard problem in its own right, and three from our own work give a sense of the scale. In a random sample of 200 companies, 194 had changed the shape of a financial statement at least once, so following a company’s reported line items across years quietly breaks (Reclassified to Conform). Across a typical fund’s own systems (its CRM, fund documents and portfolio reports), about 60% of names failed to match before entity resolution. And having a frontier model read a 10-K in full costs about $34 each time, so most builds fall back on retrieving a few paragraphs per question, which is where the wrong-period and stale-number errors tend to come from. Reading every document once, properly, and keeping what it says costs about 5 cents (Stop Paying to Forget).

None of it is ever finished, either. New sources arrive, data vendors change their formats, companies restate, and a new model ships most months, each time requiring the evals to be rerun and the prompts retuned. We sometimes ask managers whether they would like to spend a day of every week deciding whether to switch to the latest Claude or the latest GPT, and we have yet to meet one who would.

“If we can’t verify every source and every number coming through, the whole thing dies before it starts.”

— Head of AI, Global Asset Manager

The test: would every firm build it the same way?

Jack Woodruff was a partner and portfolio manager at Surveyor Capital, a division of Citadel, before founding Candlestick Capital. On stage at AI Engineer NYC last month he described where returns come from, and it is a description AI leaves untouched.

“There’s always been alpha creation by finding a divergent view.”

— Jack Woodruff, Founder, Candlestick Capital

If alpha comes from a divergent view, then the useful question to ask of any piece of your AI stack is whether it helps you hold a view nobody else holds, or whether it is something every firm needs to get right in exactly the same way. Three tests settle most cases.

Is there one right answer? A company’s revenue for a quarter, as restated, has one right answer. So does the question of whether two entries in your systems refer to the same issuer or the same fund, and so does the page a number came from. Where there is one right answer, getting it right earns you nothing, since every competitor is working toward the same answer, while getting it wrong costs you a bad memo, an afternoon of re-checking, or a PM who quietly stops using the tool. Edge lives where good investors disagree: what the quarter means, whether management can be believed, which manager to back, what to own and how much of it.

Would your competitors build it the same way? If you and the fund down the street each built a 10-K parser, you would both be building the same thing to the same specification, and neither parser would have anything to say about markets. Your screen has a point of view. So does your IC memo template, and so do the questions your agents ask.

Who benefits when it gets better? When your team improves your earnings-prep agent, only you benefit. When someone improves the way restatements are handled, every firm relying on that work benefits, and the work costs the same whether one firm pays for it or fifty share it. Building it yourself means paying the whole bill alone to arrive where everyone else already is.

There is one subtlety, and it is where most build plans go wrong. Some of what lives in the data layer really is yours. Your definition of adjusted EBITDA, your peer sets, how you handle a fiscal calendar, whether you backtest on figures as first reported or as restated, which entities your credit team treats as a single obligor: these are choices, and different firms make them differently.

Your proprietary data is yours too, from CRM notes and expert-call libraries to, at a bank, the private-company data its bankers have collected over decades. Some of it is genuine edge, and none of it should ever become anyone else’s. The machinery that stores your definitions and data, applies them consistently and cites them back is another matter. Once a definition is set, applying it correctly to every document is the same work at every firm, and it is what most build plans spend their first two years on.

Layer	What makes it hard	One right answer?	Verdict
Connecting and syncing your sources	Dozens of sources, each with its own access rules, formats and failures	Yes	Buy
Reading documents and extracting facts	Scanned PDFs, multi-page tables and footnotes, where one misread cell changes the answer	Yes	Buy
Matching companies, securities and funds across systems	Names, tickers and fund vehicles change, and every system spells them differently	Yes, once your definitions are set	Buy
Tracking restatements and point-in-time data	Keeping every version of a number, and knowing which one was known when	Yes	Buy
Pulling, computing and citing every number	Running every calculation in code and tracing each input back to its page	Yes	Buy
Your definitions and your proprietary data	Writing down choices that today live in analysts’ heads and spreadsheets	No	Yours, plugged into the layer you buy
Research agents, screens and workflows	Knowing what your PMs actually want, and keeping up as that changes	No	Build
The investment decision	Holding a view the market doesn’t share yet	No	Yours, always

In short, anything with one right answer is the same at every firm, so buy it and make sure it is right. Anything where good investors disagree is yours to build. Your data and your definitions sit in between: they plug into the layer you buy, and they stay yours throughout.

Jack had a phrase for what happens to work that every firm ends up doing.

“When everybody’s doing all the exact same things, that just becomes the table stakes.”

— Jack Woodruff, Founder, Candlestick Capital

What building it actually costs

The cost varies so much between firms that any single figure would mislead. At a small fund it might be a few engineers for two years, and at a global bank it can run to thousands of people and billions of dollars.

What is consistent is where the cost shows up. Engineers who are good at document parsing and entity resolution are scarce, and finance is rarely their first choice of employer. A demo takes a weekend, but a data layer a PM will trust with numbers tends to take 18 to 24 months. The upkeep never falls to zero. And the biggest cost is one nobody budgets for: the workflows your engineers didn’t build while they were working on plumbing.

Earlier this year we heard about an allocator with more than $20 billion under management that had put several engineers on its own data layer. Two years and several million dollars later, the verdict was that “it barely works.” For our part, the same layer has taken 17 months, 109 platform releases and a test set of more than 27,700 hand-labeled facts, and our team came to it with decades of experience building platforms like it.

“We spent eighteen months on the data platform. Then a new model came out, and we spent another three fixing what broke.”

— CTO, Asset Manager

Most firms could build it, given enough engineers and enough time. Whether they should is a very different question.

It depends what kind of shop you run

The line between build and buy moves with the size of a firm and the kind of investing it does. Many firms we talk to have a handful of engineers rather than hundreds, and even those with hundreds want them on whatever sets the firm apart. In every case but one, the line stays above the data layer.

Firm	Build	Buy the data layer for
Allocators, endowments and other LPsAI team: usually none	Manager-selection workflows, IC packs	Fund documents, capital account statements, LP reports
Fundamental long/short and long-onlyAI team: one lead	Earnings prep, screens, thesis tracking	Filings, transcripts, research notes
Private creditAI team: a handful	Credit memos, covenant tracking	Credit agreements, amendments, compliance certificates
Private equityAI team: a handful	Deal screens, IC memos, value-creation plans	Data rooms, CIMs, portfolio reports
Multi-manager platformsAI team: large, with a central data team	Agents and research tools for each pod	Every pod, from one shared layer
BanksAI team: large, behind information barriers	Banker and research agents, pitch workflows	Every desk, inside the information barriers
Quant fundsAI team: large, and data is the product	Nearly everything	Documents outside the signal, if anything

Firms with no engineers. For most allocators, family offices and smaller funds, building the data layer was never really on the table, and the more natural question is why ChatGPT isn’t enough. It handles a single document well. It struggles with the questions allocators actually ask, such as which of our funds hold a given company or what our unfunded commitments look like by vintage, because the answers sit across hundreds of capital account statements, letters and LP reports, a few of which disagree with each other. The risk at this size is buying a thin wrapper that the next model makes redundant. The better route is to buy the data layer, keep the documents in your own environment so GP confidentiality terms are respected, and build light workflows on top, with answers landing in the Excel models your team already uses and every cell cited. Our engineers help get the first ones running.

Firms with a handful of engineers. Approaches vary most in this group. A typical firm has a few billion dollars under management, an AI lead or a team of two to five, and a long list of workflows the investment team would like by next week. If that team builds the data layer, it spends two years on plumbing and may never reach the workflows. If it buys the data layer, it can start on the workflows in the first month.

“I’m the AI team. I spent most of the summer writing PDF parsers, which is not what they hired me for.”

— Head of AI, Long-Only Equity Fund

Firms with large engineering teams. Multi-manager platforms and big banks can build almost anything they choose to, and JPMorgan alone spends around $18 billion a year on technology. For them the real question is where an engineer’s hour is worth most, and the answer is nearly always signals, risk, execution and the tools investment teams use every day. A firm this size usually has a central data team and a security master already, and whatever data layer it buys should plug into both and respect the information barriers between teams. Where there is no central team, size brings its own trap: desks and departments each quietly building their own version of the same document pipeline.

“Could we build this ourselves? Probably. But why would we?”

— Head of Software and Data Engineering, Investment Bank

Quant funds. If the way you clean and join data is the signal, then the data layer is your edge and you should build it, as most quant funds already do.

The oldest question in business

Take the AI out of it and this is a question every firm already answers: what is this firm actually for?

Finance settled it long ago for most of its infrastructure. Funds use a fund administrator, a prime broker, a market data terminal, an order management system and a CRM, often the same ones their competitors use. Nobody believes a fund surrendered its edge by sharing an administrator with the fund across the street, or that a PM’s returns come from the terminal on the desk. The edge has always been in what a firm does with the infrastructure everyone shares. Geoffrey Moore described this as the difference between core and context: core is whatever sets a company apart, context is everything else that still has to be done well, and the danger is letting context swallow the people who should be working on the core.

The strongest case on the other side came from Joel Spolsky, in a 2001 essay defending companies that insist on building their own tools: “If it’s a core business function – do it yourself, no matter what.” We agree with him entirely, and the whole argument turns on which part is core. For an investment firm, the core is the divergent view and everything that helps you reach it. Parsing a 10-K is context.

The objections, answered

The obvious objection is that we would say all this, since we sell the layer we are telling you to buy. That’s fair, and it is why the objections we hear most often deserve straight answers.

“Claude or ChatGPT already does this on our drive.” For a single document, they do a fine job. Ask the same numerical question three times and compare the answers, then try a question that spans ten years of your own documents, which won’t fit in a context window however large they grow.

“It’s great on one document. Ask it something across the whole portfolio and it’s guessing, and it doesn’t tell you it’s guessing.”

— CTO, Credit Manager

“We already license data and research tools.” You should keep them. Market data, estimates and research platforms are sources, and a good data layer connects to the ones you already pay for. What those tools don’t do is join your licensed data with public filings and your own documents, resolve all of it to your entities, apply your definitions and cite each number back to where it came from. That joining is the layer we mean.

“Models will get good enough that none of this matters.” They will keep getting better, and they will stay probabilistic, so you still won’t be able to prove a number without redoing the work, and they still won’t know your firm’s data, definitions or relationships. Jack Woodruff put the practical version well: people ask Claude to build a model, and “they still have to go through and audit the numbers.” Model churn used to count against buying, since any vendor you chose might be obsolete within a year. Today the part that changes every few months is the model itself, which is exactly why the layer underneath it needs to stay put.

“A good search index is enough.” An index can find the right paragraph. It doesn’t know that the figure inside it is in thousands, belongs to fiscal Q3 and was restated a year later, or that two documents describe the same company under different names. Those facts have to be extracted, with their units, periods and entities, before anyone asks, and that is the work most indexes skip.

“Our data is too sensitive to send anywhere.” A good platform should deploy in your environment with permissions and information barriers that follow your source systems.

“The data layer is our moat.” If the data is proprietary, it may well be, and it stays yours. The processing that makes it usable is the same at every firm, and building it yourself means paying alone for what everyone needs.

Where this leaves you, and where we sit

The top of the stack, the agents and workflows that encode how you invest, is now cheap to build, easy to change and the only part that can carry your edge, so it should be yours. Underneath it sits a data layer that is hard to build, never finished and, once your definitions are set, the same at every firm. Everything you build stands on that layer, which is why it comes first: buy what every firm needs, then build your edge on top of it.

That layer is the only thing we work on. Our team built it once before, at Palantir, and has spent the last 17 months building it again for investment firms. Our engineers deploy on your data, connect your sources and build your ontology with you. Your team builds agents and workflows on top, and your engineers can add their own entities, metrics and rules as they go while we run and maintain the pipelines underneath. Because the hard problems are the same at every firm, each one we solve, whether a new filing format, a vendor’s schema change or the next model release, reaches every firm we work with, and it is a large part of why first workflows usually go live within a couple of weeks.

Not every firm has engineers to build the top of the stack, and that shouldn’t stop a smaller shop from getting the same results. For firms with no engineers, or one, our engineers go further up the stack. They sit with the investment team, build the first workflows with them in their own templates, and hand them over in a form analysts can change themselves. The workflows still belong to you; we help get the first ones built.

On stage at AI Engineer NYC, the question was whether every hedge fund will become a tech company. At the top of the stack, we think most will, in the sense that their engineers will turn the investment process into software and change it every week. Underneath, they will run on the same data layer as everyone else, which is how finance has always treated the infrastructure every firm shares.

If you’re partway through a build, or deciding whether to start one, we’d be glad to compare notes. Talk to us

FAQ

Should a hedge fund build its own AI? Build the agents and workflows that encode how you invest. Buy the data layer underneath them (document processing, entity resolution, point-in-time data and cited calculations), because it is the same at every firm. The exception is a quant fund whose data processing is itself the signal.

What parts of the AI stack should an investment firm build, and what should it buy? Buy the layers with one right answer that every firm needs: connecting sources, reading documents, resolving entities, handling restatements, and computing and citing numbers. Build the layers where firms disagree: research agents, screens, workflows and outputs in your format. Your data and definitions stay yours either way.

Does this apply to allocators and family offices with no engineers? Yes, and the data layer matters even more, because fund documents, capital account statements and LP reports rarely agree on names or dates. Buy the layer, keep the documents in your own environment, and build light workflows on top, with help from the vendor’s engineers to get the first ones running.

How much does it cost to build an AI data layer in-house? It ranges from a few engineers over roughly two years at a small fund to programs of thousands of people at large banks. The main costs are specialist engineers, 18 to 24 months before a data layer a PM will trust with numbers, upkeep that never ends as sources and models change, and the workflows your team didn’t build in the meantime.

Why do in-house AI builds at investment firms stall? The first version covers the workflow and the model, which is the part a demo shows. Production fails underneath: wrong fiscal periods, restated numbers, names that don’t match across systems, figures with no source, and answers that change between runs.

Can’t we just use ChatGPT or Claude Enterprise on our own data? For individual documents, yes. At the scale of a firm’s data, numbers need to be retrieved and computed by code, resolved to your entities and cited to their source. You can keep using your assistant on top of a data layer through MCP.

What is an ontology, and why does an AI system need one? An ontology is a structured map of your firm’s entities, definitions and relationships, so every company, fund and document resolves to one record and every term carries one definition. Without one, a model guesses which “Q3” or which “adjusted EBITDA” you meant.