prior posts in this series:
8 Signs You Might Need a New Actuarial Modeling System (Part 1) (Part 2)
6 Key Components of the Case for Actuarial Modeling System Conversion
Congratulations! You’ve secured approval to investigate upgrading to a modern actuarial system.
Now, it’s time to decide which criteria are going to be valuable to you as you make your decision. The following is a broad brush approach to how you should think about your various options. At a minimum, you will need to consider costs, usability, company reputation, responsiveness, standard (or not) products, how that software improves your processes, how you access the system, data storage, and aggregation.
You may even think of other elements that you want to include, but if you can compare your alternatives across these dimensions, you should have a good handle on the differences between systems and how they would work and be applied in your company.
1. Costs
Your costs of the system should include direct costs (license fees, hardware, and ancillary software) as well as indirect costs (time of actuaries, time of non-actuaries). These are fairly standard and fairly transparent.
As well, you’ll need to have an estimate of the “business costs” of not having a modern actuarial system. This is things like inefficient hedging, slower product development, wasted time with converting data into necessary formats, additional steps to complete documentation and model governance, etc. We spent a significant amount of time on this last time. Do check out the whole thing.
2. Usability (closed vs. open)
Another dimension is the “usability” or the “flexibility” of the system. (We’ve written about this, too.)
Basically, there is a spectrum of modern actuarial systems. On one end (SLOPE) are fully open systems. That means that users can make changes to formulas, structures, and processes without going back to the vendor for intervention.
Often, actuaries appreciate and use this kind of a system when they need flexibility in their product code. It’s akin to an Excel workbook, in that users can decide what they need to do, and then do it. They aren’t waiting for the vendor, and they’re also not creating workarounds or true-ups that add steps (and time) to the process.
At the other end is a fully closed system. Sometimes referred to as a “black box” calculation, usage of this system is limited to selecting options that the vendor has predetermined are necessary.
This is quite popular with auditors, because they recognize that limiting the end user’s chances to incorrectly code something limits their risk of doing it wrong.
Obviously, there are advantages to both. Advocating for flexibility, this is the most customizable to the user’s needs. It also allows for the actuary to validate and certify that the code is what she said it is, not relying on another professional’s judgment. When you’re the appointed actuary and not only your job but your reputation is on the line, many actuaries feel they want that certainty of investigation and understanding.
Advocates for closed systems will point out that it’s really hard to screw something up inadvertently if you can only select switches. That’s true. And closed systems are often very comprehensive out-of-the-box, because they have to be in order to adequately cover the spectrum of the user’s potential needs.
And that leads to another trade-off. More flexibility means more customization on your part, which can sometimes take a long time to get models built (if the system isn’t designed well). More standardization means that you may not have to build from scratch in order to get results, you also run the risk of not having the right combination of switches to flip to adequately describe your products or risk profile.
There is no one way that’s right for everyone. But recognizing that you’ve got to make certain trade-offs will go far in your decision.
3. Reputation
How long has the potential software you’re looking at been in use? How long has the company been around? What do others say about working with them, or with their software?
Are they leaders in the industry, or followers? Why did they even start that company in the first place? Why are they still in business?
All of these questions are good to ask not only of your potential vendors, but of customers of those vendors. How do current (and past) customers talk about those vendors and those systems? Are they what everyone is talking about? If so, why? Are they what everyone wants to be a part of? If so, why? Does everyone avoid a certain “feature” that turns out to be a “bug”?
A company’s reputation is, in the end, the only thing that can truly differentiate it from competitors. Virtually all modern actuarial software will calculate cash flows, apply accounting rules, and produce a set of output. (That’s why you’re using it, right?) And those that lead with technology run the risk of fast followers adopting the same and implementing it just as well as they do.
But the reputation (the Why they’re in business, the How they view their customers, the What world do they see in the future?), that’s going to be unique to each vendor. And even to the employees who work there.
If you can’t tell why they’re doing what they’re doing, or if you can see that what they’re actually doing doesn’t line up with what they say they’re doing, that should give you pause to question whether you can trust that company with your valuable actuarial processes.
You’re making a big investment in your actuaries and your actuarial systems. You want to do everything you can to ensure success.
4. Responsiveness
Much like your phone needs an update every now and again, your actuarial system does, too. New features, deleting extraneous fluff, improvements to the design and usability all should be happening regularly.
How quickly will your vendor 1) respond to your service request, and 2) change what you need to be changed?
You might not know this immediately. But see if you can get some examples of what it takes in order to have a change to the following: a system issue (i.e. you want some additional functionality in the front end), or a code change (you want a formula to be different, new, or deleted).
Modern actuarial software systems respect the needs of their users and are built in such a way that they can respond to requests quickly. Previous systems required many back-and-forth requirements sessions, perhaps even a User Group to intervene and advocate for what those users needed in order to do their job better.
Modern systems, though, do it better because they’re designed that way. System vendors often release updates in regular development cycles (called “sprints” in the programming world) that allow for consistent updates.
As such, you’ll never get behind on your version, leading to additional upgrade work to catch up.
We can remember conversion efforts that were projects in themselves in order to simply catch up the historical actuarial system to the newest “version”.
Problems with this setup include the fact that you (as a user) may fall behind if, due to more urgent priorities, you miss an update. Then each update becomes an even larger hurdle to staying current.
Modern actuarial systems, though, manage this for you. They generally have one current version that everyone is using, and the developers do the work to back-test and ensure continuity when they’re rolling out new features.
This means you’re never behind when you’re using a modern system. You’re always up-to-date, which not only gives you access to the latest functionality, it also ensures you don’t have down time to upgrade your software to the newest version.
That’s a pain. One that you may be able to avoid by careful selection of your next software system.
5. Products
All systems will cover the vast majority of standard life insurance and annuity products: term life, whole life, universal life, VUL, payout annuities, and deferred annuities.
And many will also cover standard types of assets: corporate bonds, government bonds, mortgages, stocks, etc.
Plus, you should also have the flexibility to incorporate externally-projected cash flows from liabilities or assets, in case the system’s base products don’t do a good enough job.
So why do we care about Products? Because, as in the “flexibility” or “usability” discussion, if your company has unique products with unique features, you may not be able to adequately model those risks using certain modeling systems.
That may be fine. You may not wish to convert every little exotic product to your standard system.
But then again, you need to recognize the trade-off you’re making when you do that. You give up standardization and integration. And you also commit to maintaining that extra little Excel workbook or R program that only one person actually knows anything about.
Managing exceptions may not be the way you really want to run your actuarial department in the future. If it’s not, you’ll want to make sure your new system can handle all your products.
6. Processes
What are the processes you really want to do with your actuarial modeling system? And how much of your work do you want to keep external to that system?
This is in line with products above. The processes you’re going to execute in your system will drive your adoption and implementation of a system. If you’d really like to get full life cycle actuarial work with just a singular platform (maybe so you don’t have to convert pricing models to valuation models, and then don’t have to convert valuation models to forecasting models), then you’ll certainly want to search for a system that can do it all.
And, again like the Products discussion above, you’ll need to decide if there are some unusual, infrequent, or just plain impossible-to-model processes that you don’t wish to import into your system. Sometimes these are just very riskless processes that don’t meet the standard for the time it would take to build them into a full model.
But remember, again, if you’re choosing not to incorporate all your processes, you’re going to be dealing with separate assumption management processes, data management processes, managing separate documentation, and constantly re-validating all those little parts that don’t make it into your standard modeling system.That’s fine. But at least recognize that you are choosing. And that five-years-from-now you is going to have to live with that choice.
7. Access
We feel it is important to bring this up because access has only really become a dimension of consideration in the past five years.
Before then, all of the software systems were basically the same: you sign up for a license, the vendor provides a disk for you to install software on your own local system or machine, and then you get to work.
If you needed to work late or on the weekend, then, you were at the office.
In contrast, with the advent of modern technology, “hosted” systems have recently become an option. Under this setup, the user does not actually install anything on their machine. They may log in to a remote workstation, or log on to a server, that provides them all the functionality that they expect. Or they may use a specific interface to connect with a separate server, where all the work is really done.
This is a throwback to the first-generation BBS systems many of us cut our teeth on. (Remember America Online? No? Must just be us then.) Back then, you turned on your computer, opened a connection to someone else’s computer, and played games that were housed over there. Like a game board on someone else’s dining room table.
That meant it was faster and easier for you to get started – you didn’t have to worry about whether you had enough memory or the right disk to install. All you had to do was log on, listen for the whiiiiiii-kshhhhh-TK-TK-TK-BING-BING-BING and you were good to go.
Similarly, modern actuarial systems allow for access anywhere.
This is especially helpful because many industries (yes, including actuaries) are recognizing the value of remote work. And, recently, the necessity of remote work.
This means that it may be inefficient to try to work through the old ways, either by having a license tied to a specific machine or connecting through a virtual private network. Modern actuarial systems understand this inefficiency and take advantage of technology to allow the actuary unprecedented access and corresponding productivity.
8. Aggregation
How much roll-up of results across various models do you currently do? How much would you like to do?
Aggregation generally happens across business units and even statutory companies. You may have a number of different models (such as Term Life, Whole Life, and UL) that are standard across various companies within the whole family (for example, Basic Insurance Co, Advanced Insurance Co, and Super-Duper Insurance Company).
In this instance, you may want to have the option to aggregate results at the company level for decision-making (such as investment strategy decisions) and financial reporting (Basic Term + Basic UL; Advanced Term + Advanced Whole Life; Super-Duper Term + Super-Duper Whole Life + Super-Duper UL). On a risk management level, though, you may need another option to aggregate final output data across all three companies: Basic + Advanced + Super-Duper.
Whatever flexibility or customization you will need to review results, you should certainly know that before you make a system decision. As well, this is also going to be based on the decision-making process for those models. If you don’t want your Deferred Annuity’s investment income to be influencing your Whole Life dividend payouts, then you need to run the projections separately.
If you can then combine the results easily to see the aggregate total, you’ll have a comprehensive view of your business with less effort than if you have to copy those results to a separate aggregator for analysis (which happens).
Figuring out how you want to make modeling decisions, and how you wish to view and analyze your model results, then, will become an important dimension of selecting a modeling system. You want one that either affords you the functionality you need, or at least offsets those additional headaches you’ll encounter by increasing speed, better interface, or some other typical drawback.
9. Data storage
So, once your models have run and been reviewed, what do you do with that? How do you maintain backup copies of your pricing or hedging runs after quarter-end? How long do you keep data readily available before archiving it?
How long do you keep it in a “first archive” before moving it to long-term storage? What if you want to pull data for an audit, a review, or just to rerun what you’ve done before? Will you need to include sign-offs and approvals to review?
Is that data secure from outside hacking? Is it protected from degradation? Could your competitors access sensitive assumption sets? Is everything locked-down to ensure nobody on the team changes it, either intentionally or unintentionally?
How and where your input and output data are stored is an essential element that you should consider when evaluating potential systems. It affects costs (hardware costs like the actual file servers, and time costs of whoever has to maintain that structure) and could delay your standard processes as well.Knowing both what you currently do with data, and what you want to do with your data setups will help you evaluate potential candidates for your actuarial modeling system upgrade.
Where SLOPE lands
Just so there’s no confusion, SLOPE has a pretty clear stance on all of those elements.
| DIMENSION | Where SLOPE lands |
|---|---|
| Cost | SLOPE is priced with a per-user annual license fee, which includes everything. You never have to pay for servers, equipment, or IT time. It’s all included. |
| Usability | SLOPE is an open system, which means users have access to change formulas, products, relationships, reports, etc. It’s all fair game. |
| Reputation | We have a collective 90 years’ worth of actuarial experience on the team, and software engineers who have helped build wildly successful platforms. We wouldn’t have built SLOPE unless we knew we could eliminate struggles actuaries face on a daily basis, and that the historical actuarial systems just weren’t going to be the way actuaries would work in the future. That confidence, competence, and forward perspective drive everything we do. |
| Responsiveness | SLOPE, as a new, nimble business, has the opportunity to adapt to our customer needs quickly. We release new versions every two weeks, so changes can be prioritized and implemented with unprecedented speed. |
| Products | SLOPE comes with a complement of standard products (life insurance, annuities, and assets). Additionally, because of the flexible nature of the system, you can add any exotic features or hard-to-model products as you wish. |
| Processes | SLOPE is designed for monthly future cash flow forecasts. This is great for pricing, valuation, and forecasting of long-duration liabilities (like Cash Flow Testing, Asset-Liability Management, Investment strategy, etc.). It is not designed for experience analysis or P&C ratemaking. If your actuaries want or need to have integration with a single system across the full spectrum, then maybe another vendor will be able to service those needs. |
| Access | SLOPE is a fully-hosted solution. The only hardware requirements are a computer with a web browser (and an internet connection, of course). That means you can work wherever you want, whenever you want. We take care of everything else. |
| Aggregation | Products can be run independently or in aggregate. Likewise, results can be viewed independently or in aggregate. Results can even be combined across various projections for comparison without copying to an external data analysis tool. |
| Data storage | Lifetime data storage is available for all SLOPE users. That is, we will continue to make your data as readily available in five years as it is right now. You don’t pay extra, either, for this feature. It’s all included in your annual license fee. |
Next Steps
Once you’ve defined your business according to these dimensions (and any others you determine are necessary to make a fair evaluation of your options), you can begin the process of vetting vendors. That’s quite straightforward – call up some and ask them where they stand, maybe get a demonstration, perhaps move to a pilot project (also called a proof-of-concept or an intensive evaluation).
Plot the alternatives on a grid, probably side-by-side and comparing pros and cons of each.
Once that’s done, though, you actually have to make the decision. In the next installment, we’ll offer some thoughts on how you should actually do that, once you’ve completed all your due diligence.