Pricing Logic

The most friendly premium calculation engine

Pricing Logic is the core of an insurance product. We understand that most companies use Excel to lay out the pricing structure of an insurance product, hence, at KASKO, we developed our pricing engine around Excel.

The configuration on Product Builder has essentially 2 parts, the Pricing Logic file and the Validation Rules.

You can keep your formula and sheets in your excel and simply add one KASKO formatted sheet Calculator to the first sheet of your excel. You can get the example Excel file here.

In the KASKO Calculator sheet, you will see the below sections.

In a functioning excel, you should be able to see the calculated premiums and output fields in column K once you put in the test values in column C. You should be able to test various scenarios and cases to see if the premiums are returned correctly.

There is a list of output fields that should always be in the pricing excel. These are the default outputs that are already listed in the pricing template file. The fields are:

  • billing_cycles

  • gross_payment_amount

  • gross_premium

  • premium_tax

  • net_premium

  • net_net_premium

  • net_commission_total

  • tax_rate

  • duration_strategy

Apart from the above fields, there are some additional

In the output field, there is a required field called Duration Strategy. This field defines how the policy start and end date should be defined. There are 4 duration strategies that can be used.

fixed_start

Fix start duration strategy is typically used for policies that have a specific start date (usually selected by the customers) but have an undefined end date (open ending). This means the policy with this duration strategy does not expire (lapse) unless it is cancelled.

With fixed_start duration strategy, you must also include policy_start_date in the output field.

fixed_end

Fix end duration strategy is typically used for policies that have a fixed end date (usually set by the customer) but does not request the customers to select a start date. This means the policy with this duration strategy will expire (lapse) on a defined date unless it is cancelled prior to the date.

With fixed_end duration strategy, you must also include policy_end_date in the output field.

fixed_start_with_interval

Fix start with interval strategy is typically used for policies that have a specific start date (usually selected by the customers) and the policies last for a defined period of time (X days/months/years) counting from the start date. This means the policy with this duration strategy will expire on a dynamic end date depending on defined the start date and end date unless it is cancelled prior to the end date.

With fixed_start_with_interval duration strategy, you must also include policy_start_date and policy_validity_interval in the output fields.

For policy_validity_interval it should always be in the format P_D/P_M/P_Y depending on the duration set. Below are some duration examples and the corresponding values.

  • 7 days - P7D

  • 14 days - P14D

  • 6 months - P6M

  • 12 months or 1 year - P12M or P1Y

  • 3 years - P3Y

fixed_start_and_end_date

Fix start and end end date duration strategy is typically used for policies that have a specific start date (usuaully set by the customers) and the policies will end on a specific end date (usually set by the customer). This means the policy with this duration strategy will start on the defined date and end on the defined date unless it is cancelled prior to the end date.

With fixed_start_with_interval duration strategy, you must also include policy_start_date and policy_end_date in the output fields.

Apart from the Pricing Excel file, you will also need the Validation Rules for all the quote data of your product. The Validation Rules are written in JSON and here is an example.

Pricing Logic Validation Rules Example
{
	"quote": [
		{
			"name": "field_1_number",
			"path": "data",
			"validation": "integer|required"
		},
		{
			"name": "field_2_module",
			"path": "data",
			"validation": "required|string|in:module_1,module_2"
		},
		{
			"name": "field_3_date",
			"path": "data",
			"validation": "iso_date|required|string|after:1 month from yesterday"
		}
	],
	"quote_patch": [],
	"pricing_variables": []
}

In the example, you can see that each of the input fields in your pricing would include 3 parts in the Validation Rules.

Once you have a functioning Pricing Logic Excel file and the Validation Rules, you can go to Product Builder → Pricing Logic and start configuring for your product.

You will need to remove all the values (column C) for all the input fields so that the pricing is clean and without any prefilled values.

When you finish the Pricing Logic Configuration, you can go to the Manual Test. Here on the left hand side, you can see a dropdown of the payment frequencies and the input fields of the product; on the right hand side, you can see a blank output screen.

This area is for you to run manual test of your Pricing Logic, by inputting different values on the left hand side and click Run Test on the top right. Once clicked, you will see the return of the pricing calculation on the right hand side in the output area.

Once the Pricing Logic is configured and you want to update the pricing calculation for your product, simply go back to Pricing Logic Configuration screen. There you can download the latest Pricing Logic Excel and make the necessary update to your Pricing Logic Excel file. Once the changes are made, you can upload it to the Product Builder (and update the Validation Rules if there are any changes there as well).

Last updated