Policy revisioning

An insurance policy may change one or more times during its lifetime within PolicyCenter.

Policies may change in the middle of a period due to:

  • Adding a driver to a policy
  • Changing coverage amounts
  • Adding a vehicle
  • Canceling the policy
  • Reinstating the policy

The complete history of all policy changes in legally-binding policies must be carefully tracked, not merely stored in the latest version of the policy. The policy history might be needed for legal auditing, customer service, financial reports, or tracking how much to charge customers for a change.

PolicyCenter stores the policy history as a series of policy revisions. Policy revisions are like snapshots of the policy on date the revision was bound (when it became legally binding). When a revision is bound, that revision represents the legally-enforced truth of that policy for all effective dates within a single policy period. However, PolicyCenter preserves older versions of the truth for that policy as historical records. Both the enforced versions and the historical versions persist and can be used or compared as needed.

In PolicyCenter, policy revisions are often referred to as branches. You can think of a branch as a graph of objects with PolicyPeriod at the root. The branch collectively represents a policy for one contractual period as of one moment in real-world time.

To track policy changes over time, a policy must be considered in two different time dimensions:

Dimension

How PolicyCenter uses this dimension

model time– The actual real-world time when policies are created or jobs (policy transactions) are bound. This is like tracking the history of previous changes in any online system that has an audit trail.

When a branch is bound, PolicyCenter sets its branch model date to match the real-world date it was bound. Additionally, PolicyCenter increments the policy revision’s model number, which is an integer value that indicates the relative order of multiple versions of the same contractual policy revision. The bound revision with the latest model number is always the currently-active legally-enforced policy revision for that effective time range. Changes that happen later supersede earlier versions of the policy for the policy period’s effective time range. However, PolicyCenter keeps older branches in the database. Older branches are required to view the policy history. Use this to generate reports of the legally-binding state of the policy at a model date earlier than today.

effective time – The time dimension of the policy itself within the policy period. For example, what time range does the policy cover? This dimension of time is unique to a policy system.

If the policy period is one year, each PolicyCenter policy period records the policy information for one year of effective time. Some objects on the policy may only exist for some range of effective time, or have different property values for different ranges of effective time.

To contrast the two dimensions of time, suppose a customer calls on March 1. The customer wants to add a car to the policy as of the beginning of the next month, April 1st:
Model date
March 1
Effective date
April 1, effective until the end of the period
Important: Be sure you understand the differences between effective time and model time before proceeding through this topic. These concepts are extremely critical for understanding the complex sequencing issues discussed later.

Model time examples

The following are example of model time:

  • A customer takes out a policy on a red car. Later the customer calls and apologizes and says it is a blue car. Yet again the customer calls and says the car really is green. The policy covers the same policy period with the same effective time but there are three different model dates with changes.
  • Policy reports run every quarter must reflect the state of policies on the last day of each quarter, which is the model date. However, you may not run the report until several weeks later. It is important that the system can query the policy as of a specific model date and ignore all changes made later (in actual time) after the model date.

Effective time examples

The following are examples of effective time:
  • A policy covers one car for an entire calendar year. Halfway through the year, the insured individual buys a used car. The policy covers the first car for the whole year of effective time. The policy covers the added car for the second half of effective time.
  • A change to an effective date in the future: a customer calls to say they will add a car to the policy as of the beginning of the next month.
  • A change to an effective date in the past: canceling a policy effective last month.

Policy in model time versus effective time

The following diagram shows a policy across model time and effective time.