A modular paradigm for financial modelling

Thoughts on moving to a better modelling paradigm in the world of LLMs and how financial modelling jobs might change

Essay · 26 Aug 2026 · John Yeldham

Being a financial modeller

During my 20 years as a financial modeller I have been both frustrated and content at the sheer relentless amount of detailed work needed to build a financial model. Frustrated by the repetition, the constant checking, the lack of systems that can organise all of this and the difficulty of non-modellers to understand what was made - even though the model was made for them. Content because all of these issues mean that financial modellers are highly specialised experts who a jack of all trades and a master of some. That expertise comes at a price, and that price has been my income and the income of all other financial modellers!

Entering into the new world of AI is a good time to reflect on where we are as an industry. Not only can it affect the value of human financial modellers but I believe its capabilities should fundamentally change the way that financial modellers operate.

Making financial models: quickly, cheaply, and well

Efforts have been made in the past to find ways to make models quickly, usually revolving around a way to modularise a financial model, so that financial model building is no longer a line by line construction, but an assembly of parts - “modules”. But those methods - up to now - have been understandably steeped in the way financial models have been built up to now.

Models have been built by financial modellers, with all their expertise, but have been structured in a way to make the building as easy and error free as possible. Because financial models are such risky things, the efficacy of building has come first, before things like user-friendliness or communication. By following suit, modular systems have embedded all the detail of current financial models in how they construct modules, and as a result they are very specific, very detailed, and have very complicated interfaces with other modules in the model. Financial modelling is very bespoke, so if you want a modular system based on specific, detailed spreadsheet level interfaces (encoded into a spreadsheet), you will need an almost unending number of variations to cope with all the variations of logic and data structures that are modelled in the real world.

My answer to this is not to define modules within spreadsheets at all. Instead, modules should be defined as simple paragraphs describing the business sense of what the module does. It is much easier to reflect differences between business logic and business data structures at the level of words than in a detailed spreadsheet (which forces you to make spreadsheet structure decisions that simply are not relevant at the language and business level). Furthermore, in the new world, it now opens the door to AI reading and writing modules trivially, without complicated spreadsheet apps acting as a go-between. LLMs are already brilliant at writing words with meaning.

What is spreadsheet modelling for anyway?

It isn’t just a shift to words however: it is also a shift from designing modules according to structure to designing modules according to purpose. There are two key purposes that define the modules I am proposing:

The latter point is actually one of the main reasons that people like financial models to be done in spreadsheets rather than, say, Python code: they can “read” the model. In that sense the “outputs” of the model are really the entire model, since all of it is read, not just the final output statistics (like project IRR, for instance).

A new modularity

More formally, my approach defines two terms, in a way that makes sense for financial modelling specifically:

  1. A module is a bounded part of a system. It contains workings that hold, communicate or develop information and may exchange information across its boundary.
  2. An Articulate Referent Module, or ARM, is a module whose referent is a recognisable real-world concept, including the behaviour and logic attributed to it. Its workings articulate that representation as an intelligible journey.

These are rather technical sounding, but encapsulate the key points in concise terms.

So how does this look in practice?

One benefit of defining these modules like we have is that they can speak to financial experts who are not modelling experts. It completely side-steps the issue of financial modellers and financial experts speaking a different language, which from experience is much, much more common than you might think. Now the modules can be designed to speak domain expert language.

Design-wise, I would split up the model into modules (ARMs) where each module corresponds to a particular domain expert or team. Now we have a system where non-modellers can talk to an LLM - or just write words themselves - to develop their own module that perfectly aligns with the logic of the business they are dealing with. For instance, a debt team can build up the module in words that describes the contractual debt mechanics. They can analyse contracts (again, LLMs can help here) and extract the underlying semantics and express this in words. They would need to be mindful of defining the components needed for module: inputs, outputs, logic - but again the LLM can talk to the domain experts to make sure the resulting module is comprehensive in all the ways it needs to be.

The model modeller

So what does that mean for financial modellers? It is interesting that this flips on the head the most common view on how financial modelling will change in future. Most surveys show modellers expect that AI will take over the rote, mechanical and detailed work of building the model in the spreadsheet, and the human modellers will retain the job of understanding specification and scope. My proposal flips this: the LLMs are actually the main agent for gathering detailed requirements, and humans are responsible for leading the design of modules at a spreadsheet level. It makes a lot of sense that LLMs - which are great at gathering semantic detail through conversations - actually have those conversations.

Of course, I have generalised in my statement and it is more subtle than that, but the direction of travel is quite different to what most people are expecting. In fact we can break down the roles further, if we want to be a little more balanced about it:

  1. Modelling project co-ordinator - who manages the disparate ideas and connects the relevant human teams - will be either a financial modeller or a project manager. LLMs are currently not good at managing a team of humans!
  2. Business domain specification will come from conversations between LLMs and business domain experts. No need for a modeller, other than they ensure the right LLM framework has been set up - but that is a one-off task.
  3. AI can assemble a model from a library of module designs and connectors (to join modules together), with a human helping (or collaborating) to apply specific tailoring along the way to perfectly match the specification.
  4. Spreadsheet-level design libraries will be led by humans. LLMs just copy humans so it falls to humans to innovate and build the best spreadsheets to fit business needs. Things like dynamic arrays and LAMBDAs in Excel have opened the door to new ways of doing things, and LLMs cannot lead that change.

Notice how there is hardly any need for a financial modeller in the above.

  1. A project manager does not need to be a financial modeller. They just need to understand which business domains are relevant to a modelling project, create project plans based around those domains, and then manage those teams and LLMs. Understanding business domains is something a business consultant does just as well as a financial modeller. Project management is something a project manager does better than a financial modeller.
  2. Once the LLM is set up (probably by the project manager), there is no need for a financial modeller in the business domain conversations. Business domain experts understand their domain better than a financial modeller does (who is necessarily a generalist).
  3. There is a need for a financial modeller to apply the tailoring to meet specific requirements, even thought the LLM can do the underlying leg work of creating the first assembled models. This is definitely bit where the financial modeller is doing the 80% of the work which completes the final 20% of the specification.
  4. Finally: design - and this is one where financial modellers lead. But - bad news for financial modellers - there only needs to be a handful of financial modellers that lead best practice for design of financial models in spreadsheets. Everyone else uses there best-in-class modules and ideas. Great for the hardcode experts, bad for “learn and earn” financial modellers. You can see this in IT development - the very best experts still command a premium but regular programmers are no longer in demand.

What next?

I have not commented on model review or other parts of financial modelling, like maintenance. I am focussing on building the models here. There is much to say about those, but that is for others. In my opinion, model audit teams are well ahead of model build teams in their thinking about AI, because firstly they need to think seriously about how AI changes risk in practice, as they are signing off that risk, and secondly implementing AI in a model build process is just a harder problem to crack than augmenting model review with AI.

For me, the next step is to use the ARM framework in practice. The good news is because the modules are at language level it is easy to set up the LLM system using current capabilities. No big new Excel or spreadsheet system needed. Just a few agents and skills will be of practical benefit. Watch this space!

← Back to Writing