No. 129: Triangles on the Web

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.