Atlatl Makes Underwriting and Outside Report ordering and interpretation SIMPLY EASIER.

The Reconciliation Engine (Recon Engine) is a powerful software tool that allows insurance companies to analyze CLUE Reports according to the company’s specific rules and guidelines.

The Recon Engine can be integrated into Atlatl’s point of sale systems to enable agents to order and analyze these reports during the quote/application process and to arrive at the same results that a back office Underwriter would produce.

The Recon Engine is also used in company back office environments to process renewals, endorsements, and new business policies with reports returned from non-interactive sources.

When the Recon Engine is integrated into a point of sale system, the sales process is usually redesigned to incorporate an additional step into the process. Agents will begin by giving a quote as they currently do, rating the policy using the accidents and violations as given by the applicant. At some point in the process, either after determination of the quote price or during the application step, the point of sale system will initiate a Report Ordering module. This module determines the set of reports to be ordered for this specific quote. The assignment of drivers to vehicles and the associated "highest rated driver" logic is used to determine on which set of drivers CLUEs should be ordered. The report ordering rules also operate when quotes are amended—the addition or deletion of drivers and/or vehicles to a quote for which reports have previously been obtained will automatically initiate the execution of report ordering rules and the ordering of additional reports where required.

Report orders are submitted to ChoicePoint and the completed reports are returned to the point of sale system. The submission to ChoicePoint requires the use of either an intermediate server or the integration of ChoicePoint’s WEBTSS ordering product. The Recon Engine currently works with either product. Once reports are returned to the point of sale system, the Recon Engine logic executes to analyze the returned reports.

The Recon Engine executes company-specific rules to compare CLUE data to quote data using date tolerance rules, "stacking" of violations and accidents with the same occurrence dates, company rules for not at fault accidents, and other requirements. The updated attributes returned by the Recon Engine are then passed back to the rating system and the policy is repriced. The repricing takes place only upon completion of all report ordering, including CLUEs.

Messages are displayed to the agent whenever information obtained from report ordering results in a change to the policy price. The agent can then look at the accident and violation summary for each driver. The point of sale system will allow only those modifications to attributes specified by the company. For example, the system generally does not allow the agent to delete any accidents or violations found on CLUE reports. In some cases, companies choose to prevent the deletion of accidents entered by the agent which are in addition to those found on the reports. These rules are, of course, customized.

For those attributes the company does not permit the agent to delete, a "Dispute" function is included in the system. This will allow the agent to select a given accident or violation and enter a text explanation for why it should not be charged. This information is added to the upload record and displayed on the application. Whether or not to charge for disputed violations is at the company’s option.

CLUE Reports are analyzed at the same time as the MVR and the attributes input with the quote. CLUE’s are the most challenging reports to deal with for a variety of reasons. First, the format of the reports is variable. Second, the data returned is only as good as that provided by the submitting insurance carrier. Third, various types of additional "possibly related information" is returned. The Recon Engine includes logic to address each of these challenges.

First, the system analyzes the different types of "hit" information—Report Level matches, Subject Level matches, and partially related claims. Rules supplied by the company determine the first two kinds of matches. Using as distinct data elements first name, middle name, last name, date of birth, and drivers license number, the system compares the order data to the returned report. A matching hierarchy is used so that if, as an example, first name, drivers license number, and date of birth match but last name does not, the system can deem this a "match" (assuming last name changed due to marriage or divorce). Again, these rules are customized, and those returned reports which do not pass the matching rules are displayed to the agent with the options to accept, reject, or modify for reorder.

Partially related claims are analyzed in the same fashion. Those which pass the company’s matching rules are added to the policy without agent intervention. Usually a more stringent matching standard is applied to partially related claims. Those which don’t pass the test are displayed one at a time for the accept/reject decision by the agent.

All of the actions taken by the agent to accept or reject entire reports, subject level reports, and possibly related claims are captured and added to the upload record. Flags can be set to send uploaded policies for Underwriter review based on these actions.

Atlatl works with its insurance company clients to achieve three goals in the design of point of sale Recon Engine systems:

1. Speed: Minimize the duration of the report ordering and reconciliation process

2. Ease of Use: Create a straightforward, intuitive presentation to the user

3. Accuracy: Produce a truly "once and done" result

The third point—accuracy—is where we spend most of our time in design. As stated previously, analysis of CLUE reports is a bit different.

We work with company Underwriting personnel to understand how CLUE’s are currently processed in the back office, then incorporate that logic into the system. We find that in many cases, processing steps and time can be eliminated from the process. The most common example is that of possibly related claims. Frequently, Underwriters processing business manually who find a possibly related claim on a CLUE report will call or write the agent for an explanation. In many of these cases, a wide range of explanations will result in the accident’s not being charged. In the meantime, however, the policy may have been uprated and billing affected. Follow up and tracking of policies in question also creates work and increases time. We work with clients to understand this process and eliminate the additional work by either eliminating those accidents from charging when possible, or expediting the resolution through the "dispute" function. We also utilize the depth of detail which can be present on a CLUE report concerning cause of loss and amount paid on the claim to eliminate confusion. "Comp only" claims, or losses within certain dollar ranges can be handled properly.

The Recon Engine can be utilized in the insurance carrier’s home office to process renewals, endorsements, and new business policies that have non-interactive reports associated with them. Further discussions would be needed to understand the overall operating environment for an NT application.

When the Recon Engine is used at both the point of sale and in the home office, the modules run on each platform are identical. The additional code needed to address the specific needs of the back office system is all external to the Recon Engine itself.

The primary differences between the point of sale and back office uses of the Recon Engine are in the handling of "partial matches" and "partially related claims". As discussed previously, these issues are handled dynamically at the point of sale through screens presented to the agent during the reconciliation process. In the back office environment, an exception processing approach is used. Any partial matches or partially related claims requiring review are handled by setting an indicator on the policies returned to the company’s policy processing system. While the vast majority of policies with completed reconciliation are ready for processing without further manual intervention, those with the indicator set are directed to Underwriters for resolution of those issues.