“No-code” and “Low-code” software applications are very much in vogue these days.
For actuaries, there is a spectrum of options from do-it-yourself to everything-done-for-you. What are the positives and negatives of such options for actuarial software applications? We break them down in this article to give you helpful perspectives when you must choose.
First, let’s start with some definitions. In the actuarial software space, there really isn’t any such thing as “no code”. What is usually meant by this is the idea of a closed box of calculations, walled off from the end user being able to make any changes in formulas. Generally, these applications give the user an interface in which to make selections, and then behind the scenes does all the calculations. The user can’t really break anything, only select from a menu of options. To be fair, this often means you can’t screw up too badly. It doesn’t ensure never getting nonsense results, though.
On the other end of the spectrum is do-it-yourself applications, or what you might call “high code”. This is the blank template like a spreadsheet or a coding program. In these applications, the end-users are designing and building everything themselves.
Who cares?
“But guys,” you might say, “We’re not planning a system transformation any time soon, why should I care?” Excellent question.
This actually comes up often, though you may not recognize it. Any time a company either expands into a new line of business or initiates a new type of analysis is a good opportunity to investigate whether your current software stack is appropriate for the job. Plus, any sort of “efficiency” initiative provides the incentive to re-evaluate what you’re currently doing and see whether there’s a better way.
Who knows, you might find that you don’t need a whole overhaul of everything, but just one or two parts. Maybe you need to add a commercial system for that unique product line which has become too complex for your antiquated spreadsheets. Or you’re feeling frustrated with the lack of transparency in your current system. You’ve been tasked to explore bringing that work back to first principles because you’ve got some really smart actuaries on staff already.
[As an aside, here’s a link to some other signs that it may be time for a new system.]
Regardless, it’s good to perform the evaluation regularly so you don’t automatically default to “that’s just what we’ve always done”. Defaults are very rarely appropriate. They’re designed for the lowest common denominator, and that’s not you. [It better not be! How are you going to differentiate?]
No-Code Actuarial Software
Examples: Axis, PolySystems, UltraVal
Pros:
You don’t have to code anything! No more staring at a screen for hours till you find you’ve got a close-parenthesis outside the wrong sub-level END statement, no more headaches about the fact that parts don’t work right once you’ve made a change, no more worrying about compiler compatibility, no more wondering whether your named ranges actually cover all the inputs they’re supposed to. These all go away because the software system takes care all of that maintenance for you.
And your users can’t break it. At worst, they can set a few switches incorrectly, which can be undone easily by reverting back to the prior version.
Plus some regulators appreciate the fact that all users of a particular system will produce identical results with the same settings. They don’t need to read and parse code, either, in order to confirm the work you’ve done.
Cons:
No-code systems often promise out-of-the-box usability. However, our experience is that these systems have just as steep a learning curve as anything else out there. [Sometimes steeper.] Sure, you can’t break anything only by setting switches to be different values, but it often takes a long time to learn the nuances of various settings and the applicability of each to your particular situation.
Second, there’s the trade-off between the accuracy of the model and the speed at which the provider can push out the next iteration. If you find an error, or something just doesn’t quite work well for your use case, you’ve got to get in line behind all the other customers who have unique tweaks they want implemented in the next release as well.
And don’t forget that as an actuary, you are responsible for the calculations in the model. You can’t just rely on the statement that “the software is assumed to do it right”. How are you going to confirm that reserves are calculated correctly? Building replicating spreadsheets for everything kind of defeats the purpose of having the system in the first place, doesn’t it?
Judgment: While there is appeal in the idea of no-code systems, our experience has been that such systems hamper effective actuarial work more than they enable it.
High-Code Actuarial Software
Examples: Home-grown Excel spreadsheets, R programs
Pros:
You know exactly what you’ve got. Because you’ve built it according to your needs and specific use cases. You’ve designed spreadsheets and programs. You’ve recorded the macros. You know what needs to go where to fit with everything else that is unique to your company.
You will also have only what you need and don’t have to pay for extraneous product lines or analysis. If you only report under US Statutory Regulations, for example, but not under GAAP at all, why should you have to pay maintenance costs that support developments to comply with those new regulations? No waste, no excess.
Cons:
You’ve only got exactly what you’ve got. Because you’ve built it, it probably hasn’t gone through the same kind of rigorous optimization, usability design, and testing that most commercial software packages will have.
The downside is that these types of development efforts often result in excessive time, spending above budget, and poor design. Because actuaries aren’t fully trained in coding or software design principles, they often end up with piecemeal parts that sort of fit together but lack coherent design or usability.
Finally, while Excel or R may appear “free” at first glance, there are many hidden costs, from actuarial development time to IT resource allocations. We’ll expand on this later.
Judgment:
Like no-code systems above, high-code systems often offer promises they cannot keep. The time and cost of development by actuaries who should really be focusing on risk assessment tend to turn endeavors to build a custom system into a negative-ROI effort.
Remember, if we’re talking about a spectrum, there are options in the middle as well.
Mid-Range Actuarial Software
Examples: Prophet, Integrate, SLOPE
Pros:
These systems look to split the difference. Instead of locking code and operations away inside a black box, mid-range actuarial software applications start with something like a library of basic calculations for a usual library of products and operations. Then users can specifically tailor variables and codes to fit their specific situation. It’s sort of like a template: you have an outline to start from, and then you make modifications from there.
With mid-range systems, you can tweak not just settings but the calculations those settings apply to. You can add variables and definitions and conditions in which they apply. Plus, you don’t have to build everything from scratch, which will speed your implementation as well as your learning curve. Professionals who are good at such tasks like optimization and error remediation have already done the bulk of that work in setting up the templates.
Another advantage of no-code systems is that users can trace their formulas, like in Excel. Instead of being locked behind the interface, mid-range actuarial software often let users navigate precedents and dependents. This allows the user to confirm model mechanics without the need to recreate them in a spreadsheet.
Cons:
As much as we would want to say there are no drawbacks to mid-range systems, we must admit that there are a few. Model management requirements, for instance, aren’t going to disappear. You’ll still be responsible for keeping documentation of the model and assumptions up-to-date.
As well, regulators and auditors may require additional demonstrations that the modifications you have included are appropriate and have passed through your necessary model governance channels. You can’t just up and make a new set of code and expect your audience to trust you. You’ve got to prove that it works and that it’s been vetted.
And you’ll have to maintain the system, too, which will require reconciliation back to the official “templates” anytime there’s regulatory advancements or product evolution. This can take time and lead to significant deviations between your models and the standard supply. Which may incentivize slower updates of your models, because the reconciliation effort feels unproductive. Slower updates means stale models, and nobody wants that. So you will have to be proactive in maintaining your models, in more ways than when using no-code versions.
Judgment:
Obviously, we’re a little biased, but if we didn’t think it was the best way, we wouldn’t have built SLOPE. These mid-range systems offer the best of both worlds: they allow both the flexibility for users to get what they want, as well as providing an initial
And modern actuarial systems often bring additional features such as cloud-native hosting and on-demand scalability that significantly improve the end user’s experience. We think that this is the way that actuaries of the future will work, and we’re proud to be on the leading edge.
“That’s the way it’s always been done around here” just isn’t going to cut it any longer.
A Caveat
You’ll notice that we haven’t talked about cost in this article. That’s because the costs of various systems include several different components, beyond the sticker price.
There is no system that will be universally cheaper, overall, than any other. Sure, the dollars on the monthly invoice might be smaller, but at what other cost? Hiring an intern to “run” the model each month? Additional infrastructure at the outset? Or what about the opportunity cost of distracting your actuaries from their regular production in order to ask them to build out this new model “in your spare time”?
All of those should be included in your cost/benefit analysis when you make your evaluations. Which goes to say, “free” doesn’t actually mean it comes with no costs at all.
With that, we’ll leave you with three tips to keep in mind when beginning a new modeling project:
Tips
- RECOGNIZE that there are options when it comes to your software. Your first tendency, when asked to “pull something together” may be an Excel spreadsheet. Or to copy the existing commercial model and just make the few tweaks that are immediately obvious, to get started. However, in almost all instances, it’s worth your time to step back for a second and ask, Is that the only option? If you’ll take a few minutes to consider the pros and cons laid out above, you might find a more effective solution at a different point along the spectrum.
- MAKE THE CASE for building your model using whatever system you decide is the best application for your use case. Consider costs of development, flexibility, future users, how your model governance will be applied, assumption maintenance, and all the various components that go into building and using your model.
- BUILD THE MODEL. We’re confident that if you start with the right choice, you’ll soon end up with a model (and analyses) that is fully optimized, helping you to be a better actuary.