Policy-Level Data Fields For Exposure

Why Policy-Level Fields Matter

An exposure calculation is only as reliable as the records behind it. A policy number alone does not establish how much coverage was in force, when it applied, or whether the policy belongs in a particular experience period. The analyst needs enough policy-level information to identify the relevant contract term, reconstruct covered time, and apply consistent inclusion rules.

Earlier material on exposure units and policy periods distinguishes the exposure base from the dates over which it is earned. Here the focus is the data needed to make those calculations from policy-level records. The examples use a hypothetical policy with one relevant exposure unit for its entire term. Where the exposure base is not one unit, the same record checks are necessary, but the base must also be measured in the appropriate units.

Identifiers and Record Grain

An identifier lets the analyst recognize the same contract across records. A policy identifier may persist across renewals, so it may not uniquely identify one policy term. A term identifier, or a combination of policy identifier and term dates, distinguishes a particular period of coverage. If a system stores policy changes as separate transactions, a transaction identifier or version number can help identify which record supersedes another.

Before calculating exposure, establish the record grain: what one row represents. A policy snapshot might contain one row per policy term as of a specified date. A transaction table might contain several dated changes for that same term. Confusing those grains can cause duplicate exposure. For example, summing a full-term exposure value from each of three transaction rows would count the term three times unless those rows represent disjoint exposure segments.

Identifiers also need operational checks. Look for missing policy or term identifiers, duplicate rows that appear to describe the same version, and transactions that cannot be linked to a term. Do not assume two rows are duplicates merely because the policy number matches: they may refer to distinct terms or different effective changes.

Dates, Status, and Policy Attributes

A policy record can contain several dates that answer different questions. The coverage effective date and expiration date define the stated term. The effective date of an endorsement, cancellation, or reinstatement indicates when a change applies. A transaction processing date indicates when the system recorded it, not necessarily when the change became effective. The valuation date states how far the data are observed or considered current.

For calculation, state a date convention. In the examples below, coverage intervals use the half-open form \([s,e)\): coverage applies on or after \(s\), and stops immediately before \(e\). Thus an expiration date of January 1 means the preceding December 31 is the final covered day. Day counts use the calendar days in these intervals. Other systems may use a different convention; it must be known and applied consistently.

Status is informative, but it is not a substitute for dates. “Active” might mean active when a snapshot was created, while a later cancellation transaction may have an earlier effective date. Conversely, a policy may show “canceled” today even though it was in force during an earlier experience period. Resolve conflicts using documented system rules and dated events; do not infer a past interval from a current status label alone.

Policy attributes can define which records are eligible for an analysis, such as a product code or jurisdiction. They may also describe the policy’s exposure basis. Their interpretation must match the intended calculation. A policy-level record may not provide enough detail when distinct parts of one policy have different coverage dates or exposure bases. In that situation, a single policy-level interval or attribute cannot safely stand in for all parts.

From Fields to Covered Time

For a policy with one exposure unit over its term, let \(D\) be the number of days in the term and \(C\) the number of covered days that fall within both the term and the experience window. Under a pro rata time allocation, the earned exposure for that window is the term exposure unit multiplied by \(C/D\). If there are cancellations or reinstatements, \(C\) is the sum of the lengths of the covered intervals, excluding any gaps.

This ratio follows because the method allocates a term’s exposure uniformly over its days. If each of \(D\) term days receives \(1/D\) of the term exposure, then \(C\) covered days receive \(C(1/D)\) of it. The result is a time-proportional allocation, not a claim about how risk varies within the term. It is inappropriate if the applicable exposure basis or earning rule is not proportional to elapsed time.

Worked Applications

Data Checks and Common Traps

A well-defined calculation should be reproducible from the source fields. Before aggregating exposure, check that each included term has a usable identifier, valid dates, an understood status, and the attributes required by the selection rule. Reconcile term and event dates, investigate duplicate or contradictory versions, and document how missing dates or conflicting status values are handled. A blank cancellation date should not automatically be interpreted as “never canceled” unless the data specification says so.

The most important traps are using a processing date as though it were an effective date, treating a current status as historical truth, counting multiple transaction versions as separate terms, and applying the wrong policy-attribute filter. Each can produce an arithmetically correct result from an incorrect set of records. Also verify that a policy-level record is adequate for the exposure being measured. If one record combines distinct coverage intervals or exposure bases, the calculation needs more detail than that record provides.