Guidelines for designing underwriting rules
You design underwriting rules in the screen. PolicyCenter uses these underwriting rules to create underwriting issues on policies. In addition, you can use Gosu code to implement underwriting rules. For example, you can use Gosu code for underwriting rules with rule conditions too complex to define in the Rule Condition editor.
When defining underwriting rules for your implementation, determine whether to modify or remove existing underwriting rules, and whether to add new underwriting rules.
To define underwriting rules, consider the following questions.
- What is the purpose of this underwriting rule? Does the rule raise an underwriting issue when the driver is more than 80 years old? Or does the rule raise an issue when the business prepares fried foods?
- How do you detect when the underwriting rule creates an underwriting issue? For example, which fields on the policy period trigger creation of this underwriting issue? What logic determines triggers the creation?
- Must you raise an issue based on conditions outside of a policy transaction and policy
data? If so, you may need to create an
underwriting referral reason. The underwriting
referral reason triggers creation of an
underwriting issue.
See Underwriting referral reasons raise underwriting issues.
- What type of value is associated with this underwriting issue? Does the value affect
which underwriters can approve that issue?
A value can be a number, a currency amount, a jurisdiction or set of jurisdictions, a class code or a range of class codes. It can also be another type of value that can be easily represented as a string.
An underwriting issue requires a value if that value affects which underwriters can approve it. For example, suppose you have an underwriting rule Driver is under 25 years old. If the same set of underwriters can approve the issue whether the driver is 17 or 24, then the rule does not need a value. However, suppose some underwriters can approve the issue if the driver is at least 21, but others can approve the issue when the driver is only 16. In this case, use the age as the value associated with the underwriting issue.
You can set values for underwriting rules even when not required. For example, if age is not strictly necessary, there is no harm in associating it with the underwriting rule. In the default configuration, the underwriter sees the value when PolicyCenter displays the underwriting issue.
- If there is a value associated with this underwriting issue, can you use an existing value
comparator?
In the base configuration, PolicyCenter provides value comparators for numeric values and for jurisdictions. You can add additional comparators if necessary. Adding a new value comparator is complex. Therefore, consider carefully before adding a new one.
See Comparing issue values, and Adding a new value comparator.
- If there is a value associated with this underwriting rule, can you use one of the existing
value formatters?
In the default configuration, PolicyCenter provides value formatters for integer, currency, jurisdictions, sets of jurisdictions, and string values. If these formatters are not sufficient, you may need to add a new value formatter. Although not as complex as adding a new comparator, consider carefully before adding a new one.
See Business rule: value formatter typeAdding a new value comparator.
- Which policy transaction types will check for this underwriting issue?
The checking set for the underwriting rule determines when PolicyCenter checks for the issue. Determine the policy transaction types (such as submission, renewal, issuance) that will check for and raise this underwriting issue. Within each policy transaction, determine which transition points (such as quoting or binding) check the underwriting rule. Does the policy transaction check this underwriting rule at one point or multiple points?
In the base configuration, underwriting issues are available in submission, issuance, policy change, reinstatement, rewrite (includes rewrite new account), and renewal policy transactions. Through configuration, you can extend underwriting to other policy transaction types, such as cancellations. For more information about which policy transactions provide underwriting in the base configuration, see Common features of policy transactions.
Underwriting issues that will not change after quoting may be checked for only at quoting. There is no reason to check the underwriting rule again unless the policy needs re-quoting.
Other underwriting issues require multiple checking sets. For example, suppose PolicyCenter receives payment delinquency information from a billing system. You can raise the underwriting issue at the next transition point (quoting, binding, issuance) no matter when it is checked for.
Note: In general, Guidewire recommends that you raise underwriting issues as early in the policy transaction as possible.See Checking sets and blocking points for underwriting issues, Checking sets and evaluators.
- Does this underwriting rule block progress of the policy transaction?
Consider the point at which the underwriting issue blocks progress. For example, a rule checks and raises fire hazard issues before quoting a policy. If these issues are not approved, the policy transaction cannot be bound. The issue has a blocking point at bind
See Checking sets and blocking points for underwriting issues and Blocking points.
- Is the underwriting rule too complex to be implemented in the Underwriting Rules user
interface?
- If just the rule condition is too complex, create a custom utility function to implement the rule condition. In the Underwriting Rules user interface, have the Rule Condition call this utility function.
- If the underwriting rule has outcomes that are more complex than just adding an underwriting issue, use a Gosu implementation.
See also
