(editor’s note – this is part 1 of a series on P&C Policy Admin technology. This was adapted from an e-book written by Luke Magnan of Combined Ratio Solutions)
This is a primer on what P&C policy administration systems do for insurers. It’s not an authoritative guide. I didn’t write it for the experts. I wanted people new to P&C insurance (or new to P&C insurance systems) to have something to turn to when bumping their heads up against these behemoths. I wanted this to be a place to start.
If you’re interested in who the heck I am, and the “why” behind this article, you can read the prelude here.
Start Simple
A very wise man told me at the beginning of my career that all any insurance system does is take some data in, do some stuff to it, and spit things out. That would be a GROSS oversimplification of what modern policy administration systems do, right? Yes, of course, it would. But still, it’s a useful basis to begin to understand the reasoning behind these systems.
It’s easy to get caught up in the complexities when looking at policy administration, and certainly, the pol admin vendors are happy to start there, wowing us with descriptions of sophisticated capabilities, but I think it’s worth starting from a place of simplicity. Let’s go.
What does a Policy Administration System Need to Do?
Issue Policies
Let’s start with what a policy administration system (PAS) does at the most fundamental level. The most important job of a PAS is to store information related to an insurance policy. Obviously, right? For this part of the conversation, assume that an insurance policy is one that is on cover. You’ve issued it. It’s in force. Someone is carrying the risks laid out within that policy, on behalf of a customer.
So the pol admin system acts as the source of truth for issued policies. It, therefore, needs to allow you to execute transactions against an in-force policy to change it. I’ll get into what I mean by transactions later, but let’s just say that the system is responsible for letting you make a substantive change to an insurance policy. This includes endorsements (policy changes), cancels, reinstates, etc. etc.
Finally, you need to be able to renew a policy upon expiration. Your customer was happy with you last year, they want to stick with you this year, their policy gets renewed.
Submissions and Quotes
Now, what are a policy administration system’s responsibilities BEFORE a policy is issued? Well, that varies, but I’m a P&C guy, and I think it’s fair to say based on systems people have built and systems people are selling, that policy administration systems, as a general rule, are also required to handle the quoting life-cycle.
There are absolutely cases where external systems handle the “pre-bind” side of the policy life-cycle. How insurance carrier systems handle their distribution channels is a whole separate topic, but for now, I contend that, as a best practice, the policy administration system should be able to represent that piece of the puzzle. In my experience, it greatly simplifies portfolio architecture if the policy administration system is the system of record for all stages of the life-cycle, even if it’s not the system response or the user experience.
This means a policy administration system needs to work a risk through a process. At it’s most fundamental level I will define the life cycle as follows:
- Someone submits a risk to you, sometimes with an indication of the level of protection preferred
- You can decide to quote the risk, which means offering an indicative price for the policy, and details on what coverage that price includes. This will be an iterative process as you uncover more details on the risk, drive towards the right price, and refine the right level of protection
- Someone can decide to buy that risk from you, which means you go through a process to turn that quote into an issued policy
Now, this lifecycle might vary from customer to customer. Some will have separate systems to handle submissions and quoting, in which case maybe only quotes get to the policy admin system, or in rare cases only issued policies. Some companies will have a very formal step to bind a quote prior to issuance, while others will move right from quoted to issued in the system.
A Business Example
Alright, now we’re looking like…something. Let’s apply a real-world insurance buying example to the policy administration system. The details won’t apply the same to everyone, and there will be lots of OTHER systems used in this process that I’m not going to mention, but I think it helps create a functional baseline.
Let’s take a commercial insurance example, I’ll use workers’ compensation.
An agent starts working with a new client. This client is looking for a new workers’ compensation policy. The agent gathers a whole bunch of information about the business, gets it into some form of application along with their expert opinion on the required protection, and submits it to a few insurance companies, including yours.
Someone enters some very high-level information about the risk into the policy administration system to create a submission. The pol admin system now has a record that something was REQUESTED of you, enough data about what was requested, who did the requesting, and on behalf of whom. Now a determination needs to be made about whether or not there’s an appetite for this risk. If there is, we move forward to quote.
Now, somehow that submission is marked as being in a “quote” status in the PAS. A quote will have all the information from the submission, but then it will need a lot more information. If the submission was just about the who and the what of the risk, the quote is about the insurance being offered to protect the risk. Underwriting will come into play, and limits, deductibles, coverages, endorsements (not policy change transactions here, but amendments or additions to coverage) will be selected. Based on all that, the right price to purchase that policy will be determined.
Somehow, the details of the insurance coverage and the price will be communicated to the agent. They might request changes and underwriters might request more information, but in this scenario let’s assume that the agent confers with the customer (the prospective insured) and decides they want to purchase your quote. Good news. The agent will communicate that to you, and you will find the quote they want to purchase in the policy administration system (because maybe the previously stated back-and-forth created lots of different quote options). They will somehow convert that quote to an issued policy (perhaps having bound it first), usually enter more data, indicate to the system they’re ready to roll, and the policy administration system will
create a policy.
The details of that policy will then be produced into a document, a legal contract. That document will be sent back to the agent. Finishing the example, the customer (now the insured) can tell you or their agent of anything they want to change about the policy (including canceling it) and you can go into the policy administration system and make that change. It’s important to note here that the policy administration system needs to be able to support the following:
1. At any point in time, you can go into that policy administration system and understand exactly what the policy looked like on a given day.
1.1 Imagine you have a 12-month policy that was in force between January 1 (the effective date) and December 31 (the expiration date). Over the course of that policy, lots of changes were requested, some were effective on January 1st, but others were effective at various other times between the effective and expiration dates. You should be able to plug in any date and see exactly what the policy looked like.
2. You can see a clear progression of all the steps that led to the issuance of that policy. You can see the submission, how and when it turned into a quote, how many times it was quoted, and which quote led to the issuance of a policy.
HERE’S A GLIMPSE ON WHAT YOU WILL READ IN PART 2
Can We Please Get to the Actual Functionality
Ok, I hear you. Every pol admin vendor’s website is full of lots of features that we should take as differentiators, but what do they really mean? What’s important?
Let’s go back to the too-simplified words I heard at the onset of my career: Let’s apply that to the business example above….
About Luke Magnan
Luke Magnan is the Chief Operating Officer (COO) for Combined Ratio, an insurance technology services provider specializing in maximizing the value commercial lines property and casualty (P&C) insurance companies have invested in existing IT infrastructure. As Combined Ratio’s COO, Magnan drives operational strategy and success. He has executive oversight for Combined Ratio’s services and product divisions. With nearly 20 years of industry experience, Magnan is an expert on property and casualty (P&C) insurance technology having worked in both insurance company and vendor organizations performing various strategy, sales, and implementation leadership roles. He has significant experience optimizing core systems and completing replacement or modernization initiatives. He has a proven track record working with insurance executives to help understand business drivers, pain points in system portfolios, suggest opportunities for modernization, and identify where unique solutions provide can provide business benefit while reducing cost. He began his career as a programmer with The Hartford and moved up quickly to leading teams of developers and maintaining responsibility for many core platforms before becoming senior program architect. He spent time as a solution architect for both Insurity and AgencyPort before joining Xuber as lead solution architect in the U.S., and then becoming AVP of sales engineering and solution architecture in North America. Magnan graduated from the York College of Pennsylvania with a B.S. in Information Technology, before going on to receive an M.B.A. from the University of Connecticut School of Business.
Luke Magnan is the Chief Operating Officer (COO) for Combined Ratio, an insurance technology services provider specializing in maximizing the value commercial lines property and casualty (P&C) insurance companies have invested in existing IT infrastructure.
As Combined Ratio’s COO, Magnan drives operational strategy and success. He has executive oversight for Combined Ratio’s services and product divisions.
With nearly 20 years of industry experience, Magnan is an expert on property and casualty (P&C) insurance technology having worked in both insurance company and vendor organizations performing various strategy, sales, and implementation leadership roles. He has significant experience optimizing core systems and completing replacement or modernization initiatives. He has a proven track record working with insurance executives to help understand business drivers, pain points in system portfolios, suggest opportunities for modernization, and identify where unique solutions provide can provide business benefit while reducing cost.
He began his career as a programmer with The Hartford and moved up quickly to leading teams of developers and maintaining responsibility for many core platforms before becoming senior program architect. He spent time as a solution architect for both Insurity and AgencyPort before joining Xuber as lead solution architect in the U.S., and then becoming AVP of sales engineering and solution architecture in North America.
Magnan graduated from the York College of Pennsylvania with a B.S. in Information Technology, before going on to receive an M.B.A. from the University of Connecticut School of Business.
