You are here: Admin Explorer Folders > Rates > Repricing

Oracle® Insurance Rules Palette 9.4.1.0 E23637_01

# 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.

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. Everything else 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.

EffectiveDate will determine the set of rates to retrieve based on the RateDescription. It also determines for a specific policy which rates are active, meaning that they are valid based on a set date value. This is most commonly a PolicyField or a SegmentField. In the Product Templates, it is a SegmentField called SegmentActiveDate. OIPA will refer to the policy and plan effective dates when identifying what RateGroups are applicable according to the EffectiveDate.

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 <= [ActiveDate]

AND ( activeToDate >= [ActiveDate] 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 that 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 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 at 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.

Copyright © 2009, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices