Why the standard AI playbook doesn’t work for investment data
By Bharath Reddy, AI Lead, FINBOURNE
Your AI can’t answer portfolio questions, and it’s not the model’s fault
Most AI projects in financial services start by pointing a language model at internal data and expecting the magic of ChatGPT to follow. It rarely does, and the reason isn’t the model. The patterns that made retrieval-based AI feel magical on the open web were designed for documents and generic tables. Investment data is neither.
Why RAG can’t see a portfolio
RAG is the most common pattern in enterprise AI. The idea is simple. You take your documents, reports, spreadsheets, trade records, and index them. When a user asks a question, the system searches that index for the passages that look most relevant, hands them to the AI model, and asks it to write an answer using those passages as context.
It works well for customer support, internal knowledge bases, and document-heavy domains like legal or HR. If the answer lives in a paragraph somewhere, RAG will probably find it.
But investment data isn’t paragraphs. A portfolio isn’t a document you can search for the word “exposure.” A position isn’t a sentence. The answer to “what’s my NAV as of this morning” doesn’t exist in any single retrievable chunk. It’s a calculation over live holdings, prices, corporate actions, and fund hierarchies that has to be performed, not found.
When you ask RAG “what’s my look-through exposure to a single issuer across our funds?”, it searches for things that look relevant. It might surface a press release about Apple, a trade ticket from last quarter, or a memo about the tech sector. All three are plausibly related. None of them answer the question. The model writes a confident-sounding answer anyway.
RAG cannot reliably tell the difference between:
– a trade and a position;
– yesterday’s data and today’s;
– a fund and its parent;
– an issuer and an ultimate parent;
– or a valuation as of one date and a valuation as of another.
Those distinctions are the whole point of investment operations. A system that flattens them isn’t wrong occasionally. It’s wrong structurally.
The obvious rebuttal is that modern RAG is more sophisticated than simple document search. That’s true. Teams add filters, structured retrieval, reranking and other refinements, and they all help. But they’re all improvements to searching, and searching is the wrong starting point for this kind of data. No amount of better searching turns a question like “what’s my NAV this morning” into an answer, because the answer has to be calculated over live data. Retrieving better passages doesn’t close that gap.
Why text-to-SQL can’t be trusted
The second popular pattern skips the search step entirely. Instead of finding documents, the AI writes a database query. You ask in English, the model generates SQL, the SQL runs against your data warehouse, and the answer comes back.
This sounds better, and in some ways it is. You’re working with live data, not a stale index. The AI isn’t pattern-matching against prose; it’s computing on structured fields.
But now the AI has to understand your schema. Which table holds positions? How do trades aggregate to holdings? What does the “as_of_date” field mean in your particular warehouse? How are tax lots represented? Does “counterparty” mean the trading counterparty or the settlement counterparty? Is a fund-of-funds position stored flat or with look-through?
These aren’t obscure technical questions. They’re the decisions your data engineers made over years, encoded in hundreds of tables, thousands of columns, and dozens of join patterns that aren’t documented anywhere a language model can read. When the model guesses wrong, and it will, the answer looks authoritative and is wrong.
The audit story compounds the problem. The AI is generating queries that hit your production systems, and those queries change every time. A regulator asking how a number was produced six months ago needs to see the exact SQL, an explanation of why the model phrased it that way, and confirmation that no semantically wrong join slipped past review.
“The AI wrote some SQL” is not a satisfying answer in a regulated context.
And there’s no reusable layer of understanding. Every new workflow requires the AI to re-learn your schema from scratch.
The same mistake, different shape
Both approaches share the same underlying mistake. They treat financial data like any other data. RAG treats it like documents. Text-to-SQL treats it like generic tables. This is also why generic AI assistants and copilots, which are built on these same patterns, struggle the moment they’re pointed at a portfolio or a position. Neither understands the things a practitioner takes for granted: what an instrument is, how positions aggregate across tax lots and venues, why a fund hierarchy matters for exposure, what “as of today” actually means when corporate actions are pending.
Financial data isn’t just structured. It has meaning. Meaning that determines which answer is correct, and meaning that generic patterns can’t infer from the data alone.
The shape of a system that fits the data
The alternative is to put a layer between the AI and the data that already understands financial concepts as financial concepts. Not a search index over documents. Not a raw schema. A domain model where instruments, portfolios, positions, valuations, corporate actions, and fund hierarchies are first-class objects, with their own behaviour and rules, rather than patterns the AI has to reverse-engineer from generic tables every time.
This isn’t a design choice you can make in a quarter.
This is where the work is, and this is where most teams stop short. Wiring an LLM up to call functions is a weekend project; the tool-calling patterns are well understood, MCP and function-calling APIs are standardised, and every framework supports them. That’s the easy part. The hard part — the part that takes a decade, not a quarter — is what those functions sit on top of. Modelling “what is a position?” correctly across equities, fixed income, derivatives, and private assets, with tax lots, multiple venues, and corporate-action history, is years of work. Doing it across jurisdictions, accounting bases, and bitemporality is years more. There are no shortcuts, and there is no model clever enough to infer it from a schema at runtime.
Without that domain model, function-calling is just text-to-SQL with extra steps. The AI is still guessing at meaning — it’s just guessing at the meaning of your function names instead of your column names.
In this model, the AI doesn’t search, and it doesn’t write database queries. It calls a pre-defined set of functions, APIs that encapsulate the hard parts:
– Get positions for this portfolio, as of this date, with look-through.
– Calculate the NAV for this fund between these two dates.
– Return the exposure to this issuer across all holdings, including indirect exposure through held funds.
Each of these functions knows what a position is, how to aggregate it correctly, and which data sources are authoritative for which field. The AI’s job is to pick the right function and interpret the result — a bounded problem, because the hard reasoning has already been done inside the function.
Answers are based on live state, not a stale index. Every AI action is auditable at the function-call level: you know exactly which function was called, with which parameters, and why. New workflows don’t require new engineering, because the functions already exist; the AI simply composes them differently.
Most importantly for any regulated firm, the same entitlements that govern your users govern the AI, because it’s accessing the same functions through the same controls. There’s no parallel access path for the model to take, no separate permissions model to maintain, and no risk of the AI surfacing data a user wouldn’t be allowed to see directly. For compliance and risk teams, this is the difference between a technology they can sign off on and one they can’t.
None of this means RAG has no place. For genuinely document-shaped problems, research notes, policy documents, Investment Memoranda, board packs, RAG is still the right tool. The point is that investment data isn’t document-shaped, and treating it as if it were is where most projects come unstuck.
Where this leaves us
RAG and text-to-SQL aren’t bad technology. They’re solving a different problem, one where the data is text or generic tables, and where the cost of a wrong answer is an inconvenience, not a misstated NAV or a missed covenant breach.
Investment operations need something different. A layer that encodes the meaning of financial data, so the AI can reason over it without rediscovering that meaning every time. That’s not a wrapper around a database. It’s a different shape of system entirely, built for the kind of data it’s serving.
At FINBOURNE, this is what we’ve built. Our platform exposes a governed library of financial functions over live positions, valuations, and portfolios that AI agents call directly. The same functions your teams use, with the same entitlements, and every call fully logged for your auditors and regulators.
If you’re evaluating AI for your investment workflows, the question isn’t “which model?” It’s “what sits between the model and your data?” Without that layer, even the best model is reasoning in the dark. That’s the foundation everything else depends on.
