Part Four: Analyzing Underwriting Information
From The Original Insurance Wiki
Part Four: Analyzing Underwriting Information
Contents |
[edit] Reconciliation Engines and How They Work
The term “Reconciliation Engine” (Recon Engine) refers to a software system designed to
- take multiple sources of information on a single subject
- and reduce them to a single, integrated output file.
For the purposes of our discussion, a Recon Engine takes input regarding the driving and accident records of applicants for PPA from numerous sources, analyzes the data, and creates a consolidated output record combining the data from all sources. Data from agent or applicant entry, along with data from MVRs and Claims History reports, are all reduced to one final data set.
Recon Engines can be used at the point of sale or in the home office of an insurance company, and can process new business, endorsements and renewals.
[edit] Using a Recon Engine at Point of Sale
“Point of sale” (POS) for our purposes refers to transacting the sale of a new PPA insurance policy. Whether this transaction takes place
- in the office of an independent or captive agent
- over the Internet directly with the applicant
- over the phone with a direct sales representative
it is still a POS transaction that can make use of a Recon Engine and automated underwriting.
Many Recon Engines are integrated into Windows-based rating and policy issue systems running on PC’s or networks in agency offices. This is still the most common method for the independent agency distribution channel. In these situations, the software includes a communications module to dial out or access an open Internet connection and order reports (Credit, MVR, and Claims History) from third-party information suppliers.
Recon Engines can also be integrated into web-based PPA rating systems, whether the system is designed for use by agents or by the insurance-buying consumer. Because these systems reside on Internet servers, outside report ordering is simplified.
Under either arrangement, report order transactions must be formatted properly and submitted to the correct information supplier. Formatting of the orders is usually the first process handled by the Recon Engine. The next step is actual submission of the orders, which can take place in two basic ways:
Direct connection to the supplier
Some report suppliers will allow direct access to their ordering systems from PCs, provided prior authorization has been established. This method is utilized in some standalone PC rating and issue systems with a Recon component.
Connection via a carrier-maintained server
This method has all report orders, whether they originate on PC’s or on an Internet rating system, sent to a server owned and operated by the insurance carrier. This server receives the orders, relays them to the proper information provider, awaits return of the completed report orders, and then routes them back to the correct ordering entity (individual PC or thread in an Internet rating application).
Connection via a third-party communications server
There are companies whose business includes offering communications server capacity and support. These organizations will provide the services described above for a monthly fee.
Once reports are returned to the Recon Engine, they are analyzed along with user-input data to arrive at a final set of attributes for each driver on the policy. Policy-level attributes may also be created. How these data sets are used in the higher-level automated underwriting process will be discussed in a later section.
[edit] Home office use—renewals and endorsements
Recon Engines are also used in insurance company home offices to process endorsements and renewals. In these cases, data from newly ordered reports is compared to the information already on a policy (rather than to the applicant’s representation of his driving record). The output file represents those attributes to be used for the remainder of the policy term (endorsements) or for the next policy term (renewals).
Endorsements are generally processed one at a time, like new business.
Renewals are usually processed in large batches some weeks or months ahead of the renewal effective date. Recon Engines can be designed to run in a batch mode to process renewals, pulling the current term data from the back office processing system and reconciling it to new MVR and Claims data to arrive at the set of attributes for the renewal term. This process is extremely efficient and can be the source of significant reductions in clerical staff when properly implemented as part of an overall automated underwriting system.
[edit] Reconciliation Rules
Report Ordering Rules
Cost
Integrated Recon Engine systems should include a module used to determine which reports to order under which circumstances. Cost can be a meaningful factor in deciding when and what reports to order. Third-party reports range in price from 40 or 50 cents to nearly $10. The price depends on the type of report, which information provider is supplying the report, volume pricing arrangements, and the ultimate source of the report (state DMVs set high, non-negotiable prices for MVRs).
Timing
Most integrated Recon Engines allow for an initial quote to be generated without ordering MVRs or Claim History Reports. The user—agent or consumer—is presented with a tentative price based on their representation of the risk. In order to proceed from the quote stage to the application stage, those reports must be ordered.
Some designs order a Credit Score during the quote process. This is done in situations where insurance companies are allowed to underwrite based on credit. Some risks can be eliminated early on based solely on Credit Score, saving time and the unnecessary ordering of additional reports.
Report ordering rules are used to determine which reports should be ordered for a given application. Some carriers will not order Credit Scores on certain drivers based on their age, because any information returned would be of limited utility and not worth the cost of the report. Some information providers offer “household” order pricing, which provides a discount over ordering individual reports when more than 2 drivers are on a policy. Rules on when to order Accident Histories also vary based on known characteristics of the risk—ages and marital status of drivers, coverages or limits applied for, user-input driving attributes, etc.
Some systems are designed to make report ordering iterative. For example, the decision to order Accident Histories is not made until the MVRs have been returned and analyzed. A good Recon Engine design will allow for these rules to be set by the company.
Matching Rules
After reports are returned from the provider, it is a good idea to verify that the reports actually pertain to the individuals for whom they were ordered. Various combinations of first name, last name, date of birth, driver’s license number, and SSN can be used to match a returned report to the applicant(s).
Rules should be set for complete and partial matches. In the case of a complete match, processing proceeds to the analysis stage without user intervention.
In the case of a partial match, the user is presented with a comparison of the details as ordered and the details on the returned reports. The user is given options to accept the returned reports, modify the order information and re-order, or reject the returned reports. Actions to be taken in the analysis and Automated Underwriting steps must be specified by the company and built into the system logic.
Analysis Rules
The ability to analyze multiple external reports with data input by the user, and arrive at one set of attributes for a policy, is the primary function of a Recon Engine. Analysis rules fall into several categories:
Accident Histories
These reports are the most complex and, because of their variable format, the most difficult to analyze.
Accident histories may contain a great deal of information that is either irrelevant to the underwriting/pricing process or not usable for various reasons. (“Not usable” information is discussed below under the heading “Undisclosed Information”).
A Recon Engine must be designed to analyze reports in the format returned by the company’s information supplier. In most cases this means reading through strings of data searching for code/date combinations that are relevant to the company’s underwriting process. Irrelevant data must be disregarded.
Once an Accident History report has been reduced to only the relevant data, detailed analysis can begin.
The Recon Engine must be able to determine
- chargeable accidents and
- the number of points to be charged.
These decisions are made based on
- the coverages under which payments have been made and
- the amounts of those payments.
The system will have to distinguish claims that are
- open with reserves set, but no payments made, from
- claims where payments have been issued.
Subrogated claims will also require special handling, as subrogation may override other rules for determining chargeability.
The final result of analysis of an Accident History report is
- a set of accident attributes, by driver, along with the
- company-specific attribute code and
- occurrence date to be used.
[edit] MVRs
Most suppliers of MVRs use a system of standardized codes for MVRs, regardless of their state of origin. This means that a single code will be used to represent the violation that may be described on different state’s MVRs as “running a red light”, “failure to stop”, “failure to obey traffic control device” and so forth. The information providers have gone to great length to analyze the laws and regulations of the states to come up with one comprehensive set of violation codes. This drastically simplifies the MVR analysis process.
Company-specific rules are applied to the information contained in the MVRs to arrive at a set of attributes and occurrence/violation dates by driver.
Date Rules
After analyzing the Accident History and MVRs, the Recon Engine will compare those attributes to the data previously input by the agent (or other user). All of these attributes are first analyzed to make sure they fall within the legal chargeability period for the state. Any attributes that fall outside the legal time period are eliminated from point computations, although they may still be considered in tiering or other AUS (automated underwriting system) decisions in some cases.
The next step is usually to apply date rules to these 3 sets of attributes to eliminate duplicates. Date rules vary by company, but usually include:
Exact date match
Keep only the attribute from the “best” source where the attribute codes and dates are an exact match.
Date tolerance
Where the agent has input an attribute that matches one from an external report, but the dates differ within a specified range (for example, 30 days), keep the attribute from the “best” source and disregard the others.
One year rule
Where the agent has input an attribute which matches exactly one returned from an external report, except that the date differs by exactly one year, the Recon Engine may be designed to consider these the same violation and keep the attribute from the “best” source.
Stacking Rules
These rules deal with accidents and violations that occur on the same date, or with multiple violations occurring on the same date. Treatment of such cases may be dictated by state regulation, or may be at the option of the insurer.
The Recon Engine must have rules to determine which attributes to create in these circumstances.
Rules may include adding a special attribute for the violation/accident(s) not charged, so they can be considered in underwriting/tiering without charging any points. Some rules specify the creation of a new “combination attribute” to charge the correct points while also conveying that another violation/accident with the same date was not charged.
Violation Rules
These rules deal with reconciling data input by the agent to that returned on the MVR. (Claims History data does not usually result in the addition of moving violations to a driver).
In contrast to the date rules and stacking rules, these rules specify the action to be taken if the two sources show different violations on the same date. They also tell what to do if the agent has input violations not found on the MVR. Companies differ on the handling of these situations.
Accident Rules
These rules specify what to do when accidents with the same date appear from multiple sources. Rules usually specify a hierarchy, based on completeness and detail, for which source is to be used. Accident History reports usually have the most detailed and complete information about chargeability and payment amount; therefore, information from Accident Histories usually takes precedence over the other sources.
MVR information, when it appears, may or may not take precedence over data input by the user. Companies must also specify what to do when the user has added an accident that appears on no outside reports and doesn’t fall within any set date tolerance. Some companies will automatically charge for such accidents, while others ignore them.
Unverifiable Driving Records
It is important to build in rules to handle drivers for whom no MVR is available. (See also earlier mention of International Drivers Licenses). Some applicants are out to “beat the system” by avoiding being charged for incidents on their driving records. They may provide inaccurate information concerning license numbers, dates of birth, or other order information so as to make acquiring their MVRs impossible. Most companies will build in an automatic, and usually punitive, surcharge for drivers whose MVRs cannot be ordered.
Undisclosed Information
Suppliers of MVRs and Accident Histories usually market a variety of other reports intended to disclose information such as
- other licensed operators living at an applicant’s address,
- prior claims reported on specific vehicles,
- claims associated with a given address, and so forth.
Rules for handling this information can be built into a Recon Engine.
Companies need to carefully analyze their options regarding these sources of data to make sure the information they might contain will be actionable in the company’s context.
As an example, the discovery of an undisclosed licensed driver may not permit the company to add that driver to its policy and alter the premium. The company might want to set a rule under these circumstances to request that the applicant provide evidence of other insurance for the undisclosed driver, and to take rating action only if such proof is not provided.
Similarly, a report indicating that a claim was paid involving a vehicle with a specific VIN is generally not actionable, because the applicant may have acquired the vehicle from its previous owner subsequent to that claim.
[edit] Good Recon Engines will allow rules to be set for these additional report types.
Deriving the final set of attributes
The final step in the Recon process is the execution of all rules and the creation of one final set of attributes for each driver. Because there are potentially three sources of information for a given attribute, the rules may be applied sequentially
- first compare user input to MVR data
- then compare that result to Accident History data or
- use a matrix.
The matrix approach involves setting up a table to show which data source should be used in determining the final attribute.
Honesty Rules
Nearly all PPA quotes begin by entering an applicant’s representation of his/her driving record. As mentioned under the heading “Subjective (‘Soft”) Sources”, smart companies track what information was provided truthfully by an applicant/agent vs. the information gathered only through third-party reports.
Good Recon Engine systems will include codes indicating where attributes came from—admission by the applicant, outside reports, or both. Companies can then use this information in the underwriting/pricing/tiering process.
We believe that there is a qualitative difference between a 12-point risk where the insured told the company about all twelve points in the application process and another 12-point risk who initially told the company he had not points at all. Whether this qualitative difference can be quantified—by altering the price or terms of a policy—is up to the company and its flexibility in the given market.
A good Recon Engine will record and preserve this data so that it can be used where and when appropriate.
