Oracle® Insurance Rules Palette 10.1.2.0 E59346-01

Rate Repricing

Sometimes a re-price may occur after the initial product is launched. The processes and structure of the product may not change, but the re-price could change some aspects of the coverage such as the base coverage rates.   Rates used for valuation routines do not fall into this category and would not apply in this situation. Repricing applies to rates that represent a cost to the policy. It is restricted to certain limits by the policy contract and by plan filing with governmental jurisdictions.

The AsRate table holds the detail rates. The AsRateGroup table is used to control when a set of rates in AsRate will be used by a calculation. So in regards to re-pricing, a new complete set of AsRate records is needed for the new rate group.

There are five columns in AsRateGroup that are the most important factors OIPA considers when identifying the correct set of rates that a policy will use during execution. They are the RateDescription, EffectiveDate, ActiveFromDate, ActiveToDate and RateGroupGUID. An explanation of each column is provided below.

AsRateGroup Column Explanation

RateDescription: The rate description for a rate must have the same value across all of the rate group records.

EffectiveDate: The EffectiveDate is compared to a segment’s RateActiveDate or a policy's Plan Date or Issue Date; whichever represents the effective date of the policy. The system selects the rate group with the highest EffectiveDate value that is less than or equal to the provided RateActiveDate. At no time can two sets of rates be available for a given RateActiveDate. And there must always be at least one rate set for each RateActiveDate.

Effective Date Example for Repricing

Based on the table above, if a RateActivationDate is 12/31/2008, then line 1 represents the rate set that is selected. If a RateActivationDate is 1/1/2009, then line 2 represents the rate set that is selected. Notice that there are two sets of rates with an EffectiveDate less than or equal to 1/1/2009, but the system will only return one set (the set with the highest effective date). If the RateActivationDate is 12/31/2003, then an error will occur within the calculation that tries to use the rates.

Near the end of an older set of rates and at the beginning of a new set of rates, there may be questions as to which rate set the policy should use. Once the set is decided, it is a matter of setting the value of SegmentRateActiveDate appropriately. For example, a policy may be dated on or after 1/1/2009, but the user has the flexibility to select the new rates by providing a value of 1/1/2009 or later in the segment’s rate active dates or the user can select the old rates by providing a value of 12/31/2008 or earlier in the segment’s rate active dates. These dates for rate access are set by the example and will differ from the dates used by the actual rate data.

ActiveFromDate and ActiveToDate: As the name implies, these two dates define a date range where rates are available based on an activity’s effective date. A set of rates will not be available to the activity if the activity’s effective date is not within the date range. Being within the date range is defined as a date being greater than or equal to ActiveFromDate and less than ActiveToDate. If ActiveToDate is null, then the latter comparison is always true. No two date ranges for the same rate may overlap. For example, in the table below, lines 1 and 2 are valid. Lines 3 and 4 are invalid. Line 5 is valid since it does not overlap with either line 3 and 4. Lines 6 and 7 are valid, but 1 day is missing from the data ranges (12/31/2008). This will pose a problem for activities that use rate description Z and have activity effective dates of 12/31/2008.

ActiveFrom and ActiveTo Examples

In the table below, a new column of information is added to the table, EffectiveDate. The first 7 lines are a copy of the prior table. They are valid and invalid for the same reasons above. Lines 8 and 9 are added to show more invalid dating. The ActiveFromDate and ActiveToDate columns look valid. It is the EffectiveDate in combination with these dates that make the lines invalid. Activities dated between 1/1/2004 and 1/1/2009 where the segment’s rate activation date is less than 1/1/2009 will have no problem processing. However, once the activity’s effective dates become equal to or greater than 1/1/2009, policies with segment rate activation dates less than 1/1/2009 will not be able to process. Line 8 is not valid for rate access on activities dated 1/1/2009 or later with segment rate activation date less than 1/1/2009. Line 9 has an effective date of 1/1/2009. This tells the system that the segment activation date must be 1/1/2009 or greater, leaving earlier issues without rate access. To become valid, line 9’s EffectiveDate should be 1/1/2004 or an additional record with an EffectiveDate of 1/1/2004 is needed to accommodate the earlier issues or the ActiveToDate on line 8 should be null leaving rate access for these early issues at line 8.

Effective Date Column Added to Example

How Repricing Works

In order for OIPA to use a set of different rates from the original product, you must use a combination of the EffectiveDate, ActiveFromDate and ActiveToDate in the AsRateGroup table. The other data in the AsRateGroup table will remain the same. The date information, along with the Rate Description and criteria for the Rate Group, is used by a configuror to point to the correct stored values in the AsRate table. Regardless of how many entries for a single Rate Description are entered into AsRateGroup, the differentiating rate group information needs to be entered to ensure that only one set of rates will be valid for any policy or segment for any given day.    

EffectiveDate for a given RateDescription will determine the RateGroup or RateGroups based on a date data attribute of the Policy or Segment. This is most commonly a PolicyField or a SegmentField.    

Once a set of RateGroups is retrieved that have the required EffectiveDate (there may be a few at this point), the list is further narrowed down based on the Activity date, which will use ActiveFromDate and ActiveToDate to determine the applicable rates.

RateGroup selection SQL Pseudo Code that is generated:

SELECT * FROM AsRateGroup

WHERE rateDescription = [RateDescription]

AND effectiveDate <= [EffectiveDate]

AND activeFromDate <= [ActivityDate]

AND ( activeToDate >= [ActivityDate] OR activeToDate is null ) 

Repricing for New Policies -vs- Repricing for Existing and New Policies

By using Rate Groups, actuaries are given the opportunity to do one of the following:

• Re-price a product for an existing benefit that sets new rates for a product, but the new rates are used only for new policies after a given date. Existing policies will still use the old set of rates. See Example One below. 

• Re-price a product where the old rates are no longer used from a certain date forward, and both old and new policies use a set of rates from a given date. See Example Two below. 

In either case, only one set of rates is valid for a policy at any one time.

Example One: Two Sets of Rates are Open

Re-price a product for an existing benefit that sets new rates for a product, but the new rates are used only for new policies after a given date. Existing policies will still use the old set of rates.  

• For example, a base segment was priced using rate set A with an original effective date of 1/1/2000 and no backdating. The Rate Group name is BaseRates. It is determined four years later that the rates should be increased to be more profitable with a re-price effective date of 1/1/2004, again with no backdating. Further suppose that it is decided that already existing policies should not be affected and they should continue to use the existing BaseRates rates that have been loaded.   

• In this case, BaseRates is the appropriate Rate Description for the rates and by continuing to use the same description, configuration to perform the rate lookup will not need to change as the RateDescription will stay the same.

• In the database, two entries will exist in AsRateGroup. Both are called BaseRates but with different EffectiveDates, which are also known as Rate Activation Dates. 

• The second set of rates will follow the same Rate Upload procedure as above. The RateDescription used for the second set of rates will be BaseRates, the same name as the original set of rates, but will be loaded with a different Rate Activation Date and a different ActiveFromDate. 

• After entering the Rate Group information, AsRateGroup would hold the following information. For this example, no criteria is used other than IntegerCriteria. If additional criteria were used, all criteria names must match between the old and new rates.  

Mapping it Out

Line one is used for RateDescription=BaseRates where policies have an EffectiveDate from 1/1/2000 (inclusive) to 1/1/2004 (exclusive).

Line two is used for RateDescription=BaseRates where policies have an EffectiveDate from 1/1/2004 (inclusive) forward.

Sample of Rate Effective Dates

Backdating

Should backdating of activities be allowed, then the ActiveFromDate would not match the EffectiveDate/RateActivationDate. An example where three months of backdating is allowed would look like this: 

Sample of Rate Backdating

Rate Database Samples

• For activities on policies with an EffectiveDate between 1/1/2000 and 12/31/2003, the original rates will always be used.   

• For activities on all policies whose EffectiveDate is on or after 1/1/2004, the new re-priced rates will be used.  

Example Two: Only One Set of Rates is Open for BaseRates 

Re-price a product where the old rates are no longer used from a certain date forward, and both old and new policies use a set of rates from that given date.  

• For example, a base segment was priced using rate set A and named Rate Group BaseRates. It is determined four years later that the rates should be increased to be more profitable. Further suppose that it is decided that already existing policies should also have their rates increased and their current rates will no longer be valid as of a given date.  

• In this case, BaseRates is the appropriate Rate Description for the rates. Since you are continuing to use the same description, you will configure the rate lookup the same way.  

• In the database, there will exist two entries in AsRateGroup, both called BaseRates but with different EffectiveDates. In addition, the rates that will no longer be in affect will have the ActiveToDate filled in. 

• After entering the Rate Group information, AsRateGroup will hold the following information. For this example, no criteria is used other than IntegerCriteria. If criteria were used, all criteria names must match between the old and new rates. 

Mapping it Out

Line one is used from RateDescription=BaseRates where policies have an EffectiveDate from 1/1/2000 (inclusive) forward but only for activities with effective dates between 1/1/2000 (inclusive) and 12/31/2003 (inclusive).

Line two is used from RateDescription=BaseRates where policies have an EffectiveDate from 1/1/2000 (inclusive) forward but only for activities with effective dates on or after 1/1/2004.

Sample of Rate Backdating

Rate Database Samples

• Activities on policies between 1/1/2000 and 12/31/2003 whose RateActiviationDate is between 1/1/2000 and 12/31/2003 will use the original rates.

• Activities on all policies that occur on or after 1/1/2004 will use the new re-priced rates.