Build vs buy after the cost collapse

The old equilibrium

For as long as I have worked in life and health modelling — some twenty years now — the build-versus-buy question has had a settled answer. Insurers buy. They buy Prophet, or AXIS, or RAFM, and they configure. The received explanation is functional: the commercial suites are broader, better tested and better supported than anything an in-house team could produce. Having spent six years inside FIS working on Prophet itself, and having since led migrations onto it from AXIS, from RAFM and from a specialist long-term care platform, for insurers in the UK, Europe, the United States and Asia, I think the received explanation is incomplete. The suites are good. But that is not chiefly why insurers buy them.

Insurers buy them because a commercial platform is defensible. When hundreds of insurers run the same engine, its model risk is, in a practical sense, shared. The auditor has seen the platform before. The regulator has seen it before. The committee approving its use is following the market, not leading it, and a defect discovered in a widely used engine is an industry event rather than a personal one. The chief actuary who standardises on the market’s platform purchases, along with the software, an institutional shelter. That shelter — not the feature list — was always the real product. And for most of my career it was correctly priced, because the alternative, building, carried a cost measured in vendor-team-years that no single insurer could rationally bear.

What changed

That build cost has now collapsed, and I want to be precise about the claim, because this site makes it nowhere else. Agentic AI systems — models that write, test and revise code under a domain expert’s direction — have changed the production function of quantitative software. The scarce input is no longer engineering hours. It is the judgement to specify what an engine must do, to recognise when its output is wrong, and to know in advance what evidence a validator will demand. An actuary who has that judgement can now direct the construction of software that previously required a vendor team and a multi-year roadmap.

I offer a worked example rather than an assertion. In evenings and weekends, working alone, I built the Gnanam ESG: an economic scenario generator comprising seven models — Hull–White one- and two-factor for interest rates; geometric Brownian motion, Heston and jump-diffusion for equities; Merton and Jarrow–Turnbull for credit — beneath a portfolio aggregation layer. It ships with eight methodology documents written to citation grade, and with a regression harness of 155 pytest files that locks every simulation to a bit-identical fingerprint, so that any change to the code which alters any output, anywhere, fails the build. The interest-rate calibration reprices the swaption surface to roughly 1e-9 basis points. I do not claim the ESG rivals the breadth of a commercial suite; it does not. I claim that its existence, at this standard, out of one person’s spare hours, was not possible five years ago — and that any reader of this paper can verify the claim by inspecting the artefacts, which is rather the point of what follows.

What did not change

Here the argument must slow down, because the collapse in build cost is only one side of the ledger, and it is the other side that governs the decision.

The cost of validation has not fallen. A model that enters an insurer’s reporting chain must be independently validated, documented, governed and monitored, whatever it cost to build. Under Solvency II, IFRS 17, US GAAP or the NAIC risk-based capital framework, the demands of sign-off are indifferent to the production method: the validator must still trace every methodological choice to its justification, reproduce results, probe the boundaries at which the model fails, and put their own name to the conclusion. None of that work is done by an AI whose output is itself the thing under review; if anything, uncertainty about machine-written code raises the standard of evidence a prudent reviewer will set.

And the ownership of the risk is total. A chief risk officer who adopts a bespoke engine owns one hundred per cent of its model risk. There is no vendor to share the blame, no user community whose collective experience substitutes for assurance, no line in the validation report naming a familiar platform that lets a reviewer move on. Every assumption must stand on its own evidence.

This is the fact the current enthusiasm for AI-built models routinely omits, and it must be stated bluntly: any build-versus-buy analysis that prices the build and ignores the sign-off is wrong. The collapse in build cost does not shrink the validation bill; it merely makes validation the dominant term in the total cost of ownership. An honest analysis begins there.

The resolution

The resolution I propose is not that validation can be economised away. It is that validation can be made cheaper per unit of assurance — by openness.

Consider what a validator can actually do with a commercial platform. The core engine is closed. The validator tests inputs against outputs, reads vendor documentation written for another purpose, benchmarks against a second model where budget allows, and leans on the community’s shared experience as a proxy for inspection. The profession has long priced this opacity as a convenience — someone else’s problem, competently handled. It was always a cost. It places a ceiling on the depth of assurance that any quantity of validation effort can purchase, because the artefact itself resists examination.

An engine built for inspectability inverts this. Where the methodology documents cite the primary literature and derive what they implement; where the code can be read alongside the papers it encodes; where a regression harness demonstrates, rather than asserts, that behaviour is pinned — the validator’s work becomes direct: read, reproduce, challenge. The evidence of correctness is the deliverable, not an appendix. My contention is that a transparent engine accompanied by a complete evidence pack can be cheaper to sign off than a black box accompanied by a vendor relationship — not because the review is smaller, but because none of it is spent negotiating with opacity. The defensibility that insurers were buying from the herd can instead be built into the artefact.

What still favours the incumbents

I should be plain about what this argument does not establish.

The commercial suites retain advantages that openness does not touch. There is the ecosystem: decades of product libraries, templates and accumulated workarounds that a bespoke engine begins without. There is staffing liquidity: an insurer can hire experienced Prophet or AXIS developers on the open market, whereas a bespoke engine’s expertise is concentrated in the people who built it — in the case of my worked example, concentrated in me, which is a key-person risk I cannot argue away. There is regulator familiarity: a supervisor who has met a platform in a hundred filings extends it a presumption that no new engine inherits, and the first bespoke engines through review will pay a pioneer’s toll. And my evidence base is a single worked example, built by the person advancing the thesis; the reader should discount accordingly.

So the boundary of the argument is this. For the core valuation platform of a large insurer, buying remains the defensible choice today. Where the economics have genuinely turned is at the edges the suites serve least well — scenario generation, niche products, and above all independent challenger models, where a transparent engine set against the incumbent is itself an act of validation. The old equilibrium rested on a ratio of costs that has changed and will not change back. The question is not whether bespoke engines reach the profession, but whether they arrive carrying their evidence with them.