When polices are downloaded from carriers (like through IVANS downloads, EBix Team-up Downloads or other 3rd party download applications) what should be done with each policy? Basically policy download actually means policy transactions download. Each downloaded record is a transaction related to a policy. For example policy Renewal (RWL – renewal of an existing policy), Non-Renewal (RWX – user decides to not to renew an existing policy), New Business Issue (NBS – new policy), Rewrite (REW – cancelling and rewriting an existing policy with modifications), Cancellation (XLC – cancel existing ongoing policy), Policy Change (PCH – endorsements or changes to an existing policy) or Reinstatement (REI – Reinstating a cancelled or suspended policy) are the possible transactions related to each record. Corresponding to each transaction back-end agency management system should be updated according to the expectations of the end user. For example in case of cancellation of a policy existing policy record in the agency management system should be located and marked as cancelled with other essential details like cancellation date, reason etc which are received in the transaction data. Similarly if endorsements are there (changes in existing policy) then the policy record in agency management system should be updated with new data OR some systems add a separate endorsement record so as to maintain entire history of changes. If it is a new policy transaction even in that case it is possible that the customer account already exists in the agency management system since that customer might already have an ongoing or expired policy from the past. Hence only policy record should be created and attached to the same customer account in this case. But if it is a new customer then customer account also needs to be created. These logical decisions for different transaction codes need the following –

– Identify if the policy already exists based on policy data received in the downloaded policy transaction
– Identify if the customer account already exists based on customer data received in the downloaded policy transaction

To identify the matching policy record in agency management system policy number is the starting point. But what if there are multiple records with same policy number (like if same policy was renewed 2-3 times earlier as well and all prior records are present, or if 2 different insurance companies issued policy with the same policy number)? So we need to add the second piece which is NAIC code (to identify the insurance carrier). With NAIC code + Policy Number we will be sure that we are searching within policies issued by the matching carrier only. But still the case of renewal or cancellation of same policy exists. That means if same policy was cancelled, renewed or rewritten earlier more than 1 record of the same may exist. So at this point we need to match other fields like policy status, lob code, effective date and expiration date to uniquely identify the matching policy record. If it is located that means next action can be taken according to the transaction code. But if a match is not found or still more than one policy records match that means a human being needs to take a look at the transaction record and manually match it to the correct policy. This is where Policy Reconcile process comes into picture. All such policy transactions are put into manual reconcile mode and user gets a screen to take a look at each such policy. User can search in existing policy database at this point and match the correct policy. This process is called as Policy Reconcile Process or Policy Reconciliation. User can choose to ignore a transaction, add a new transaction record or update an existing policy record here. Along with the manipulation of policies, related schedules and coverage are also created and updated.

Similar to the policy identification, customer account also needs to be identified. But unfortunately very little customer information comes along with downloaded transaction and based on this information it is not certain that correct customer account can be identified in most of the cases. Still some insurance software try to match first name, last name billing address etc to locate the customer account. If it is found it can be decided to link the same account to new policy transaction or otherwise if software is not built in such a way so as to auto identify the account then accounts can also be sent to reconcile page for manual mapping to existing account. This mapping step can also be on on same screen of policy reconcile page.

Finally, some insurance software give you a feature to configure that for Carrier 1 all policies should go to Reconcile page, for Carrier 2 all policies should be attempted to be updated automatically etc. In this way you can control it on carrier level.