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?
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?
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:
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.
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:
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.
Arrange a demo with one of our experts
You will receive an email with demo details. Looking forward to chatting with you.