We operate in a complex space. That's true for myself and my colleagues in software engineering, but if you work in [re]insurance then that's probably true for you too.

Reinsurance practitioners now have an array of tools available to them through the huge growth of the insurtech sector, however Excel appears to maintain its position as the go-to resource for cedents, brokers, and reinsurers. Is it time to move on?

Programming Languages Are Not Infallible

Software a few decades ago was often written in a programming language called C. Perhaps you've heard of it. It's a mighty powerful language and it's still widely used today, but it has a problem: working with C invariably means manually managing computer memory.

At any kind of non-trivial scale, it is near enough inevitable that manually managing memory allocations will ensure you or someone in your team will cause a memory access violation. This happens when your program inadvertently writes data into memory locations adjacent to where you were expecting. This happened in an infamous and critical security vulnerability called CVE-2014-0160, more commonly known as Heartbleed.

What happens when this happens?

Many things.

All of them, bad.

Your program can crash. Your data can be corrupted. You can expose your system — and any other system your program runs on — to critical security vulnerabilities. You can leak sensitive data. In fact, C is the language with the highest proportion of Internet-facing security vulnerabilities by far.

How do we manage this complexity (and consequent risk)?

Well it certainly isn't by just being really careful. Imagine proffering an argument like that to a road traffic safety authority! Let's do away with seatbelts and just be really careful!

In professional software engineering, we employ a technique called Defence in Depth, which means we use multiple layers of security controls to guard against the inevitability of human failure in a complex system.

These layers can come in several complementary forms. For example:

• Layers of abstraction: When you’re driving a car, you aren’t thinking to yourself that you’d like to increase the rate at which fuel is injected into your vehicle’s internal combustion chambers and cause more forceful explosions. Instead, you abstract over these technical details. You want to go faster, so you push the throttle pedal a little harder. Similarly in software engineering, we don’t write our code directly in ones and zeroes, even though that’s how logic is fundamentally represented in the machine. We abstract over the binary language with higher-level languages which are less cumbersome to wield.
• Various kinds of manual and automated tests: Whenever we build or design a system, we need to check that the thing we’re building actually works the way we expect. Sometimes we have people manually verifying the functionality of the system. Sometimes we can instruct machines to do this verification for us automatically. Sometimes it’s a combination of the two.
• Static analysis, type theory, category theory, or formal methods:In many contexts, we can use fundamental mathematical properties of the components in our system to guarantee that certain kinds of failures can’t happen. These kinds of more formal approaches are often employed in areas where system failure has the potential to cause serious human harm, such as the software that controls aircraft. Boeing invests heavily in formal methods as part of their risk mitigation strategy.

People Aren’t Infallible Either

It can be tempting to convince yourself that you just wouldn't make these silly mistakes. But how well does this scale? Can you trust every member of your team to be utterly, meticulously infallible? Even under varying levels of professional experience? And under pressure from looming deadlines? Language barriers? Challenges outside of work?

The winning strategy is to accept human fallibility as universal truth. And this of course extends beyond software engineering.

Utilising the Right Tools to Reduce Avoidable Error

If you're a [re]insurance professional, then there's a good chance that Excel is your power tool. Excel does everything. It gives you all the freedom you could ever fathom, and more.

But Excel — like a Swiss Army knife where every swivelling surgical implement is actually a miniature chainsaw, and the handle itself is a miniature chainsaw, too — also gives you the freedom to swiftly cut both of your legs off. How would you even hold such a tool? Yes, Excel can do everything, but that means it also gives you more opportunity to harm yourself — or rather, your business — than you’re likely comfortable with.

We've seen this happen countless times in industry:

• When a colleague is manually fettling monetary amounts in individual cells in a million-row bordereau and misses a decimal place.
• When Excel inexplicably parses biological genes as calendar dates
• When your spreadsheet includes some numbers labelled NOT SHARE WITH UNDERWRITER, and then the entire spreadsheet is exposed with the underwriter on a Zoom call.

The consequences for blunders such as these are expensive exercises in verification at best. And when large sets of data are managed manually by several people, the surface area for mistakes like these is vast.

But the C programming language isn't going away, and of course neither is Excel. These power tools have their place, and it wouldn't make sense for a business to try to obviate them entirely.

The wise and grizzled software engineer will still write code in C, but not all the time. The key to managing complexity is by being smarter about when to reach for those power tools. In most cases, it makes better economic sense to use the tools which protect you from security vulnerabilities, invalid data, and human error. In software engineering that tool might be Python. Or it might be Haskell. Or it might be TLA+.

At Supercede, a large part of our risk mitigation strategy is by leveraging the Haskell programming language. It enables us to easily create abstractions over lower level computation. It also allows us to leverage type theory and static analysis so we can protect ourselves from ourselves. When we need to fine-tune the performance characteristics of some low-level algorithm, we can drop down to a language like C, but that’s not our default.

At Supercede our tool for mitigating software engineering risk is Haskell.

In [re]insurance, that tool is Supercede.

Supercede is your Defence in Depth, and research highlights that Supercede delivers an 85% reduction in the internal time spent collating and validating risk information between ceded re teams and their underwriting, claims, accounting and finance colleagues.