Process Flow

This topic describes the life cycle of a Policy in ClariNet LS. It assumes that you are familiar with the structure of a Case in ClariNet LS.

Stage 1: Setup/Submission

A new Case is created through one of five different processes. The result varies depending on which of these processes is followed.

1. This process is described in Create a Case using a Form. It creates a new Case and adds Policy and Insured data. The option exists to attach an Illustration document, without entering any of the Illustration data. It also creates a Received Transaction for the Case. Documents may be added to the Case during this process although – with the exception of an Illustration and Life Expectancy Reports - they may not be linked to Case objects.

2. A User creates the Case using Case View This process is described on the Case page. It creates a new Case and adds Agent, Broker, Provider and Investor data.

3. Another Client submits the Case via ClariNet LS This process is similar to Create a Case using a Form, although it may result in more data at the outset. Once another Client has created a Case, it can submit the Case to other Clients which may be interested in purchasing the relevant Policy. This process creates two Transactions: a Sent Transaction for the sending Client and a Received Transaction for the recipient. Depending on the setup process followed by the sending Client, this may result in more data than setting up the Case yourself.

4. A User imports the Case using the Excel Portfolio Upload template

Importing a Case using the Excel Portfolio Upload template creates a Policy within a new Case. It may link the Policy to an existing Insured or create a new Insured. Optionally, it can create several different Case objects:

• Registered Owner;
• Servicing Carrier;
• Underwriters Reports (multiple);
• Health Status Contacts (multiple for each Insured);
• Healthcare Providers (multiple for each Insured)
• Premium Schedules (multiple)
• Verification of Coverage (multiple)
• Custom IRRs (multiple)

This process does not add any documents to the Case. It can also be used to add new data to an existing Case or modify existing data.

5. A User imports the Case using the Common Case Standard import process

This process is similar to using the Excel Portfolio Upload template, except that it uses an XML file. The XML file is generated by exporting a Case from ClariNet LS. If the export includes documents, the XML file and all associated documents are contained in a ZIP archive. Importing the XML file only will create a new Case containing all of the data in the XML; importing the ZIP archive will add all of the documents, linked to their respective Case objects.

Stage 2: Pricing

Pricing a Policy requires that at least one Premium Schedule exists in the relevant Case. It also requires at least one Life Expectancy Report for each surviving Insured in that Case. Note that in ClariNet LS, a Premium Schedule contains information on the Death Benefit for the Policy as well as scheduled Premium payments for that Policy. Premium Schedules can be added to a Case as part of the setup process – alternatively, they can be generated using the ClariNet LS Premium Calculator.

Process

Pricing a Policy involves:

• Selecting a Premium Schedule;
• Choosing a Value Date;
• Selecting one or more Life Expectancy Reports for each surviving Insured and adjusting the Weighting for each report; and
• Choosing up to three different Valuation Templates to define how survival curves are calculated, which Discount Rates are used to calculate the value of each cashflow leg, etc.

Result

The results of pricing a Policy are saved within the relevant Case and are displayed on the Valuations tab (regardless of whether the pricing is generated using the Single Policy Pricing model or the Portfolio valuation model). The results include values for the Policy as of the Value Date, based on the parameters set in the Valuation Template and the Premium Schedule selected by the User.

Stage 3: Bidding

Bidding on a Policy requires that either a Sent Transaction or a Received Transaction have been started by a Client.

Process

Each Transaction can have multiple Events, which describe the flow from start to end:

• Starting: Open for Bidding (Received), Submitted (Sent)
• Bid
• Query
• Counter-offer
• Ending: Bid Accepted, Declined (Sent), Withdrawn (Received)

For a Transaction between two Clients, the process flow is driven by the actions of each Client in turn. Thus, once the sender has submitted the Case to the recipient, the next step in the Transaction is for the recipient to take; the sender can only elect to stop the Transaction at this point (i.e., withdraw the Case from the recipient).

Result

The end stage of either a Sent Transaction or a Received Transaction is either agreement as to price (Bid Accepted) or no agreement, in which Case the Transaction will end up as Declined or Withdrawn.

Stage 4: Closing

In order to start a Closing Transaction, either a Sent Transaction or a Received Transaction must have the “Bid Accepted” Event and not be either Withdrawn or Declined.

Process

A Closing Transaction is linked to a “successful” Sent or Received Transaction. Any one Case can have multiple Closing Transactions active simultaneously. The exact steps to complete a Closing Transaction are comprised of system-defined steps and user-defined steps, as follows:

• Price Allocation (System): Allocate a gross bid between different entities (e.g., Seller, Broker, Provider);
• Case Participants (System): Identify the entities which will form part of the contract;
• Contract Package (System): Generate a Contract Package for the sale of the Policy, based on Word templates created and maintained by the Client;
• Document Verification (User): A compliance checklist for the documents in the Contract Package, based on check points defined by the Client; and
• Closing Checklist (User): A workflow process defined by the Client, with specific tasks/steps grouped into Closing Events.

The process begins when a Closing Transaction is created by a Client and ends when a User enters a date into the Closing Completed field.

Result

The result of a Closing Transaction is that it is marked as Completed.

It does not change the Case Status; this is determined by reference to the information entered on the Cost/Maturity/Disposal tab in the Case Summary.

Stage 5: Servicing

In order for Servicing Tasks to be undertaken for a Case, the Case must be contained in at least one Portfolio.

Process

Servicing describes the “care and feeding” of a Policy after purchase. It typically involves one or more of the Servicing Tasks listed below. ClariNet LS incorporates a Servicing Task planner with flags and follow-ups to show the status of each Servicing Task for a Case, with the frequency of each Servicing Task set by the Client and triggered by reference to the date of the most recent relevant document. The Servicing Tasks include:

• Premium Payments;
• Illustration Orders;
• VOC Orders;
• Health Status Tracking;
• Life Expectancy Report Orders;
• Medical Record Orders and
• Premium Schedule Updates.

Servicing Tasks are cyclical – they will be undertaken several times during the life of the Policy. Different Servicing Tasks may be undertaken simultaneously.

Stage 6: Maturity/Disposal

A Policy which is active (i.e., not lapsed, surrendered, matured or sold).

Process

This involves tracking the realization of a Policy. It is recorded on the Cost/Maturity/Disposal tab in the Case Summary. Realization takes one of four different sub-processes:

• Maturity: Claiming and receiving the Net Death Benefit from the Carrier, as a consequence of the death of the last surviving Insured;
• Sale: Selling the Policy to a third party;
• Surrender: Surrendering the Policy to the Carrier in exchange for payment of the Cash Surrender Value; or
• Lapse: Allowing the Policy to lapse for non-payment of premium.

Maturity has a number of steps which are tracked (e.g., requesting the claim package, submitting the claim package, having the owner receive the claim check). The others merely record the date of the event and any amounts received in consequence. Lapse is treated as a surrender but for zero compensation.

Status

The Status column is calculated dynamically, based on fixed data points on the Cost/Maturity/Disposal tab and Date of Death on the Insured tab:

• if (PolicyIsOwned)
  • if (PolicyIsSold) => SOLD
  • if (PolicyIsSurrendered) = > SURR
  • if (PolicyHasMaturityPaid) => MAT
  • if (PolicyHasMatured-but not paid) => PEND
  • otherwise => "OWN"
• if (not owned) => [blank]

PolicyIsOwned= Purchase Date AND Purchase Cost have a value

PolicyIsSold = Disposal Type is “Sold” AND Disposal Date AND Disposal Amount have a value

PolicyIsSurrendered = Disposal Type is “Surrendered” AND Disposal Date AND Disposal Amount have a value

PolicyHasMaturityPaid = Maturity Payment Date AND Maturity NDB Payment have a value

Has Matured but Not paid = takes into account 1st to Die, 2nd to Die (Joint Life Payout Type = First to Die = either insured died (Primary or Secondary is irrelevant) Second to Die = both insureds died) and insured(s)' Date Of Death on Insured tab

If you do not own a Policy, then none of these Statuses will be shown. Currently, you must enter a Purchase Date and Purchase Cost for any of these values to be shown.

Because the Status field is calculated on the fly every time it is displayed, it does not appear on the Audit Log. Instead, look for changes in the underlying values (such as Purchase Date, Maturity Payment Date, etc.)

Last Status

The other status-related field is currently called Last Status and is shown in Case Lists, alongside Last Status Date.

This field reflects a recent action on the Case, not necessarily its current state.

If for example you accept a Bid on a Transaction, Last Status will become "Bid Accepted". At this point, you decide to start the Closing Transaction. The Last Status will become "Closing". At this point, you Withdraw from Bidding from other bidders who were not accepted. The Last Status becomes "Withdrawn", even though you are actually still processing the Closing transaction.

If you do not deal with Transactions (Sent, Received or Closing), we recommend you hide these two fields from your case lists in the First Steps Using ClariNetLS. Simply uncheck Last Status and Last Status Date. See Case Lists for further details.

If you need to search Cases, please use the underlying criteria such as "Received Transaction Event" rather than "Last Status".

This field might be updated or removed in a future release of ClariNet LS as it often leads to confusion.