[gosub100]

What is the primary computational task for insurance? Is it computing actuarial tables? Or accounting for the premiums/claims? Or something else? I can excuse banking for not switching off of COBOL but I fail to see how insurance uses it to any significant degree.

[sethhochberg]

Some less-common varieties of life insurance start to look a whole lot like investment products and are (sometimes controversially) sold as such for people in very specific financial situations - think like cash value and death benefit value that vary over time based on asset performance. A legacy insurer selling Variable Universal Life or similar policies would have some financial calculation needs.

[janstice]

And I guess if there’s a whole-of-life policy sold in 1962 that hasn’t been terminated - I guess there’s a lot of grandfathered rules that are just easier to keep in their original systems.

[jonathanlydall]

I can’t remark on COBOL, but I did contracting for a time to non-US insurance company replacing their Universe Basic system originally written in the mid 90s, with a .NET Core (3.1 had just come out at the time, around 2019) based system.

The system contained records of all their policies including all the premium factors (e.g. make, model, year of car, parking location, physical address, etc). These premium factors were then fed into a rating engine which would use actuarial tables with custom actuarial defined algorithms to determine premiums.

In insurance companies, working out the correct premium is core to everything. Insurance companies can have lots of different products and their competitive edge comes from how well they structure their offerings and determine the correct premiums based on risk factors. One does not simply rewrite such a thing.

Couple of things I thought were a bit interesting about the place:

- Their single server running Universe Basic (with a hot spare I believe) had 4TB of RAM. - While I was used to the devs being the stars of the show at the consulting house I worked at, at insurance companies it’s the actuaries.

[kqr]

Accounting is a huge part of it. Sometimes claims are not fully resolved for decades, and the books for that policy hypothetically have to be kept open for as long. This must be kept correct, but is not computationally heavy.

Computing total exposures and possible loss distributions are things which can be more computationally heavy. It includes grouping together similar policies which is multiplicative in complexity.

[jbreckmckye]

Insurance is largely about pricing risk. At the heart of most insurance platforms is a risk engine of sorts that takes a list of parameters and produces a premium.

The better your risk models, the more easily you can offer competitive premiums without over-exposure.

(I have worked in insuretech. Although my work was on transactional services and our white labelling capabilities rather than the math heavy stuff)

[kpil]

I think you got most details from the others, but insurance is two basically two different things:

Life Insurance is mostly a savings product, and the insurance part protects you if you live too long.

Property and casualty insurance protects you from losses, including someone's life, but also houses, cars, etc.

The domains are quite different, but they both have specific "insurance business" computing that's related to actuarial science or analysis, i.e. the statistics needed to calculate reserves, policies, prices etc.

I doubt COBOL is used for any actuarial analysis. I think SAS is still strong, but I suspect R is used now. Maybe Python is used in the more static calculations that are handed over to developers, but the actuaries are typically coding whatever they need when they create their models.

The rest is just case management, automating business rules, bookkeeping, payments, and for life insurance also systems for trading securities and funds, and possibly in-house tools for asset management.

There isn't really a strong case for COBOL. The only reason COBOL still is used is that the insurance companies where early adopters and saw computing as a way to reduce the administrative overhead. The investments were made at a time when trusting some hippies running UNIX wasn't really on the table, and even less so trusting some nerds and their rickety PCs. They built up a workforce with COBOL devs that also gained quite a lot of business knowledge.

The digitalisation created another problem - a lot of the older employees were hired to do simple administrative tasks. Even big corporations aren't totally psychopathic so it actually has taken a long time to shift out the employees, and retrain the remainder for the jobs that got more demanding. Even the employees that didn't really have that much high-value domain-specific knowledge to begin with. So the case for more automation was actually not as strong as it could have been.

Even still, although especially life insurance is a totally digital product (damage claims is not), they primarily see IT as a cost centre at heart although they probably claim they do not.

This has shaped their systems and they have tended to replace their old systems when they're forced by external factors, as the upsides - better digital sales, more automated decisions, better trading experience for their customers,etc are not as easy to achieve as the more tangible administrative automation cost savings they started out with.

Actually, this also applies to banks. You could totally run an insurance company or bank without any mainframes or a single line of COBOL. But the organisations still have COBOL developers and maybe more important an upper management that come from that tradition.