Skip to Navigation Skip to Main Content Skip to Footer
Actuarial Modeling

Cycle Time vs. Runtime(5 min read)

Actuarial work is an iterative process. Exploring “what if”s and answering questions that have been asked of you leads deeper and deeper into the numbers. And in order to begin digging into those numbers, they first need to be calculated. Optimizing models for runtime has long been a focus for actuaries, and it makes sense – if work can’t continue until calculations are complete, reducing that time to the shortest possible allows the next set of analysis and iteration to begin sooner.

The issue is that model runtimes are only one small piece of the actuarial puzzle. Researching the needs of the model, building or modifying calculations, running the model, understanding and communicating the results, and returning to the model with a new set of changes all add up to its cycle time – the time it takes to complete an iteration of a model.

Cycle time is the key metric that drives the work of an actuary. If an iteration takes two hours to complete, then there is a hard limit to the number of “what if?” questions that can be answered in a working day.

The Obsession with Runtime

So if cycle time is so important, why is there such an intense focus on runtime?

There are three factors that clearly contribute to this mindset when actuaries assess a platform’s capabilities. The first is that runtime is the most tangible part of the process. An actuary knows exactly how long the model took to run once the results are in. If optimizations are successful, it’s very clear whether the number is lower than the previous run’s or not. 

The second component is the growing demand for calculational intensity from increasingly complex products and regulatory standards. Models need to run through more and more calculations to satisfy these needs, leading to greater runtimes. It can become impossible to complete work in a timely fashion if runtime efficiencies aren’t addressed.

A sign that says "waiting", representing what runtime is

Finally, runtime is ultimately just…waiting. There is nothing else to do until results are produced, so progress on the model’s cycle comes to a halt. No analysis can be completed, no further testing can be implemented before you actually know the impacts of your latest iteration. 

However, it’s important to acknowledge that actuaries are rarely working on a single aspect on a single model. While runtime is still waiting time for one problem, it’s also time that can be spent addressing others. Even though there are ways to dramatically cut runtimes, it’s important to consider your platform’s effects on every part of the actuarial cycle.

Can Platforms Address Cycle Time?

Managing assumptions

Assumptions should be centralized and standardized within the platform itself. This allows users to quickly identify which sets and historical versions of assumptions were used to create a set of results automatically without relying on users to manually create an audit trail. If these exist externally, it is now on the company to develop, house, and maintain a system to track this information which is both time intensive and prone to user error. Documentation of processes like these often ends up as the last step (if it’s done at all). It quickly becomes outdated and unhelpful if it isn’t kept up to date with changes made.

A stack of ring-bound books, representing the challenges that documentation can impose on reducing cycle time.
If only it were ever this organized.

Understanding models

Models need to be easily decipherable, and those written in proprietary code take longer to read, understand, and debug. Platforms that are “black boxes” and close off most access to the actuarial model make these processes even more difficult. In response, actuarial practices often are forced to create their best estimate of a replica in Excel or some other external tool in order to validate results, which is far from a good use of actuarial time. This ultimately doubles the workload of maintenance; all changes to the model now happen twice, increasing your cycle time.

Getting results quickly

Platforms that make use of cloud bursting or other hybrid computing techniques require additional time that can significantly add onto the waiting period associated with runtime. Sending an entire model’s worth of data up to the cloud and pulling the results back down are resource-intensive processes. A platform that takes advantage of the cloud should be cloud native itself in order to gain the most benefit. 

Communicating results

Once a run completes, are there additional steps to take in order to get results into a usable format? If your platform only provides limited (or no) reporting capabilities, that means that there will be some sort of ETL process that will take additional time that further slows your model’s cycle time. Cleaning up and transforming data to load into a business intelligence tool will either take manual intervention or maintenance of an automated process.

A better solution would be to have embedded, flexible analytics that allow actuaries (and other model stakeholders within the company) to begin their analysis immediately upon run completion. The ability to jump immediately into pre-built dashboards or quickly build ad hoc reports without having to incorporate an additional tool will save time, budget, and documentation.

Automating processes

With a constantly growing workload, actuarial platforms should be automating regular processes such as kicking off quarterly valuation runs, greatly reducing the effort required to manage them. Making use of Application Programming Interfaces (APIs) to connect your platform to other upstream and downstream applications enables actuaries to pull updated assumptions from admin systems, load them into the model, kick off a run, and produce results to send to downstream ledgers or data stores. 

Benefits of Low Cycle Time

With long cycle times, actuaries are constantly back on their heels, trying to keep up with regulatory and business requirements. It’s difficult to make use of new information in real time. By the time you process and analyze your results, the window to respond to it may have already closed. (One of our clients had this very issue with their previous solution!)

Reducing cycle time will produce the opposite results. With the extra time afforded to your actuaries, they can iterate far more frequently, allowing for better, more thorough analysis. And when there is a time-sensitive matter, they can be significantly more responsive to new information. Upper management will certainly be appreciative of shorter response times, time-to-market, and timelines for answers to their “what if” scenarios.

What’s Next with Cycle Time?

So what do you do with all of this? We’d recommend taking a look into your own cycle times. Assess where your platform is helping (or hindering) your efforts to optimize processes. If you’re not happy with what you find, it might be a sign that you need a new actuarial system. Fortunately, we’ve got a 7-part series on successful actuarial model conversions – take a look!