Coding your actual rating algorithm

Consider encapsulating your actual algorithm into separate Gosu classes, one for each type of premium.

Wherever you put your actual rating algorithm, Guidewire strongly recommends that you cleanly and clearly separate your rating logic into two parts.

  • Data from lookup tables, which typically insurer business users manage
  • Programming logic in rating formulas, which typically IT departments own and manage

Split your rating logic so that most data comes from lookup tables. Business users can manage the lookup table data separate from the pure formulas in programming code.

It might be tempting to store table data in system tables, which the application throws away and rebuilds from configuration files on application startup. However, Guidewire strongly recommends that you store your table data as standard entity instances. In other words, store table data as entities that you define in the data model that persist in the PolicyCenter database. Create screens for your business users to directly edit this data. In real-world deployments, this approach is the most versatile for ensuring that business users with the right permissions can change rates without requesting help from the IT department.

If you store table data as standard entities, remember that you cannot use source code control to move rate tables from a development or test environment to a production environment. Your data is in the database itself not configuration files. You must create your own process for moving your tables as administrative data. You can export the data from the test server and then load it into your production server.

Guidewire strongly recommends that you store your table data as persisted entity instances in the PolicyCenter database. There are special requirements to consider for copying data to your production system with this approach. This approach lets business users manage the table data in the application user interface. This approach results in the most successful real-world PolicyCenter rating integration implementations.

The basic pattern for rating code is described below.

  1. Define a table with effective dates, the underwriter company (UWCompany), the state, and so on.
  2. Create a class that retrieves data from that table using the query builder APIs. The built-in rating engines extensively use these types of lookups.
  3. Create screens for editing those rate tables in the web user interface (PCF files) so business users can manage the data.

For rate table lookups, it is important to know what date to use for any table lookup that uses a date. As you write rating code, pay extremely close attention to ensuring that you always use the appropriate date.

Remember also that PolicyCenter sometimes must recalculate rates even when nothing important to the rate actually changed. Because of this, you must guarantee that your formulas and rate tables always return the same amount if PolicyCenter re-runs the formula at a later date.

The following rules must be followed.

  • Reference dates for lookups must be consistent. For example, always use the start of the period, not the current date or current time.
  • Never backdate any rate or formula changes. If PolicyCenter needs to re-rate a rating request with the same reference date at a later time to a production system, your code must always return the same result. If you ever need to change the formula, you must preserve the old formula for any existing data. The formula change must take effect in the future, or at least after the reference date for all existing policies. To change a formula used in rating, your code would preserve the old formula for all your legacy policies but rates on newer effective dates can use the new formula. In other words, your code that actually generates the rate would perform the following operations.
    1. Check the effective date of the change
    2. If the change’s effective date is before the formula’s change date, your code must run your old formula. It is critical that you never permit backdated rates in production systems.
    3. If the change’s effective date is after the formula’s change date, your code must use your new formula.
  • Avoid round-off errors. Be sure to avoid round-off errors in your proration code.

Of course, if you are using an external rating engine, be sure that your external engine follows this general pattern. If you have questions about supporting these rules, please contact Guidewire Customer Support.

You must carefully implement rates and formulas, and be particularly careful with changes with real production data. Reference dates must be consistent. Never backdate rate changes or formulas. Avoid round-off errors. If you fail to follow these rules, customer data may be affected, and PolicyCenter has undefined behavior.