Checking sets and blocking points for underwriting issues

You can define checking sets and blocking points for each issue.

Checking sets are the places in a policy transaction where PolicyCenter checks to see if an issue needs to be raised. You specify a checking set value for each underwriting rule. For example, PolicyCenter checks for high-valued vehicles before quoting the policy.

Blocking points stop progress of the policy transaction until an issue is approved. You define a blocking point for each underwriting rule. For example, PolicyCenter prevents a user from binding a policy until high-value vehicle issues are approved.

Checking set values

In an underwriting rule, Checking Set specifies when to check for existence or absence of an underwriting rule. The evaluator classes further enforce which jobs check for that issue type. In some cases, PolicyCenter uses this value to filter issue types for display in the user interface.

The checking set represents the place in a policy transaction that a rule is checked.

The following table describes the checking set values in the base configuration.

Value	In UI?	Description
All		PolicyCenter checks this rule at all blocking points. PolicyCenter removes an existing underwriting issue if the evaluators do not trigger this type of issue. Issues created by this checking set may come from external systems in a way that is not necessarily synchronized with the job flow. For example, a claim system sends notice of excessive claims, or a billing system sends notice of a delinquent account. If you have an issue that cannot change once the policy is quoted (without re-editing the policy), do not use this checking set.
Manual	•	The underwriting issue is created when the user manually added an issue to the policy period. PolicyCenter displays Manual issues on the Risk Analysis screen.
MVR		For motor vehicle record underwriting issues. PolicyCenter checks for this issue at quote, quote release, bind, and issuance.
PolicyRenewalAPI	•	PolicyCenter checks this rule prior to calling policy renewal web services. Policy renewal web services provides methods for managing renewals in PolicyCenter.
PreBind	•	For underwriting issues that can only be detected immediately prior to binding the job. PolicyCenter checks this rule prior to binding.
PreIssuance	•	For underwriting issues that can be detected immediately prior to issuance. For submission policy transactions, PolicyCenter checks this rule prior to issuing the policy. If the policy transaction does not have an issuance step, PolicyCenter checks this rule prior to binding.
PreQuote	•	For underwriting issues that can be detected on the policy period even before quote, such as issues related to data entered in draft mode. PolicyCenter checks this rule prior to generating a quote.
PreRateRelease		PolicyCenter checks these rule underwriting rules after quoting and before the rate or quote is released.
PreQuoteRelease	•	For underwriting issues that need information from a valid quote or that can be detected after a valid quote. For example, use this checking set for issues that depend on the premium. PolicyCenter checks this rule after a valid quote, but before releasing the quote.
Question		For underwriting issues is based on answers to a question set. PolicyCenter checks this rule before quote.
Referral		For underwriting issues is related to underwriting referral reasons on the policy. PolicyCenter checks this rule at all blocking points. PolicyCenter displays these issues in the UW Referral Reasons tab of the Risk Analysis screen. You can also add a referral reason to a policy by using the `addReferralReason` API.
RegulatoryHold		For underwriting issues related to policy holds with the Regulatory Hold hold type. PolicyCenter checks this rule at all blocking points. The user is notified each time the job advances to the next step.
Reinsurance		For underwriting issues related to reinsurance. For example, you can use this checking set to raise an issue if a policy has insufficient reinsurance. PolicyCenter checks this rule at all blocking points except quote.
Renewal	•	For underwriting issues related to renewals. PolicyCenter checks this rule in renewal policy transactions at quote and issuance.
Upgrade		In certain cases, Guidewire uses this value when upgrading PolicyCenter. Do not use this value for any other purpose.
UWHold		Use for underwriting issues related to policy holds with the Underwriting Hold hold type. PolicyCenter checks this rule at all blocking points. Therefore, the user is notified each time the policy transaction advances to the next step.

The In UI column indicates the values that appear in the Rule screen of the base configuration. The TriggeringPointKey.TF_UWRULECHECKINGSETFILTER filter narrows the choices in the user interface. Modify this filter to add hidden values such a RegulatoryHold.

Except for All, a rule can be associated with only one checking set.

Checking set values correspond to the UWIssueType.CheckingSet property. The UWIssueCheckingSet typelist defines these values.

Blocking point values

In an underwriting rule, Blocking Point specifies the point at which this issue blocks progress of a policy transaction.

The blocking point values, listed in priority order from lowest to highest, are:

Value	Code	Description
Non-Blocking	`NonBlocking`	Sometimes referred to as informational issues. These issues do not block progress unless specifically rejected by a user.
Blocks Issuance	`BlocksIssuance`	Prevents issuance for submission policy transactions. Prevents binding for policy transactions that do not have a separate issuance step.
Blocks Bind	`BlocksBind`	The issue blocks binding the policy.
Blocks Quote Release	`BlocksQuoteRelease`	Allows quoting to be performed, but unauthorized users cannot view the quote until an underwriter has the opportunity to review and approve it. The job cannot progress further.
Blocks Rate Release	`BlocksRateRelease`	Block releasing a policy period rate. If two-step quoting is enabled in the policy line, this prevents the user from accessing the Quote screen. For example, although the policy is rated, you may not want the user to access the Quote screen until the policy has underwriting approval. In one-step quoting, this blocking point blocks quote release. The `BlocksRateRelease` blocking point is treated slightly differently from other blocking points. At the `BlocksRateRelease` blocking point, PolicyCenter only checks the `PreRateRelease` checking set, and does not check the `All` checking set. This is done for performance reasons, to make the first step of two step quoting execute quickly. If necessary, you can modify this behavior by making a change in the JobProcessUWIssueEvaluator class.
Blocks Quote	`BlocksQuote`	Prevents quoting and steps leading up to quoting. Use for issues that require intervention before the rating engine is called. You can use this blocking point for other types of issues, as well. However, if a policy transaction has a Blocks Quote issue, PolicyCenter will not call the rating engine, and the policy transactions remains in draft state. This blocking point also blocks rating, which is the first step in two-step quoting. Do not use for issues that need information from a valid quote. For example, do not use for issues related to total premium.
Rejected	`Rejected`	The most restrictive value. Rejects the issue. A rejected issue prevents the policy transaction from crossing any blocking point.

The blocking point corresponds to the UWIssueType.BlockingPoint property.

Note: Consider using the Blocks Quote Release blocking point rather than Blocks Quote. Some data, such as quote modifiers, are generated as a result of obtaining the quote. If this data triggers a Blocks Quote issue, the user may have difficulty resolving the issue. The difficulty is because the user interface, as a result of not permitting quote, may no longer allow the user to edit those fields.

Blocking points and checking sets are related, but not the same. In general, there is a checking set for each blocking point. However, there are other special checking sets as well as special blocking points. Issues need not have the same checking set and blocking point. For example, an issue can be created pre-quote, but not block until quote release or binding. The special blocking points are:

Non-Blocking – An issue does not block progress.
Rejected – A rejected issue blocks further progress because it prevents the job from crossing any blocking point.

In addition, there are blocking points for quote, quote release, bind, and issuance.

The blocking point values have a priority order. When the job is at a blocking point, the job progress is blocked by any open issue that blocks at that priority or at a higher priority. Generally, higher priority blocking points occur earlier in the job. For example, a job has been quoted and is waiting to be bound. A loss-control specialist adds a referral reason to the policy that blocks quote. The resulting issue blocks binding the policy, even though the Blocks Quote blocking point has already been passed. The user can approve the issue then bind the policy without needing to obtain a new quote. In the default configuration, raising a lower priority blocking issue does not invalidate already completed steps.