Polaris has designed and built Private Motor Car, Commercial and Household ‘skeleton schemes’ for use by product builders. These are full cycle scheme templates containing example groups, tables and rules which product builders can customise to meet the requirements of their specific product.
Their purpose is to provide a basis for product builders to develop their schemes, giving them a structure without constraining flexibility. Rules are provided which define the structure, give examples to make use of the structure and support the data manipulation required by all users (eg. IPT Calculation). They also contain rules provided by Polaris to control processing by transaction type (eg. New Business, MTA) and provide utility rules for populating the required output objects (eg. MTA Premium Calculation). In addition, there are some rules that provide example ways of validating input data and structuring output covers and premium quote breakdowns.
A skeleton structure has the following sections:
§ Process control - this sets up how the scheme should operate, particularly where it is vital that certain functions or calculations are performed in a strict sequence.
§ Risk Acceptance - this section deals with specifying the data necessary to assess the risk and to make accept, refer or decline decisions.
§ Premium Calculation & Quote Breakdown - this sections provides the standard calculators needed to produce the quote premium details.
§ Terms & Conditions - this provides standards rules for determining what endorsements, excesses and conditions apply to the quote.
It also contains standard data manipulation for:
§ IPT calculation
§ Mid Term Adjustments using the Industry standard premium calculation and standard terms generation.
The skeleton is supported by a sample specification document as Polaris strongly recommend that the overall structure and design of any insurance product should be developed and documented before starting to build it using the ProductWriterŇ software.
The following sections summarise the elements which should be included in a product definition specification in order that a ProductWriter® based product can be written. Although the example used is for commercial insurance much is also applicable to personal lines.
Once written your product will:
§ identify what information a broker system must capture for you to assess the risk, provide a quotation, place new business etc.
§ identify the risk acceptance (declines/refers) criteria as stated in the rating guide.
§ quote the premium payable
§ provide a breakdown of how the premium was calculated, from base premium to payable premium (quote breakdown)
§ identify the cover that is/will be operative along with specific sums insured, limits and excess that apply
§ identify applicable endorsements
§ provide screen display notes.
ProductWriter® supports the various stages of processing business from new business, through MTAs to renewals. It is important to remember that your processing requirements may be different at these different points in the processing cycle and to specify your rules accordingly.
ProductWriter® provides a number of different transactions to support the various stages in the business cycle. The key transactions for the commercial dictionary are:
§ POS enquiry (used by some software houses)
§ POS request quotation
§ New business
§ MTA processing
§ Renewal
It is important therefore that you consider and specify the different actions for each of these business stages.
1. Risks to be declined
Ensure that you include every condition that you would wish to decline business for this specific product. These might include certain factors to do with the proposer, the location, the vehicle, occupations etc. As necessary identify the code list values which are to be declined. For such cases a reason for declinature should be given. It should not be possible to override a decline. If there is any situation where you would allow the decline to be overridden then it should be output as a referral.
2. Risks to be referred
Detail the conditions under which the insurance is to be referred to the insurer for agreement to accept the business. Again these could include factors such as the proposer details, the location, the vehicle, trade etc. They could be certain values from a code list or a complex set of circumstances.
The reason(s) for referring should be given. It is important that, as far as possible, all referral reasons are identified to the broker the first time a quotation is requested; product design should take this into account. You should ensure that product builders use the refer and continue option and the calculations continue as if it was not a referral. (Further details are contained in the technical manual)
3. Requirements for premium calculation
Set up a rating table giving the product’s base rates
§
identify the objects and properties from the data
dictionary that are to be used
§
supply the insurer rating values to be used
§
identify range bands for rating purposes eg. buildings
Sum Insured 0 - 89,999 etc
Identify and detail all relevant loadings to be applied eg.
§
hazardous locations or activities
Identify and detail all relevant discounts to be applied eg.
§
good locations, good protections, NCD
Identify and detail all relevant excesses that impact the premium payable (both voluntary and compulsory) and how these apply.
Round the premium to the nearest pound (50p - round up)
Apply and detail IPT at the current rate
4. Cover
The elements that are to be included in certain cover components are documented in the common usage of cover report. It is important that this is used as the basis for you specifying what cover is to be provided. If your “standard” includes more aspects it is important that you include these as additions.
The finished product will provide details of limits, sums insured, benefits and excesses in terms of the objects and properties provided in the dictionary. This sort of information should be made available to the product developer. When designing your products, avoid embedding limits in wordings or endorsements as they should be specified as data in properties within the dictionary.
5. Quotation conditions
A quotation condition is a specific condition that applies to the quotation and is normally a temporary condition, eg subject to survey. You can use either the market standard lists or provide your own equivalent.
6. Endorsements
An endorsement is a material change to the cover or variation in cover conditions. Again, you can use either the market standard lists or provide your own equivalent. If an insurer uses their own endorsement code list the type code should also be completed to categorise the endorsement.
Identify and detail all endorsements that may apply for this product and define the circumstances when they should be output.
7.
Notes
Notes are displayed on the broker screen. They are used to display ad hoc messages that may be applicable to a product for a limited period. They should not include any material information about the policy.