Part Five: Automated Underwriting System Design
From The Original Insurance Wiki
Part Five: Automated Underwriting System Design
The discussion in Part Four dealt with Recon Engine design. This section will make clear the distinction between the Recon Engine and the larger Automated Underwriting System. Please see research paper
The Recon Engine is concerned with the ordering and analysis of data reports at the driver level. The output from the Recon Engine in turn becomes one of a number of elements considered in the Automated Underwriting System.
The Automated Underwriting System deals with the entire risk at the policy level. The Automated Underwriting System makes a number of decisions about the policy as a whole.
Residual Markets
If the state in which the system is used has a residual market mechanism (Assigned Risk Pool, JUA, etc.), the Automated Underwriting System (AUS) should determine which risks the company wishes to place there. In states where the company can retain a portion of the coverage (liability v. physical damage) and place the remaining portion in the residual market, the AUS should make this determination.
Special vehicle treatment
A good AUS will handle special rules concerning vehicles. For example, a vehicle considered “high performance” might be acceptable when driven by a 40 year old with no driving record points, but unacceptable when driven by a 25 year old with a speeding ticket. A good AUS will allow for these rules to be set.
The system should also allow for modifying the range of acceptable coverage limits/deductibles by vehicle and by vehicle/driver combination. Surcharges and discounts based on the VIN are also common features of a good AUS.
Accept some coverages, reject others
This is a similar decision to the one discussed under Residual Markets. The difference here is that a company might refuse to offer (within regulatory bounds) specific coverages to certain types of risks. This could result in the company writing a liability-only or physical-damage only policy.
Multiple tiers within same company
In some states, companies are permitted to have multiple underwriting tiers within the same legal entity. In these cases, companies have far greater flexibility in dealing with a wide variety of risks.
Instead of declining coverage or placing a risk in a residual market, the company may offer to insure the risk in a different tier, modifying the premium charged so that it is commensurate with the risk. A good AUS will display only certain tiers for each risk quoted.
Varying pay plans to encourage/discourage risks
An AUS should include the ability to modify payment plans offered according to the risk. This topic is discussed under Part 2.3 Insurer Responses to Regulatory Restrictions.
Contents |
[edit] Proven Values of Automated Underwriting
There are several principles in AUS design that have proven their value repeatedly in the marketplace:
Make decisions as early as possible in the process
Whether the AUS system is running on the web, on a network, or on a standalone PC, it is important to make the process run as quickly as possible. Proper system design can dramatically shorten the time required to price, underwrite, and issue a PPA policy.
Place “deal killers” upfront
To the extent possible, questions which will automatically disqualify a risk should be asked early in the process.
There are many systems still in use today that will allow a user to input all rating information concerning drivers, vehicles, and policy-level characteristics, order reports, and gather complete application information, then reject a risk because of the answer to one or more application questions.
Up front disqualification may be done in a variety of ways.
- One is displaying a screen at the beginning of the quote process listing the absolute eligibility requirements. Users must verify that all criteria are met before proceeding to more detailed data entry.
- Another option is to ask disqualifying questions individually at the outset of the process.
Once a risk is disqualified based on user entry, an appropriate message can be displayed and the entry can stop. This saves time and, in the case of report ordering, prevents spending the company’s money on unneeded MVRs, Credit Scores, and Accident Histories.
Prioritize inputs
All PPA policies have 3 types of inputs.
- vehicle information,
- driver information, and
- policy level information.
The sequence in which each of these types of information is gathered, and the order of questions within each sequence, should be carefully designed for ease of use and AUS efficiency.
For example, certain vehicles may be allowed only in certain program tiers, or may be eligible only for certain coverage levels. Once it has been determined that a vehicle falls into one of these categories, downstream questions should be modified or eliminated based on this information.
Similarly, drivers within certain age ranges or with specific violations may qualify for a limited range of policy limits or payment plans. These decisions, once made, should cue downstream changes in screen presentation.
[edit] Household level determination
In addition to looking at individual vehicles and drivers on a policy, an AUS should allow the company to set rules on a policy or “household” level:
Number of cars v Number of Drivers
Companies frequently make underwriting decisions based on this comparison. When the number of cars greatly exceeds the number of drivers, this may indicate the existence of additional undisclosed drivers.
More drivers than vehicles may lead the company to conclude that the insured vehicles will be used much more heavily, increasing the risk. They may also question the existence of other vehicles not disclosed. (This may happen in states where liability insurance is required in order to maintain registration).
Age/Sex/Marital Status/Relation to Insured
As in our hypothetical underwriting guidelines for Acme Insurance, companies may infer relationships or other policy characteristics from an analysis of these inputs. At the least, certain combinations may cue the presentation of additional clarifying questions.
Driving Experience
Underwriting actions are frequently taken based solely on driver age. In addition, the determination of which outside reports should be ordered may be influenced by the ages of drivers on a policy.
[edit] Determine handling of endorsements
Companies using a Recon Engine and AUS to process endorsements must decide whether they will take certain actions.
- canceling coverages or
- modifying coverages or
- changing tiers
These actions may be made midterm or they may set an indicator for the policy to be modified at the next renewal. In many states, regulations prevent certain midterm changes so placing indicators for renewal processing may be the only option.
Determine which reports to order, and when
The AUS must determine which reports are to be ordered for each quote. This determination is usually made by report type. For example, the decision to order credit may be based on the age of the named insured, or on the age of a secondary driver if the named insured is below a fixed age. Accident History reports may be ordered on some or all drivers, on an individual or household level, based on other inputs.
Verify accuracy of any rating/tiering input where possible
In systems utilizing outside report ordering and a Recon Engine, most driver-related data will be verified. The most commonly overlooked data element is driver age/date of birth. Because of the sensitivity of most rating algorithms to driver age, the system should automatically re-rate if driver age is changed based on outside reports.
For example, some systems in wide use today will ask for “driver age” in the quote process, and then ask for “driver date of birth” at a later point, such as in the application. These systems do not usually check these two entries against one another; a good AUS will.
Some insurance companies require that applicants submit written documentation in order to earn certain discounts. An example of this is requiring the submission of a policy declarations page as proof of a continuous coverage discount.
[edit] Verification methods which require follow up
Any procedure requiring a policy be monitored for follow-up, and then modified if the follow up requirement is not met, should be evaluated for effectiveness. Many companies have found such procedures to be error-prone and overly expensive. If verification involves hard copy or follow-up, reconsider it. If at all possible, replace these procedures with others that allow point-of-sale verification.
“Slotting” or “Scoring” of risks
Some Automated Underwriting Systems, particularly those associated with Risk Qualification programs, either assign scores to individual policies or place them into one of a series of groups.
The scored policies, or groups of policies, are then reviewed individually by insurance company staff who make the final decisions about pricing, tiering, etc. These systems are most commonly used in preferred or ultra-preferred programs where the company believes subjective factors also need to be considered. Some of the largest policy processing system vendors use this approach in their AUS design.
These systems, while an improvement over an entirely manual underwriting process, do not take full advantage of the efficiencies AUS can provide.
