Actuarial modeling systems have been around since the dawn of time. Maybe not quite that long, but there is a bunch of history there.
And as tools go, they have often performed well. First, actuaries developed commutation functions to simplify calculations. They worked, but were quite limited on time steps and the features that could be modeled, and the fact that they were a simplification of theory because first principles calculations were just too complicated..
Then spreadsheets came along, and everyone was happy. Actuaries could do what they wanted, could make formulas according to their needs, and could model product cash flows from first principles.
And then actuarial software sprang up, ex nihilo and all that, and people could do what they really wanted to do, but had been limited by the constraints of the spreadsheets. Things like precise calculations of date-specific reserves, running across hundreds of thousands of policies with the same code, and so on.
But as those software packages have aged, maybe your company hasn’t quite kept up with the times.
Maybe you don’t have all the features you want, or need. Maybe you implemented an “actuarial modernization” project a couple of years ago, and wonder whether you got all you were promised.
Maybe because of those frustrations you’re wondering if it’s time to look for a new software system.
But, do you actually need a new software package? Or would you be better served by just patching your current system yet again with another workaround?
It’s kind of hard to tell without getting in and actually looking at your systems and processes. That’s what consultants seem to be for, anyway.
There are quite a few “usual” reasons why your company may choose to implement a new actuarial modeling software. Regulatory requirements, new products, or accessing new technology (such as cloud-based distributed processing) are the obvious ones.
However, there are plenty of not-so-obvious leading indicators that your actuaries may need a new system to handle their day-to-day, quarter-end, or ad-hoc processes. In this article, we’ll point out a few clues that it might be time to upgrade your actuarial modeling system.
1. When your processes aren’t standard any longer
If you don’t have a lot of consistency across your business units, products, or divisions, this is a good indicator that you might benefit from switching systems.
If the pricing team creates a model in Excel, and throws a bunch of specs and a database of results over the wall to the valuation team, that’s not standardization.
If your valuation team and your A/LM team are building separate, parallel models in disparate systems, because one doesn’t do what the other needs, that’s not standardization.
If your discrete business unit actuaries have their own process for assumption updates (including peer review, sign-off, and validation in the model), but nothing is the same (or even similar) across departments, that’s not standardization.
And it’s a major challenge.
It’s not your fault
Nobody set out to create such convoluted structures of modeling and model management. Everyone started the last conversion project with the goal of keeping standards high, and holding everyone to them.
We get this way incrementally. One little exception to the rule here, one deviation from standard there, and over time those differences compound.
Eventually, you get to the point where you’re managing more exceptions than abiding by the actual standards.
The challenges of learning all of these different systems, processes, and standards impedes many actuaries’ work product. Because they can’t contribute like they want to.
This divergence may slow down rotations. It may keep experienced actuaries from taking on leadership positions in another department, because of an intimidating learning curve or fear of losing expertise in the existing team.
Ultimately, those aren’t good for business. Actuaries can do better, and many of them want to do better. If you’re struggling, maybe that’s a sign that it’s time to hit [RESET] and get all your standards back on track.
2. When your processes aren’t scalable
By this, we don’t just mean that you don’t have access to virtual machines, or a dedicated bank of machines for distributed processing.
We mean, when you do one thing for one product, and you do two things for two products.
That’s linearity. Suppose you are a pricing actuary, and all your processes are different for each of your products. Your term life, your deferred annuities, and your riders all have unique structures of assumption development, modeling changes, pricing targets, and review.
If you want to add new products, then, are you going to be inclined to follow all those different standards, slowing you down and adding mental frustration? Or are you going to be looking for ways to avoid some of this busywork? We’d be trying to avoid it, if at all possible. How might that be affecting your output?
The alternative is to create processes that are scalable, because you do them once and they apply to multiple products at the same time.
If you’re still struggling with software that doesn’t allow you the flexibility to investigate multiple different options in parallel, with just a couple of clicks, then you may be a candidate for a new system.
Scalability makes work easier and better
Let’s take a simple term life product. If you have a non-scalable system, every time you have a new product feature, or expense assumption, or commission structure, you may have to make a whole new “product”. That requires more time – more data – more headache – more back-end management.
And reduces the incentive to investigate alternatives, because of the overhead involved.
Which means you’re not doing your best work.
Alternatively, if you have a scalable system, when you have new features you’re trying to price or calculate reserves for, it may be as simple as adding a few lines to a table. Now, you can easily scale up and investigate two, five, ten, or a hundred different options for those new products. If you do it right, it may take no more effort than copying a table.
That’s the advantage of modern, flexible, scalable systems. They allow you to do one thing for many products.
3. When you spend too much time on audits
Nobody likes audits. (Not even auditors.) But they are a necessary part of the actuarial work process.
Much of an actuarial audit is “Tell me how this number was derived.” And, often, that requires replicating a calculation that was done in aggregate for the individual pieces. You might even need to split cells into individual model points and create additional output reports to extract all the sub-calculations that went into the final reserve number.
This isn’t a good use of your time. Modern actuarial systems recognize the need for actuaries to drill into calculations and show the history of how they were developed.
Traditional actuarial systems don’t have that ability. Which means that actuaries may have to spend time recreating seriatim results that should have been produced and recorded when the models were run the first time.We recently heard an actuary talking about this drill-down capacity of one such modern system. (Ten bucks says you can probably guess which one…) He said he’d been working for 20 years with a commercially available tool, and had gotten very good at it.
He was proud that it only took half an hour each time to validate a cell’s reserve calculation.
But still, that was time that he didn’t need to spend. That time did not add to any analysis of risks for his clients. That time did not ensure he was more knowledgeable about new regulations and how to account for them. That time wasn’t productive – it was detractive.
Unfortunately, that’s the standard for many actuaries. We too often think, That’s just what I have to deal with.
It doesn’t have to be that way.
When he saw one of these modern, click-it-and-see systems, he said, “That’s going to put me out of business!”
Maybe.
Or maybe he’ll sign up as a user of that system, and get his clients better results.
The same is available for other actuaries as well. If you’re spending more time recreating results for audits than you did generating them in the first place, maybe it’s time to look for a new system.
4. When you need more comprehensive model governance tools
How do you manage your assumptions? How do you document which assumption was used in the various models? How do you validate that model changes are what they were intended to be, and that nobody is accidentally changing, adding, or deleting features?
Do you depend on eyeballing results afterwards to make sure they don’t look “out of line”? How do you validate that process?
A better way is to implement a model governance framework, which often includes rules about how to make changes to the models (calculations) and the inputs (assumptions). You might assign certain roles and responsibilities, require sign-offs, and track versions of tables and formulas. Everything has structure and clear delineation of who does what.
The whole point of model governance is to allow the actuary to do one specific thing: Be confident of what is in the model.
Unfortunately, some actuaries struggle with this kind of certainty. They just don’t know, because there is a whole history of unrecorded changes to either model features or assumptions that weren’t systematically tracked.
They may be able to investigate a model to figure out what’s there now. But what happens if, for instance, a commission rate table in a valuation model isn’t matching what was in the pricing documents. Do you know who changed it? And when? And why? Or whether it might have just been input incorrectly in the first place?
Modern software provides much of this functionality automatically
Cloud-based systems usually have automated tracking of changes implemented to the system. They often also have automatic versioning, in which code and tables can be archived along with the results of the model, so every element can be traced back to its source.
You don’t get that with older systems. We can recall times when assumptions were tracked in separate Microsoft Word documents, one document for each model (sorted by company, then product line, then task). That ends up adding a lot of manual intervention on the part of the actuary (or the actuarial student) to:
- Validate that the assumption in the model was changed to what was recommended based on the experience study;
- Validate that the assumption in the model was recorded in the documentation; and
- Record who made the change, when, and for what reason.
As an alternative, modern software automatically provides for much of that change management. Functionality may include table and code change tracking within the system itself, as well as documenting who made the changes and when. Instead of creating separate documents, which themselves need to be managed and maintained, the model can be considered self-documenting.
That speeds up your processes, eliminates headaches, simplifies audits and related tasks later, and gives the actuary a chance to get back to the actual value-added work of evaluating risk. So if you’re struggling because your model governance framework isn’t robust enough, flexible enough, or doesn’t actually provide the kind of structure you need to be confident that the models are what you said they are, that’s a good sign you could benefit from an upgrade to a modern system.
There’s a lot more to this idea. For now, we’re going to stop and let you catch your breath. Next: 4 more signs it might be time to change your actuarial modeling system, and a word of caution as well.