HPC optimization and actuarial processes at a European insurer

Context

An international insurer headquartered in Europe runs its actuarial calculations on an HPC infrastructure managed by IBM Spectrum Symphony. The critical processes of every month-end close cycle depend on actuarial PL/SQL code written over years, without documentation and without the original team that developed it.

With a static HPC infrastructure and processes of up to 15 minutes each inside ever tighter close windows, the risk was not only about performance: it was about the regulatory calendar. The brief was to reduce times and resource consumption without interrupting a single close cycle.

The challenge

The initial diagnosis identified three fronts:

• Undocumented legacy actuarial code: changing it without understanding it in depth was a risk to the accuracy of the results.
• A static HPC infrastructure: resource allocation did not follow the real load of each process, with server consumption peaks during closes.
• Compromised close windows: four critical processes concentrated the compute time and any incident put on-time reporting at risk.

Phased approach

The work was organised in three chained stages, each validated before moving to the next.

1. 01

   Diagnosis of the actuarial environment and the HPC infrastructure

   Mapping of the business logic, the code and the grid's bottlenecks: which processes consumed the time and why.

2. 02

   Phased modular refactoring of 4 critical processes

   Rewriting functions, removing redundancy and reorganising the logic, process by process, comparing results with the original at every iteration.

3. 03

   Progressive HPC optimisation

   Adjusting grid resource usage to the real load of each process, with no platform changes and without interrupting the business cycles.

Architecture and strategy

No piece of the environment was replaced: the insurer kept its Symphony grid and its Oracle database. The improvement came from two combined levers, the code (less work per process) and the platform (a better distribution of that work), applied in small increments with accuracy validation at each one.

Measurable results

Results validated in production after the last phase:

Aggregated figures, anonymised under a non-disclosure agreement. Source: Vermont Solutions projects.

Lessons that carry over

• Diagnose before touching anything: the biggest saving sat in four specific processes, not in the whole platform.
• Refactoring and platform tuning together multiply the effect of each lever on its own.
• Validating accuracy at every iteration is what makes it safe to change undocumented actuarial code.

Regulatory framework

In insurance, actuarial calculation time determines whether reporting deadlines are met.

• Solvency II: calculation of technical provisions and supervisory reporting within the deadline.
• DORA (Art. 28): intervention on a critical system managed with phased validation and rollback capability.

Frequently asked questions

Related content

• Service: HPC and Grid Computing →
• Service: performance tuning →
• Product: add-on for IBM Spectrum Symphony →
• Case: actuarial modernisation at a large insurer →
• Glossary: IBM Spectrum Symphony →
• Glossary: PL/SQL →