Microservices have been mainstream in software engineering for a decade. They have been almost absent from actuarial and accounting workflows. That gap is closing, and the teams crossing it are getting compounding returns. This article is a working note on what it actually looks like to put microservices into actuarial and finance work.
Why this is finally happening
The reason microservices took so long to reach actuarial and accounting estates is straightforward: the existing toolchain was Excel, and Excel does not host services. A workbook is a monolith. A model in Excel that needs to talk to another model in Excel does so by file handoff, manual copy, or VBA glue. Each handoff is fragile. Each handoff is a place where the cycle slows down.
Three things changed in the last few years. Office.js made Excel scriptable across the web. Cloud platforms made small services cheap to host. And, mostly, IFRS 17 and SAM made the data flowing through the actuarial estate too complex for a workbook-only architecture to handle credibly. The pressure to break things up has finally reached the actuarial and finance functions.
What a microservice does in this context
A microservice in an actuarial or accounting workflow is a small, focused piece of code that does one thing well, exposes a clear API, runs on its own deployment, and can be called by anything that speaks HTTP. Examples we have built or seen at clients:
- A cashflow projection service that takes a set of policy records and an assumption set, and returns projected cashflows. Single endpoint. Clear contract. Versioned.
- An assumption resolution service that, given a product, basis and effective date, returns the active assumption set. The Excel front-end calls it; the projection service calls it; reporting calls it.
- A reconciliation service that takes two trial balances and returns the variance with explanations.
- A tax-fund-split service for South African Life books that allocates cashflows across the four tax funds (IPF, CPF, UPF, RPF) according to current rules.
Each of these is small. Each is owned by one team. Each can be tested independently. Each can be deployed without rebuilding the whole estate.
Why this matters
The benefit is not architectural elegance. The benefit is that the day-to-day work changes. When the assumption-resolution rule changes, you change one service. The projection model picks up the new rule on the next call. The reporting picks it up on the next call. There is no chain of workbook updates and version mismatches. The cycle accelerates because the things that used to require coordination now require an API call.
The change to working life is real. On the engagements where we have done this, that meeting goes away — because the new assumption is in the service, and the service is the source of truth. The “meeting where we synchronise everyone on the new assumption” was costing them a day a fortnight. They get the day back.
What we see go wrong
Three patterns recur when teams try this without enough engineering depth.
Distributed monolith. The team breaks the workbook into services but the services all share the same database, the same deployment timing, the same release cycle. They have all the complexity of distribution and none of the independence. The cure is to enforce true independence — each service owns its own data, deploys on its own schedule, and the contract is the only thing that matters.
Service sprawl. Every minor calculation becomes its own service. The team ends up running forty services and cannot remember what each does. The cure is the opposite discipline — keep services chunky enough that a person can describe what each does in one sentence. If the description is “it computes X for Y”, the service is well-shaped. If it is “it has some helpers for the projection”, merge it into the projection service.
Version-skew chaos. Services version independently and the team loses track of which versions are mutually compatible. The cure is contract testing at the boundary, run in CI, that fails the build the moment a downstream service stops accepting an upstream’s output. This is engineering hygiene, not theatrics.
What good looks like
A working microservice estate inside an actuarial team, two years in, looks like this. There are five to ten focused services, each owned by one or two people. Excel front-ends call them through the Office.js layer. Reporting tools call them through the same APIs. The CI pipeline runs contract tests against each service nightly. Versioned and reproducible — the team can regenerate a six-month-old IFRS 17 number from versioned services and inputs without manual intervention.
This is not a far-off destination. It is what we are helping teams build now, in projects that take months not years. The hardest part is not the engineering. The hardest part is convincing the team that the workbook needs to give up its monolithic role and become a thin front-end.
If you are scoping a microservices migration for actuarial or finance work, our Symphony Automate product and our bespoke software practice cover both ends of this — the orchestration layer and the build itself.