The Engineering Challenges Behind Institutional AI

Institutional-grade financial AI is hard for five specific reasons: the data is messy and unit-sensitive, history gets quietly rewritten, every number has to be traceable to a source, forecasts have to be reproducible, and all of it has to hold across hundreds of companies rather than one demo. None of these are model problems. They are engineering and discipline problems, and they are the difference between a tool that impresses in a demo and one a professional can actually rely on.

This is the overview. Each challenge below is a principle, not a build. Where a challenge deserves its own treatment, there is a deeper post linked. If you want the honest short version of the whole thing: the model is the easy part.

Challenge one: the data is dirtier than it looks

A company filing looks like a clean table. It is not. The same line item is labelled differently across filers and across years. Numbers arrive in different units, some in absolute rupees and some in crore. A profit line in one company’s statement can mean something slightly different in another’s. A model reading the page faithfully will extract exactly what is printed, which is sometimes exactly wrong.

The principle here is that a better model does not fix a broken data contract. If a value is off by a factor of a hundred because of a units mismatch, no amount of clever prompting corrects it. Deterministic cleanup does. This is why data quality beats model quality more often than people expect, and why the unglamorous work of normalising units and reconciling labels tends to remove whole categories of error at once.

The deeper version of this problem, understanding a financial statement as structured accounting rather than prose, is its own subject. A statement is bound by identities: the balance sheet has to balance, cash flow has to reconcile to the movement in cash, the segments have to add to the total. Real understanding means respecting those identities and checking one statement against another. That is covered in building an AI that understands financial statements.

Challenge two: history does not stay still

This is the one most people underestimate. When a company reports a quarter, it often restates the prior-year comparable at the same time, because of an accounting change, a demerger, a discontinued operation, or a redefinition of segments. So the history you can pull today is not always the history that was knowable on the date a decision was actually made.

That matters enormously for anyone testing an idea or measuring a track record. If you run a strategy over “the numbers as they read today”, you may be quietly feeding it information that did not exist at the time. The results look better than they could ever have been in practice. This is a form of lookahead bias, and it is easy to fall into without noticing.

The principle is point-in-time correctness: every number should carry the date it was first known, and a later revision should never silently overwrite what was visible earlier. You keep both the original and the restatement, tagged by date, and you always ask “what was knowable then” rather than “what do we know now”. Why point-in-time data matters goes into this properly. The harder engineering question, how to structure decades of inconsistent filings so software and models can use them without tripping over restatements and format changes, is its own piece: structuring decades of filings for LLMs.

Challenge three: every number needs a source

In casual use, an AI that is usually right is good enough. In finance it is not, because the cost of a confident wrong number is high and the error is often invisible until it has already fed a decision. A figure that looks reasonable but was never in any filing is more dangerous than a blank, because it does not invite the double-check that a blank would.

The principle is simple to state and hard to hold to: every number an AI reports about a company should link back to the exact source document and line it came from. Not a general reference to “the annual report”, but the specific place, so a human can open it and verify in seconds. Source-linked answers turn the AI from something you have to trust into something you can check. That is the whole argument in why citations are non-negotiable in financial AI.

Citations also change behaviour upstream. If the system has to point at a source for every figure, it cannot invent one, which quietly rules out a large class of the fabricated-number failures that plague general models on financial questions.

Challenge four: forecasts have to be reproducible

Ask a language model to forecast a company’s next year and it will give you a fluent, confident answer. Ask it the same question twice and you may get two different answers, with no clear account of what changed. For thinking out loud, that is fine. For allocating capital, it is not, because a forecast you cannot reproduce or audit is not really a forecast. It is a guess with good grammar.

The principle is determinism where it counts. A forecast should come from an explicit method: decompose the business into its drivers, state the assumptions, and let the number fall out of the arithmetic. Then anyone can see why the answer is what it is, change one assumption, and watch the result move in a way that makes sense. The reasoning can be assisted; the output should be reconstructable from stated inputs.

This is not anti-AI. It is about putting the model where its judgement helps, in reading and structuring and reasoning, and keeping the final number on an auditable rail. The full argument, including the honest trade-off between reasoning quality and reproducibility, is in why deterministic forecasting beats LLM guesses. It builds directly on how professionals actually forecast revenue before an earnings print.

Challenge five: it has to hold at scale

Any of the above can be made to work for one company on a good day. The real challenge is holding all of it across a wide universe of names, quarter after quarter, without a human babysitting each one. The edge cases multiply. A bank’s statements do not look like a manufacturer’s. An oil marketer reports revenue in a way that needs care. A company that demerged three years ago has a broken history that has to be stitched back together correctly.

The principle is that reliability at scale is an engineering property, not a model property. It comes from handling the awkward cases explicitly rather than hoping the model muddles through, and from checks that catch a bad number before it reaches a person. The failures that matter are rarely dramatic. They are a single unit slip or a stale restatement in one row among thousands, which is exactly why systematic handling beats manual vigilance.

Why these five compound

The uncomfortable part is that these challenges are not independent. A clean number with no source cannot be trusted. A well-sourced number on restated history is still misleading. A reproducible forecast built on dirty inputs is reproducibly wrong. You do not get to solve one and move on; they reinforce each other, and a weakness in any one leaks into the rest.

That is why building financial AI that a professional will actually lean on is less about a cleverer model and more about a stack of unglamorous disciplines that all have to hold at once. The Altys stance across the series is consistent: describe the problem plainly, respect the accounting, keep the human able to check the work, and never dress a guess up as a fact.

The model is the last ten percent. The trust is the other ninety.

If there is a single takeaway, it is that “impressive in a demo” and “reliable for a decision” are different products with different bars. The gap between them is not intelligence. It is the boring engineering that most of the world skips, and it is exactly the part that decides whether the output is worth building on.