Policies, premium and exposure are three of the fundamental metrics in P&C insurance. Each of these metrics can be measured and summarized in several different ways. We’ll walk through the basic mechanics of policies, premium and exposure, how they are measured, and the circumstances under which each metric is appropriate.

## Basic Mechanics#

### Policies#

A policy is a contract between an insurer and an insured to transfer a well-defined risk from the insured to the insurer for a specific period of time in exchange for a fixed cash payment (the premium). Exposure is a rough measure of the amount of risk being transferred from the insured to the insurer.

For example, you may pay $500 to an insurance company for a six month auto insurance policy that runs from March 1st, 2022 to August 31, 2022. The premium associated with this policy is$500, and the risk being transferred is the risk that you will injure other people or damage other property while driving your car in the six months of the policy period. The exposure associated with the policy is 0.5 vehicle-years.

Premium is always measured in units of currency. For the sake of simplicity, we’ll use US dollars throughout this section, but we could use as well use pounds, euros, yen, rubles, or any other currency.

### Exposure#

Units of exposure differ depending on the insurance product. Private passenger auto insurance exposure is traditionally measured in vehicle-years, homeowners’ insurance is measured in total insured value, and workers’ compensation insurance is measured in salary paid. Some insurance products do not have consistent standards for measuring exposure – for example, some types of general liability insurance may use annual revenue; others (especially for retail businesses) may use square footage; but often exposure is not explicitly measured.

Note that exposure is an extremely crude measure of risk. If I drive my Honda Civic 5,000 miles per year and you drive your Lamborghini Huracan 100,000 miles per year, both of us have exactly one vehicle-year of exposure per year. However, our insurance premiums will almost certainly be quite a bit different.

## Dates and Intervals#

Before we discuss individual insurance metrics, it is worth taking a little time to discuss dates and units of measure. In economics and accounting, the difference between stocks and flows is well-understood: stocks are point-in-time measures of quantities, while flows are measured over an interval of time, and can be thought of as rates or speeds. The same distinction exists in insurance, although the terminology of stocks and flows is not nearly as common.

### Experience Dates and Periods#

For quantities that are stocks, such as the number of insurance policies in force at a given point in time, we refer to the point in time as an experience date. For quantities that are flows, such as the number of insurance policies written over a given period of time, we refer to the period in time as an experience period. Experience dates and experience periods are fundamentally different data types: experience dates are single points in time, whereas experience periods are intervals in time that are bounded by two dates.

Our standard convention inside Ledger is to represent dates via the ISO-8601 format (i.e., YYYY-MM-DD). We represent experience periods via the ISO-8601 extension for time intervals (i.e., YYYY-MM-DD/YYYY-MM-DD). We use the convention that an experience period starts at 12:00:00am on the first day of the period, and ends at 11:59:59pm on the last day of the period. For example, we would write the experience period March 2022 as 2022-03-01/2022-03-31.

### Evaluation Dates#

Another important temporal concept is the idea of an evaluation date. An evaluation date can be thought of as the logical “as-of” date that a metric is evaluated at. Evaluation dates are particularly important in an insurance context, because the value of any metric may not be known with certainty for a quite a long time after the end of an experience period. By using evaluation dates, we can clearly denote the logical date as of which the information is being calculated. Evaluation dates are always point-in-time quantities, and we represent them as we do experience dates, in the ISO-8601 format.

### Pull Times#

[Note: This section is Ledger-specific and very far in the weeds. Causal readers can skip this section.]

Finally, there is the concept of a pull time. A pull time is the wall-clock time at which we obtained data in our systems to compute a given metric. For example, we could pull earned premium for the experience period 2022-01-01/2022-03-31 and evaluation date 2022-06-30 at 2022-07-03T12:34:56.

There are two reasons we distinguish between pull times and evaluation dates. First, unless there is very good reason to do otherwise (such as an audit), pull times are almost always the wall-clock time that a metric request is made. However, computing metrics as of earlier evaluation dates is ubiquitous in insurance data.

Second, pull times are important for us because we generally receive data from risk originators on a lag. Within a risk originator’s production systems, computing a metric with all data on hand is equivalent to computing a metric with an evaluation date equal to today’s date. The same is not true for us! For example, if we get monthly bordereaux from a program 15 days after the end of the month, then we won’t be able to compute metrics as of evaluation date 2021-06-30 until 2021-07-15, no matter how badly we may want to. By distinguishing pull times from evaluation dates, we clearly distinguish between the physical and logical recency of the data.

## Policy Data#

We receive policy data in many different formats, and we store policy data in more than one format internally. For the sake of this material, we’ll present fictional policy data in a somewhat stylized format that captures a few key features of real policy data. As we get further into the weeds on policy data, we’ll progressively extend the data format to account for more real-world complexities.

### Policy Transaction Data#

In this set of examples, we’ll be working with policy transaction data. The complete history of a policy can be represented by a series of transactions that represent key events in the policy lifecycle, such as inception, renewal, endorsement (changes to the policy), and cancellation. Our initial policy data format is a table of records where each record represents a single policy transaction. (Recall that a single policy may have multiple transactions associated with it.) Each policy transaction has the following attributes:

• The policy number is an alphanumeric string generated by the originator that uniquely identifies the policy. Different originators use very different formats for their policy numbers: some are shorter and some are longer; some are purely numeric and some contain letters; some obviously try to encode information about the policy and others are completely inscrutable. We can generally assume that a policy number will be unique within an insurance program, but we can’t assume universal uniqueness.

• The policy effective date is the first date of the period during which the insurer will pay for covered losses by the insured.

• The policy expiration date is the last date of the period during which the insurer will pay for covered losses by the insured. We use the same convention for policy effective and expiration dates as we do for experience periods, so a policy in effect for the entire year of 2022 would have effective and expiration dates of 2022-01-01 and 2022-12-31, respectively. Within a given program, almost all policies will typically have the same duration. Most insurance policies in the US are one year long; private passenger auto insurance (i.e., personal auto) is a notable exception where policies are typically 6 months long.

• The transaction type code captures the sort of activity the transaction represents. For now, the only transaction type codes we’ll consider are NBUS, which is short for new business (initial sale of a policy), and RENL, which is short for renewal.

• The transaction effective date captures the date at which the transaction takes effect. For new business transactions, the transaction effective date is typically the same as the policy effective date. This is not true for other transaction types. For example, an endorsement transaction can take effect at any point during the policy period.

• The record date is the day the transaction was entered into the system. In general, the record date need not be the same as the transaction effective date. At new business, it is not unusual for a record date to be several days or weeks before its corresponding transaction effective date if a policyholder buys coverage from a new insurer shortly before their policy with another insurer is due to expire.