GUIDE TO THE REPLACEMENT REGISTER

Transcription

1 GUIDE TO THE REPLACEMENT REGISTER This guide provides an overview of the notification requirements for participating member offices in respect of the Replacement Register and is issued under section 6 of the ASISA Standard on Replacement. 1. Purpose of the Replacement Register The key objective of the Register is to assist with the implementation of the provisions regarding replacements as contained in the commission regulations, under Part 3 of the Long Term Insurance Act (effective from 1 March 2007). ASISA, as well as its long term insurance members, will also receive the following associated benefits from the Policy Replacement Monitoring System: A better understanding of the quantity and types of replacements taking place in the life insurance industry; Members that are currently unable to track internal replacements (where one of their products is replaced by another of their own products) will gain visibility into these replacements through the system; The automated processing of data will alleviate administrative burden as well as human errors in the member organisations; The centralised rules engine will ensure consistency in determining when a replacement has taken place across and within members; The data can be further analysed to determine trends and gather statistics. 2. Basic Rules 2.1 The electronic register has been developed by ASTUTE for ASISA. Members providing data to the register and receiving notifications are those that have investment business. 2.2 Data must be provided from 1 December The participating member offices currently are: ABSA Life Assupol Life Clientele Life Discovery Life Hollard Life Liberty Group

2 Metropolitan Life Momentum Nedgroup Life Old Mutual PPS Regent Life Sanlam 2.4 The operating rules of the system are as follows: To identify a replacement match on transactions within a 4-month trading window. Any matches/potential matches are then reported back to the life office holding the replaced policy as well as the life office that has issued the new policy. The types of policies to be reported on are those falling under the definition of "replacement policy" in the commission regulations, being a multiple premium policy which is an investment policy. Typically they will be endowments or RA s and certain hybrid policies. Where a policy is of a hybrid type, the type most closely matching the policy should be selected for the purposes of notification to the system. Policy holder or Life insured details on an old change event and the policy holder or life insured details on the new change event will determine if a replacement event has taken place. Due to the complexity of some products as well as the purpose of different products, the system may at times return a potential match. This scenario would be particularly relevant to business insurance, joint life and 3 rd party policies. Under these circumstances the onus will be on the life office to determine if a bona fide replacement has taken place. All the relevant information will still be provided by the system to assist the life office in making this determination. Change events are those events that lead to the change in the status of a policy e.g. policy cancelled, policy lapsed, premium reduced, new policy issued etc. Member offices must report policy change events to the central system at least twice a month. Provision has been made for reversing of any notified event. This is mainly to cater for circumstances where a cancelled policy has been rescued or a new product has been cancelled within a cooling off period and all premiums are refunded. A reversal event can result in a Replacement Reversal notification. As part of the data requirements, member offices must indicate whether or not the administration fees on the policy exceeded 15% of the policy surrender value and only policies marked by the life assurer as exceeding the 15% threshold will be matched. 3. Data Elements The following data fields have been identified by ASISA to be provided by each member for any policy that will be transmitted to the centralised system:

3 Policy Change Event Data Fields Data Field Name of Juristic Policy Holder Organisation ID number of policyholder (or failing: Date of birth: format: yymmdd ) Surname of policyholder Full names of policyholder Gender of policyholder Postal code of policyholder ID number of insured life (or failing: Date of birth: format: yymmdd ) Surname of insured life Full names of insured life Gender of insured life Postal code of insured life Policy number Client number Effective Date Policy term Comments The name of the juristic organisation where the policy holder is a juristic. Where the policy holder is juristic, the rest of the policy holder fields can be used to describe the main policy holder within the organisation. ID numbers must be complete and will be used as the main identification field in the searching algorithm. Where there is more than one policy holder, this field will be reused per policy holder. policy holder, this policy holder, this m or f (gender can also be deduced from ID no). Where there is more than one policy holder, this field will be reused per policy holder. Postal code of residence or place of work. Allows for regional analysis. ID numbers must be complete and will be used as the main identification field in the searching algorithm. Where there is more than one insured life, this field will be reused per insured life. insured life, this field will be reused per insured life. insured life, this field will be reused per insured life. m or f (gender can also be deduced from ID no). Where there is more than one insured life, this field will be reused per insured life. Postal code of residence or place of work. Allows for regional analysis. Where there is more than one insured life, this field will be reused per insured life. Insurer s internal client number if available. This will help identify internal churning instances. Format: yyyy/mm/dd. This has been defined as the date on which the benefits contained in the contract are fully available to the policy holder. In years or 1000 for whole life 3

4 Causal Event Date Causal Event Replacement Indicator Reversal Indicator Policy Type ID number of intermediary Intermediary company name (FSP) Type of intermediary Causal Event Indicator Format: yyyy/mm/dd. Paid Up Premium Increase (On Premium Reduction (On Term Reduction (On These data entry types for this single data field are mutually Partial Surrender (Sec 14) exclusive: A policy can only Partial Surrender terminate or be sold for one of Full Surrender (Sec 14) these reasons, for our purpose. Full Surrender Lapse/Suspensions Cancellations New Business Early Retirement Used to indicate that the new business event is for the purpose of replacing the policy specified by the policy change event Used to indicate that the match found on the policy needs to be reversed Endowment: y/n Retirement annuity: y/m Whole life: y/n These data fields are not mutually exclusive: An endowment policy can also be of the universal life type. ID number of the agent or financial adviser. Where there is more than one intermediary, this field will be reused per Text field with name of company. Where there is more than one intermediary, this field will be reused per Insurance company advisor These data entry types (agent) Independent financial are mutually exclusive: A policy can only be sold Bank financial through one of these, for (corporate financial adviser) our purpose. Where there is more than one No financial intermediary, this field (including call centre will be reused per business) Boolean field to indicate if the administration fees exceeded 15% of the policy value Yes or No 4

5 The Policy Replacement Monitoring System will provide the following data fields back to the member issuing the new policy, (as well as the member of the cancelled policy) that has been identified as belonging to a replacement transaction: Data Field Name of Juristic Policy Holder Organisation ID number of policyholder (or failing: Date of birth: format: yymmdd ) Surname of policyholder Full names of policyholder Gender New business member New business Policy number New business Client number Cancelled member Cancelled Policy number Cancelled Client number New business effective date Policy term Causal Event Policy Type ID number of New Business intermediary Replacement Notification Data Fields Comments The name of the juristic organisation where the policy holder is a juristic. Where the policy holder is juristic, the rest of the policy holder fields can be used to describe the main policy holder within the organisation. New Business Paid Up Premium Reduction (On Premium Increase (On Term Reduction (On Partial Surrender (Sec 14) Partial Surrender Full Surrender (Sec 14) Full Surrender Lapse/Suspensions Cancellations Early Retirement Endowment: y/n Retirement annuity: y/n Whole life: y/n These data entry types are mutually exclusive: A policy can only terminate or be sold for one of these reasons, for our purpose. These data fields are not mutually exclusive: An endowment policy can also be of the universal life type. ID number of the agent or financial adviser. Where there is more than one intermediary, this field will be reused per 5

6 Data Field New Business Intermediary company name (FSP) Type of New Business intermediary ID number of Policy Change intermediary Policy Change Intermediary company name (FSP) Type of Policy Change intermediary Comments Text field with name of company. Where there is more than one intermediary, this field will be reused per Insurance company advisor (agent) Independent financial Bank financial (corporate financial adviser) No financial (including call centre business) These data entry types are mutually exclusive: A policy can only be sold through one of these, for our purpose. Where there is more than one intermediary, this field will be reused per ID number of the agent or financial adviser. Where there is more than one intermediary, this field will be reused per Text field with name of company. Where there is more than one intermediary, this field will be reused per Insurance company advisor (agent) Independent financial Bank financial (corporate financial adviser) No financial (including call centre business) These data entry types are mutually exclusive: A policy can only be sold through one of these, for our purpose. Where there is more than one intermediary, this field will be reused per 6

7 The system will make provision for reversals of notifications i.e. when a policy has been cancelled within the cooling off period and all premiums have been refunded to the policy holder or when a life office is successful in rescuing a replaced policy. 4. Procedure for queries 4.1 All queries in relation to the operation of the system must be logged with Astute. These should be logged on the request logging system of the Astute Technology department. The request logging system is an online system available at The following username and password should be used to gain access to the site: Username: LOA-Users@astutefse.com Password: Astute 4.2 Queries should be logged as Production queries with a Normal priority. 4.3 Acknowledgement of all queries logged are usually sent to the originator of the query within 2 working days of the query being logged. 4.4 The status of all open queries can also be viewed on the request logging system 4.5 Any updates to the query should be effected on the request logging system. 4.6 Escalation of a previously logged query can be sent to the Daryl Smith: Darryl@astutefse.com ******************************************* 7