Career | Sitemap    

Consider a Career in Actuarial Software

By David P. Friedlander

Looking for a change in direction? Software may be calling your name.

Half of my job as a chief actuary at a software company is to help de­sign software that complies with the Actuarial Standards of Practice and the applicable laws and regulations. Then I have to make sure the end product is in accordance with the designs. The other half of my job is to train and support the software users.

Today, nearly all actuaries use comput­er software and most use software tools that are designed specifically for actuar­ies. Some are at least partly designed by their fellow actuaries. However, actuaries are also frequently involved in the design of software tools that are used mainly by non-actuaries. If you’re an actuary who enjoys working with computers, this could be the career path for you.

Communication Skills Are Key

My own firm is always looking for the few people who have that elusive combi­nation of actuarial, communication, and technology skills that make it possible to work smoothly with both the technol­ogy who actu­ally develop the code and the cli­ents who use it. For our company, those end users are employee benefits profes­sionals. However, other software firms that employ actuaries produce tools used by life insurance actuaries, casualty actuaries, underwriters, and others.

Those of us who work with software firms find ourselves both training and supporting the actuaries and actuarial assistants who use the software. These people are usually well versed in actu­arial principals but often know very little about computers. We also need to pro­vide design specifications to technology professionals who know far more than we do about computers but may not know the difference between an actu­ary and a mortuary. Therefore, we need all of the communications skills that a consulting actuary needs as well as an understanding of computers.

In order to communicate ac­tuarial principals to tech­nology professionals, we need to have a very thorough understanding of those principals. It’s the same kind of understand­ing required to pass actuarial examinations, although, unlike some other environments in which actuaries work, software firms usually consider the quality of their work much more important than examination-based credentials when they judge their employees.

A software product has to anticipate many different scenarios, some of which probably were not included in the lim­ited number of questions that could be included on an examination. For exam­ple, a product that calculates optional forms of pension benefits has to account properly for the participant whose bene­fits are the regulatory maximum benefit under the normal form of payment but not under the selected optional form and vice versa. On the other hand, it also has to account properly for the person whose benefit is so small that the option isn’t permitted at all, along with the vast majority of cases that fall between these extremes.

As an actuary who has been in the software development environment for 30 years, I’ve witnessed incredible changes in the data processing environ­ment. In this field, the one thing that’s certain is change, so one has to be very flexible.

In the 1970s, almost all actuarial soft­ware resided on mainframe computers, often the so-called super computers (far from “super” by 2005 standards) that were manufactured by the now defunct Control Data Corporation. In those days, programs were laboriously created on punch cards, one instruction per card, and woe to anyone who dropped one of those decks if the cards weren’t properly numbered!

By the early 1980s, much of the soft­ware had migrated to mini-computers manufactured by other poorly remem­bered companies such as Prime Comput­ing and Digital Equipment Corporation. I still remember authorizing a purchase in 1982 for a 300 megabyte disk drive that was the size of a desk, had a remov­able disk platter weighing more than 50 pounds, and cost about $20,000. (Today, a $300 MP3 player has 100 times more disk space, fits in my shirt pocket, and weighs 4 ounces.)

Later in the 1980s, the tools appeared on DOS-based personal computers. Of course, personal computers still domi­nate today, although DOS is nearly for­gotten and has been replaced by vari­ous versions of Windows. Each of these advances, along with the well-known changes in the regulatory environment, has required that the software tools be largely rewritten and, therefore, has cre­ated new opportunities for those of us in the software development field.

In addition to these changes, the tools themselves have become far more complex, so that it now requires a team of technology professionals to write the actual code. By comparison, as recently as the 1980s, actuarial software firms were often staffed entirely by technolo­gy savvy actuaries and employed few or sometimes no technology professionals. In those days, all that was expected of the tools was that they produce the cor­rect answers. Output didn’t need to be attractive because it was manually tran­scribed before delivery to the end user and nobody expected results to arrive in less than an hour.

Today, we expect instant results that can be conveyed to the end user and with almost no work to be done by the operator of the tools. We also expect ev­erything to run remotely via the Internet. What all this means to actuaries who work at software firms is that we have to communicate our science to technology professionals instead of write code. Com­munications skills have become more im­portant to us than programming skills.

None of this means that anyone can work at a software environment without understanding data processing. We still have to know how to write program­ming specifications that are acceptable to technology professionals, and this requires an understanding of database technology. Modern databases are ac­cessed using a tool called SQL (some­times pronounces as Sequel) and it’s very helpful for actuaries in this environ­ment to know that tool. It’s also very use­ful to be able to read and “debug” actual code and even to be able to write small patches of that code (often referred to as “entry point programming”).

Breaking the Code

Programming code is written using tools called programming language, so these skills require a familiarity with those tools. The most modern code is written in the following languages: C++, C# (pronounced C-Sharp), DELPHI, Visual BASIC, and FORTRAN. However, we often also have to work with older code that can be more economically maintained than rewritten. This code is also written in FORTRAN, BASIC (the predecessor of Visual BASIC) and PASCAL (the prede­cessor of DELPHI). However, it may also be written in dying languages such as COBOL and APL, so it’s useful to know those too.

It’s also worth noting that the majority of actuaries who work in software devel­opment companies are either enrolled actuaries or associates of the Society of Actuaries or the Casualty Actuarial Soci­ety, rather than fellows of those organi­zations. Because it’s one of the areas in which an actuary can work without pass­ing as many examinations, the extra time we spend learning about computers may be at least partially offset by fewer hours of formal studying.

To summarize, working at a software company is a choice to consider if you’re a strong technical actuary with excel­lent communications skills, you’re able to deal with frequent changes to the environment in which you work, and if you enjoy working with computers and know more about them than most of your fellow actuaries. It’s an option that may not require completing all of the fellowship examinations if you have technical strengths that offset a lack of credentials.

David P. Friedlander is principal and chief actuary at Lynchval Systems Worldwide in Chantilly, Va.

Product Request

You can request a free demonstration of any of our products here...

Request Demo

Help Desk

Our best-in-class services are here for you.

Contact Us