Monthly Archives: September 2018

A triangle is a data structure commonly used by actuaries to estimate reserves for insurance companies. Without going into too much detail, a reserve is money that an insurance company sets aside to pay claims on a book of policies. The reason why reserves must be estimated is due to the uncertain nature of the business – that is, for every policy sold, it is unknown at the time of sale whether or not the insured will suffer a claim over the policy period, nor is it known with certainty how many claims the insured will file, or how much the company will have to pay in order to settle those claims. Yet, the insurance company still needs to have funds available to satisfy its contractual obligations – hence, the need for actuaries.

Triangles are popular amongst actuaries because they provide a compact summarization of claims transactions, and are an elegant visual representation of claims development. They are furthermore amenable to several algorithms that are used to estimate the reserves, such as chain ladder, Bornhuetter-Ferguson, and ODP Bootstrap.

I had originally set out to do something more ambitious for today – that is, to automate the production of browser-based triangles via JavaScript, but I’m not quite there yet with my studies in the language, and moreover simply setting up pieces of the frontend involved enough work and learning to merit its own post.

Today, I’ll go over the visual presentation of actuarial triangles in HTML, while later posts will cover automating their production via JavaScript, JSON, and backend calculations.

Below, you’ll find a table of 15 claims, taken from Friedland’s text on claims reserving. The Claim ID is simply a value to identify a particular claim. The other two columns have the following definitions:

• Accident Date

The accident date is the date on which the claim occurs. For example, if you were driving on January 5 and had an accident during that trip, then January 5 would be the accident date.

• Report Date

The report date is the date on which the claim is reported to the insurer. If you were driving around on January 5 and had an accident during that trip, but didn’t notify the insurance company until February 1, then February 1 would be the report date.

You may be wondering why actuaries would care about the distinction. In the table below, you see that at worst, claims are reported only a few months after they occur. In certain lines of business, however, claims can be reported even many years after they occur. One example would be asbestos claims, in which cancer may not develop until many years after exposure to the substance. Another would be roof damage resulting from storms, in which the homeowners may not know that their roofs are damaged until the next time they climb up to go see, which may happen some time after the storm in question.

There really isn’t much to it, but I did learn a few things here. In particular, the HTML attribute colspan was used on the top row header to merge the top few cells together. Furthermore, I altered a ruleset to this site’s CSS, which centered and middle-aligned the text within the table:

While the above table is straightforward to understand, there isn’t much that you can do with it. First, there aren’t any claim dollars attached to those claims, so we won’t be able to perform any kind of financial projections if there aren’t any historical transactions. Second, even after getting the transaction data, the presentation can get messy because the order in which transactions occur don’t always coincide with the order in which claims occur or are reported.

We see that this is the case in the table below, which shows the historical transactions for this group of claims. The first payment for claim 9 occurs before the first payment for claim 4, even though claim 4 occurred first.

A more visually appealing representation orders the claims chronologically by date of occurrence, while ordering the transactions horizontally by date of payment.

I’ve picked up a few pieces of syntax here, as not only have I made use of the colspan attribute, but also the rowspan attribute, allowing the first three subheadings of the table to occupy two rows each. Furthermore, I’ve added horizontal lines to visually separate the claims by accident year, by adding a new ruleset to the site’s CSS:

Finally, although the above table provides a better description of the book of business, it is not compact, and nor is it in a form that is amenable to reserving calculations. Below is a table that aggregates the transactions by accident year, on an incremental paid basis. Below that, is a similar table, but stated on a cumulative paid basis.

While I’ve got the visual representation of what I want to achieve here, there’s still quite a bit of work to do. As you can see here, there’s a lot of repetition, and hardcoded redundant values in the code. Indeed, I caught several errors prior to publishing this post. Next, I’ll aim to streamline the production of these tables via JavaScript with the following tasks:

1. Store claims data as a JSON object

Repetition increases the chance for error – for example, you can see that I’ve repeated several bits of data such as the accident date for many of these claims. It’s better to store them in one location, perhaps as a JSON object.

2. Write a JavaScript function to read the JSON, construct the tables, and populate the tables

The tables above took a lot of copying and pasting of HTML tags. It would be more efficient, and less error-prone, if I automated the construction of these tables with a function.

I’ve got a few side projects going on, one of which involves creating a web application for some of the actuarial libraries I’m developing. Since I have a bad habit of quitting projects shortly after I’ve announced them to the public, I’m going to wait until I’ve made some progress on it. In the meantime, I’d like to talk about some of the tools that I’ve had to learn in order to get this done – one of which is JavaScript.

I came across JavaScript a many years ago, back when D3.js came out. Upon seeing D3 for the first time, I was immediately amazed at how beautiful the examples were – so much so, that I decided to learn it myself. However, I found the learning curve to be steep, and it soon became apparent to me that I was going to have to learn a lot if I wanted to get good at it. This meant that I would have to take a step back and learn JavaScript, the language underlying D3. Today, I won’t be talking about D3, but I will go over some of the JavaScript that I’ve learned so far, particularly the flotr2 library.

While the charts that I’m showing you today are simple, constructing them is deceptively challenging. The reason why is that producing high-quality graphics (and later, high-quality dynamic graphics) on the Web requires a large body of prerequisite knowledge, including but not limited to:

• HTML

HTML, or HyperText Markup Language, is a markup language that dictates the logical structure of a web page. The structural components that you see on this web page, such as paragraphs, titles, headers, and links, are dictated by HTML tags.

• CSS

CSS, or Cascading Style Sheets, is a style sheet language that dictates the aesthetic layout of a web page. The stylistic features of this web page, such as fonts, colors, margins, etc., are dictated by CSS rule sets.

• JavaScript

JavaScript is a programming language used to create dynamic web pages that respond to user interaction. You may have seen some websites load different charts depending on what the user does. There’s a high chance they were driven by JavaScript.

• Artistic Ability

Many books have been written on the three subjects above. I have encountered many programmers who have spent hours upon hours reading as many books on HTML, CSS, and JavaScript, only to end up producing horrible-looking charts when they try using something like D3,js. Why do their charts look so terrible, when they possess all of the prerequisite technical knowledge to produce them? One reason why, is that they lack artistic ability. Not only would you need to know three languages, but you also have to be skillful in graphic design. The ability to choose an appropriate color palette, careful selection of margins, and subtle placement of graph elements are required.

• Domain Knowledge

Lastly, if you’re going to present something, you really need to know what you’re talking about. I have spent many years trying to become a subject matter expert in actuarial science. However, this post isn’t about that, but moreso about visual presentation. But still, you should have some substance to your methods, if you want to be able to back up your claims.

Early in my career, I recall an executive telling me that there are a lot of smart people out there with brilliant ideas, yet they fail because they can’t communicate those ideas clearly and concisely, nor can they persuade anyone.

Humans can be irrational creatures, and aren’t always persuaded by facts. I’ve taken this advice very seriously, and these days my strategy is to use good visual and oral presentation skills to persuade people – while simultaneously carrying out the technical work behind the scenes to a high level of standard, so that I can back my claims up if examined thoroughly.

Now, you might ask, why should I bother learning all of this stuff when I could have just mocked up a bar chart in PowerPoint, and copy-and-pasted it here? There are many good reasons – first, it would make for a very boring blog post, and second, I have greater ambitions for using these technologies in the development of web applications, and not just a one-off blog post. In a web application, the data underlying the charts are stored in a backend database, and explicitly defining the data transfer routines and parameters of those charts via code enables the automatic loading and rendering of charts – when you have thousands of users, the technical way becomes much more productive. Third, reproducible research is a core tenet of the scientific method. Good code can be self-documenting, and being able to reproduce experiments via the execution of well-maintained code will help you justify and defend whatever it is that you’re trying to prove.

flotr2
flotr2 is a JavaScript library that produces simple charts. I plan to transition to D3 later, but I think it’s a good tool for people who are new to JavaScript. Sadly, the two charts that you see below are the culmination of over 500 pages of reading. 400 of those were on HTML and CSS, which I read way back to produce this website that you see here. The other 100 come from some pieces of JavaScript that I read in a web application development book, and from another book that I’m reading on data visualization with JavaScript.

CSS and JavaScript
The examples below depend on two scripts. One is the same CSS script underlying the webpage, and the other is the flotr2 library, stored in a JavaScript file. I’ve placed both these files on my server, and I’ve linked to them in my web page:

The following chart, is generated by the script below it. The data are arbitrary, but you can see here that the parameters corresponding to what you see in the cart, are specified in the code (expense data, title, colors, etc.).

Now we can change some things up. Let’s say instead of expenses, we want losses. I’ll do that by changing up the title, variable names, color, and data points: