Actuarial Process and HPC Optimisation
A major European insurer with critical actuarial processes faced unsustainable computing times and a static HPC infrastructure unable to adapt to demand.
Challenge
Static HPC infrastructure and undocumented legacy code. Monthly closing cycles consumed days of computing, with bottlenecks in the most critical actuarial processes and high operational risk.
Solution
Detailed actuarial environment diagnosis, progressive phased HPC optimisation and modular code refactoring. Deployment without interrupting critical business cycles.
Technologies
- HPC / Grid Computing
- Actuarial code optimisation
- Hybrid infrastructure
- Performance monitoring
Context
A large European insurer ran its actuarial and group-policy processes on an inherited Oracle stack (Oracle 10g, Oracle Forms, PL/SQL, Pro*C). Key calculations took up to 36 hours, business logic was embedded in undocumented code and, without the original team, every intervention was more expensive. On top of that came a long payback: investments took up to three years to recover.
The agreed objective was threefold: accelerate and simplify the actuarial and group-policy processes, modernise the system without interrupting daily operations, and guarantee accuracy and regulatory compliance with greater efficiency. All of it with exact month-end reporting as a non-negotiable constraint.
The challenge
The actuarial and group-policy processes were held back by an outdated infrastructure. Operations that are essential for risk assessment and regulatory compliance suffered bottlenecks that hurt both efficiency and the reliability of results:
- Obsolete processes: old code and outdated technology.
- Long processing times: up to 36 hours to calculate group and actuarial results.
- Regulatory compliance: strict requirements demanding accurate reports at month-end close.
- Technical debt: without the original team, maintaining the system got harder every year.
- Financial impact: a long payback, with investments taking up to three years to recover.
Phased approach
The engagement was structured in phases, which made for an orderly, controlled implementation aligned with the insurer's operating cycles. Three principles guided it: operational stability (act on the systems without altering their availability), a gradual approach (prioritise the most critical actuarial and group-policy processes) and a technical-plus-business view (deep technical knowledge combined with an understanding of the regulatory and risk environment).
-
01
Study phase
Code analysis, review of the actuarial and group-policy processes and gathering of business information.
-
02
Problem identification
Bottlenecks in four main functions, undocumented historical code and slow, inflexible processes.
-
03
Solution design
Phased planning, modular restructuring and prioritisation of critical tasks.
-
04
Implementation and validation
Staged releases without interrupting operations and continuous functional validation.
-
05
Closure
Validated results, optimised environment and a drastic reduction in processing time.
Architecture and strategy
The strategy rested on four pillars. Detailed diagnosis of the actuarial and group-policy environment: the existing infrastructure, business logic, code and most critical processes were mapped, identifying bottlenecks, duplication and undocumented procedures. Modular refactoring of the code: the most demanding procedures were reworked, rewriting functions, removing redundancy and reorganising the logic; the refactoring concentrated on the four processes (policies, insurer, capital and reserve) that accounted for more than 90% of compute time.
HPC infrastructure optimisation: resources adjusted to real load and calculation accuracy validated at every iteration. Progressive improvement in phases: staged releases with intermediate validation, guaranteeing operational continuity without affecting month-end close cycles. In parallel, the architecture was decoupled into microservices (ReactJS front end, .NET API back end, actuarial calculation engine and database microservices), with a Redis cache and dual Oracle/SQL Server compatibility during the transition, until the Oracle dependency was fully removed in favour of .NET, Python, SQL Server and Azure SQL.
Measurable results
During the initial phase we identified which processes consumed the most time, which allowed the first iteration to focus exclusively on the most critical ones and deliver an immediate impact on performance.
| Indicator | Before | After |
|---|---|---|
| Acceleration of actuarial processes | Key calculations of up to 36 h | +80% (modular refactoring) |
| Improvement in the optimised process | Process with the highest compute consumption | 98.62% |
| Total time of the first critical iteration | 1,080 minutes | 370 minutes |
| Oracle dependency (PL/SQL, Pro*C, Forms) | Total | Removed (.NET / Python / SQL Server / Azure SQL) |
| Continuity during the migration | Risk at every month-end close | No interruptions (staged releases with validation) |
| M365 security score (access hardening) | 11.48% | +30% over the baseline, with MFA on critical roles |
Aggregated figures, anonymised under a non-disclosure agreement. Source: Vermont Solutions projects.
Lessons that carry over
- Prioritise by load concentration: attacking 90% of compute time first delivers immediate impact.
- Decoupling the logic from the proprietary engine reduces dependence and enables real scalability.
- Dual compatibility during the transition means zero interruptions at month-end close.
- Advancing security in low-impact phases (MFA on admin roles first) improves the posture without friction for users.
Regulatory framework
Actuarial calculations feed supervisory reports with fixed deadlines. The modernisation was designed to strengthen compliance, not to put it at risk.
- Solvency II: reserve calculation and supervisory reporting requirements, with reports delivered on time and no risk of sanctions.
- DORA (Art. 28): operational resilience and ICT third-party management in the new architecture.
- A documented, maintainable system: reduced technical debt as evidence of internal control.
Frequently asked questions
How was it guaranteed that the actuarial results stayed correct after the refactoring?
By validating calculation accuracy at every iteration and with continuous functional validation before each release. No change reached production without comparing its results with those of the original process.
Did the month-end closes have to stop?
No. Releases were staged, with dual Oracle/SQL Server compatibility during the transition, so the close cycles were never affected.
Why focus on only four processes?
Because policies, insurer, capital and reserve accounted for more than 90% of compute time. Tackling them first produced the 98.62% improvement in the optimised process and cut the first critical iteration from 1,080 to 370 minutes.
Can I know the insurer and the full figures?
The case is anonymised under a non-disclosure agreement. Architecture details and full figures are shared after signing an NDA.
Related content
Last updated: 2026-09-12