A Complete Guide to Policy Transactions in Guidewire PolicyCenter

Policy Transactions

The core of PolicyCenter revolves around the policy. Examples of policy changes are: creation of a new policy, renewal of a policy for a new term or cancellation of a policy. The only transaction not included in the slide is Audit. Audits can occur at any time during a policy term. A final audit can occur at the end of each policy term.

Review: Policy Transactions

1. Policy Change
2. Not renewed
3. Renewal
4. Submission
5. Policy
6. Policy
7. created
8. Expires
9. Policy ends
10. Cancellation
11. Reinstatement
12. Rewrite

Life Span of a Policy

Policy transaction graphs are useful when depicting the nature and behavior of complex transaction interactions, including reinstatements, rewrites, preemptions, and out-of- sequence transaction. The next slides are a version of the policy graph.

The question “When does a policy end?” does not have a universal answer in the insurance industry. Personal line insurers are more likely to view successive policy terms as a single policy, commercial line insurers tend to view each term as a “policy”. If you assume that a policy has a one-year term, but at renewal time a new policy number is not generated. (This frequently occurs, but is not always the case with every insurance company.) At the end of that year, the policy is renewed, and the policy retains the same policy number. Did the original policy end?

Some would say yes, that when the expiration date is reached, the policy ends. A new policy with the same number is created, but it is a different policy. Others would say no, if the two time periods are governed by a document with the same policy number, then it is in fact the same policy.

Policy Period – Guidewire Terminology

In PolicyCenter, a Policy Period is a copy of the entire policy after a job takes place which can be within a Policy Term (job = policy change, renewal, etc.). The copy of the policy includes policy information that was in effect prior to the job executing and reflects the new changes. There can be multiple periods within a term. For instance, each time there is a policy change, a new period begins on that effective date.

All transactions (including submissions) have a create, effective and close date.

• The create date is when the transaction was initiated. 
• Transaction close date or close date is the date the job was completed.
• Effective date is the date that the information in the job becomes legal and binding, as well as the date that the transaction becomes effective. For example, you could create and complete a submission today for an auto policy that will not take effect until Monday of next week. Today would be the written date, but Monday of next week is the effective date.

In some cases, the transaction close date comes before the effective date. For example, a submission job is typically completed before the policy goes into effect. In other cases, the transaction close date comes after the effective date. For example, a rewrite job that corrects a clerical error may be run several weeks after the policy has become effective, but the rewrite is effective at the start of the policy.

Issuance job always occurs with a submission job. There are times that a user may choose to bind a submission without issuing it. Perhaps additional information needs to be collected that binding does not require, but is required in order to issue the final policy contract such as the verification.

Policy change

A change transaction is referred to as a “policy change”. A “material change” is a change to a policy that affects what is covered. Policy changes typically involve material changes. Policy changes frequently involve a change to the policy’s premium.

Renewals

An insured may choose not to renew a policy because a better- priced policy was found elsewhere, or because the policy premium changed (possibly due to changes in the industry or due to claims made against the original policy) and the insured does not wish to pay the new premium. An insurer may choose not to renew a policy because the policy is considered financially unfavorable.

Renewals can be highly regulated from state to state. There are restrictions in some states relating to non-renewal due to losses. In addition, there are restrictions in many states related to rate increases on renewals in excess of a given percent. Most states have restrictions relating to the insurer non-renewing without providing a specified amount of prior notice. Renewal regulation at a state level are largely a consumer protection issue. It is focused primarily on personal lines (homeowners, personal auto) and is harder to place on commercial lines.

Cancellations

Cancellations are easier for the insured to execute than by the insurer. In many cases, the insured can choose to discontinue a policy and is not required to provide justification. However, an insurer cannot discontinue a policy unless they can demonstrate just cause, such as non-payment of premiums, purposeful inaccurate information provided at the time of submission or fraud.

Rewrites

A rewrite involves a change to a policy that is significant enough that it cannot be captured with a policy change. Although there is no absolute rule in the insurance industry that dictates when something must be done as a rewrite versus a policy change, there is at least one common use case for this type of transaction: People who work for the insurer may make clerical errors when entering policy information. For example, during a discussion with an applicant, the underwriter might have agreed to provide a certain type of coverage but forget to enter it into the policy system. The forms issued from the submission job are incorrect, and the insured may prefer to have a new set of forms drafted so that they have physical proof of exactly what was covered. In this case, a rewrite is required. If the requirement was to make the change, then a policy change satisfies the requirement. This rewrite must have an effective date as of the start of the policy.

The rewrite feature allows you to perform a Full-Term Rewrite which replaces the original policy for the complete policy term.

Mid-Term Rewrites

A mid-term rewrite replaces a portion of the original term and allows you to rewrite the policy to the original policy end date or to a new end date. Every transaction has two different dates:

⚫ transaction close date or close date – the date the job was completed.

⚫ effective date – the date that the information in the job becomes legal and binding.

In some cases, the transaction close date comes before the effective date. For example, a submission job is typically completed before the policy goes into effect. In other cases, the transaction close date comes after the effective date. If a rewrite job corrects a clerical error that ran several weeks after the policy has become effective, but the rewrite is effective at the start of the policy.

Rewrite New Account

Rewriting a policy to another account means moving the policy going forward to another account, but the policy history including earlier policy terms stays with its current account. For example, a young adult has a policy under his parent’s personal auto account. He graduates from college, and wants to move his policy to his own account. The insurer cancels his policy, and rewrites it to his new account.

When the user chooses to rewrite a policy to a new account, a rewrite new account job is created on the new account. This job takes data from an existing policy and creates a new policy with a new policy number in the new account. The policies on the new and old accounts cannot overlap. No policy transaction can be created on the source policy for a date later than the rewrite date (effective date of the rewritten policy). The policy does not exist on the source account after that date.

Unlike a rewrite job, a rewrite new policy job can have qualification questions. Qualification questions are discussed later in this Guidewire course.

History of a Policy

If a policy is created, not modified, and then either canceled before the renewal date or not renewed at the expiration date, then the policy did not change over time. In all other circumstances, the policy changes over time.

PolicyPeriods

The PolicyPeriod entity stores information for a specific revision of the contractual period of a policy. Every change in the policy is represented by a PolicyPeriod, which is cloned during policy changes, renewals, or other jobs. The cloned branch is updated with the changes and will only be visible when a user views a policy from that branch’s effective date. The cloned branch becomes the base for future changes.

A revision takes place when a job occurs on a policy. The submission creates the first revision. Each additional transaction on the policy creates a new revision. Therefore, a policy usually has multiple revisions, with one PolicyPeriod entity for each revision. During the contractual period, only one PolicyPeriod entity is in effect at a time.

In the example, a new revision is created when a policy change is processed that adds a car to the policy. The EffectiveDate for the car is several months into contractual period, and the ExpirationDate extends to the end of the period. PolicyCenter clones a new PolicyPeriod entity and its sub-entities and adds an entity for the new car. The contractual period now has two PolicyPeriods. The new PolicyPeriod entity is in effect. The old PolicyPeriod entity is preserved as a historical record of the policy.

End Results of a Renewal Job

Definitions: Non-renewed: An insurer might choose not to renew a policy since the policy is considered financially unfavorable (e.g., too many claims filed against the policy). Renewals can be highly regulated from jurisdiction to jurisdiction, including restrictions relating to non-renewal due to losses. There are also restrictions in many jurisdictions related to rate increases on renewals in excess of a maximum percent. Finally, restrictions exist in almost all jurisdictions relating to the insurer non-renewing without providing a specified amount of prior notice. Renewal regulation at a jurisdiction level is a consumer protection issue and focuses primarily on personal lines (homeowners, personal auto). It is much harder to place on commercial lines.

Not taken: An insured may choose not to renew a policy because they found a better- priced policy elsewhere, or because the policy premium has changed (due to changes in the industry or claims made against the original policy).

Short-term renewal (not shown): In some cases, a policy may be renewed “short term”; the policy is renewed but it is not renewed for the full term (typically for a small fraction of the full term). One common situation where this occurs involves cancellation. When an insurer cancels a policy.

Renewal Process

The renewal job can be started automatically by the start renewal batch job, which searches for policies expiring in X days and begins the renewal process. It can also be manually started from the user interface. Both batch jobs and the manual process will start the same renewal workflow.

The renewal workflow is an automated process which quotes the renewal, checks conditions or sends documents at various times. When it reaches the effective date of the new term, it completes the renewal job. If the renewal job has a non-renew or not-taken pre-renewal direction, it will end up in a state of non- renew or not-taken. Otherwise, it is automatically bound and renewed.

The automated renewal workflow may be manually interrupted by editing the policy transaction. This normally occurs when the underwriter or agent wants to make changes to the renewal job. The renewal job can take a different path, from non-renew to renewed or vice versa. Before the renewal is quoted again, you have the option to non-renew or not-taken even though there is no pre-renewal direction. This completes the renewal job.

After you manually quote the renewal job, there are two bind options. In this path, a renewal job that starts with a non-renewal or not-taken pre-renewal direction.

Read Also – Guidewire Policy Center