(editor’s note – this is the final of a series on P&C Policy Admin technology. You can read Part 1 here: https://insnerds.com/pc-policy-admin-systems-take-data-in-do-things-spit-stuff-out-part-1/ . You can read Part 2 here: https://insnerds.com/pc-policy-admin-systems-take-data-in-do-things-spit-stuff-out-part-2/ This was adapted from an e-book written by Luke Magnan of Combined Ratio Solutions)

 

PART 2 – SPIT THINGS OUT

Policies

The pol admin system needs to produce some electronic policy document. This involves taking the list of of the forms scheduled in the user interface (see forms attachment above), filling in all the policy characteristics from the policy itself, producing a document electronically (think a PDF or word document, or maybe an electronic document made to go to a printer and mailed), and store that document.

How these forms are maintained is important. Can insurers update or add forms themselves? Are there templates that are housed in the system that anybody can update and that offer all the appropriate versioning? Does the vendor need to get involved? All important questions to weigh and ask.

Other Documents

While the policy is the most important document for a pol admin system to produce, it’s certainly not the only one. There are quote letters, binders, certificates of insurance, declination letters, cancellation letters. There’s lots of correspondence insurers have to juggle, and there’s no reason a policy administration system shouldn’t be able to automatically generate and store these at the appropriate times.

Some policy administration systems may have capabilities to integrate with your email system to automatically send documents at the appropriate times to the appropriate people. This can be a real boon for high-volume business.

Reporting and Analytics Data

Somehow, all that data in your policy administration system needs to be accessible for reporting and analytics. It’s your data, you need a way to leverage it to produce insight. Here’s yet another case where you need to look at your enterprise capabilities to determine how much the policy administration should do on its own, and how much it should enable other systems to do.

Some policy administration systems may have pre-built (canned) reports. Some might offer the ability to build your own reports. Others may expect you to have a separate data warehouse that generates its reports. You need to determine what’s best for you. At the VERY least a policy administration system needs to expose its data in such a way that it can be consumed by some other tools to build reports and perform analytics.

Some systems will have their own data warehouses that you can configure reports on or electronically pull from. Others might push out data to be consumed by a separate, external, data warehouse. Still, others might schedule batch feeds to external systems. Regardless, you need to have a sense of your data strategy and evaluate admin systems based on how well they fit into that strategy.

 

Statutory Reporting

Some businesses require regular, regulated reports to be sent to statutory bodies, like state regulators. Some systems will handle this, some will provide you the technical know-how so that you can do it yourself, others will expect you pull this from your data warehouse as specified above.

 

Audit Logs

Everything a user does should be logged, and you should be able to get at that log. If a quote is issued, you should be able to find out exactly who issued that quote and when. If a quote has a 60% schedule mod applied, you should be able to identify the user who applied it. How accessible this information is to end-users may vary, but you need full transparency into every action taken by every user, including other systems that initiated the change in the PAS.

 

Send Stuff Downstream

You’ve issued a policy, but that’s really only the beginning. Lots and lots of other systems in your portfolio desperately need that data to do their own work. Billing systems, claims systems, general ledgers, the list goes on and on. Some of those systems might prefer to actively “pull” data about a specific policy (or group of policies) on request, others might want feeds of data sent on a scheduled basis. No matter what, the pol admin system needs to be able to provide some solution.

From a technical viewpoint, there’s also going to be the issue of mapping data. You’ve got to get whatever format your policy administration system provides into the format the consuming system wants. Is that something that happens in the pol admin system and requires coding work from the vendor or your internal IT team? Can a third party tool handle the mapping? Are there ready-built integrations to certain general ledgers or, even more valuable, to agency management systems? These are all important considerations evaluating pol admin options.

 

Do Things

We’ve covered what policy administration systems do to take data in and we’ve covered what they need to spit-out, but we haven’t yet discussed all the things they do in between.
That’s ok though because honestly, I secretly got a LOT of that functionality covered in the prior two sections. There are only a few notable things I want to cover here.
Grab a drink of water, take a few deep breaths, we’re almost done.

Insurance Transactions

Sometimes people want to build their own policy administration systems. Maybe you’re shocked by the price or the duration of implementation and think you can do it faster and cheaper. Maybe you really want to tailor the solution to your exact business and the out-of-the-box vendor solutions just don’t align. Maybe you want to do wild things I’ve never even thought of in a pol admin system that will prove to be a real differentiator for your business.

I think this is great. I love the thought of building pol admin systems, particularly when you’re doing something different from other insurers. A word of caution, however. In my humble opinion, it is the ability to handle insurance transactions that are often overlooked when setting out to build it yourself, and the complexities here are what most often blow timeframes and budgets.

So what does it mean that a policy admin system can handle insurance transactions? I have tried to write the next sentence 75 times, each try more confusing and poorly worded than the last. It’s a tough question to answer. I’m going to try using an example.

Let’s imagine you love spreadsheets so much that you think you can capture policy data in Excel. Lots of companies do it in the beginning. Assume that each policy is on a new worksheet, and on each row in a policy’s worksheet you capture a different field for one policy. One row has some limit. Another has some deductible. A third has some location and class code. With me so far?

Now let’s say you want to capture a quote. Easy. The agent comes back and says they want a higher limit. You go ahead and overtype the value in your limit row to the new limit. So far so good. Now they issue the policy. Fine. Maybe the first row is the status and it used to say “quote” and you type in “issued”.

But what happens when they want to change that limit, and the change is effective three months after the effective date. You can’t just change the limit row. If you did that, and a claim occurred the first month you’d have no idea what the right limit was. So now you’d have to create a new column and copy all the data from the first column
to the second column, and just change the limit field in that second column. Alright. Not simple, but now you’ll just go ahead and for every change after the policy is issued, you’ll copy the latest column to a new column and make the change in the new column.

What happens if a change comes out of sequence though? What if you got a change requested and the effective date of the change is one month after the policy’s effective date? I guess you’d insert a new row between those other two, copy the row to the left and make the change there. But then you’d have to go to the row to the right and reflect it there too. What about a premium audit, where you need to record the audited exposures but it shouldn’t change the coverage in place. Or a cancel and reinstate. What if you need to cancel an endorsement.

Policy administration systems need to know how to capture insurance transactions in such a way that, for issued policies, you can always tell exactly what was on cover at any given date. You can always get a “picture” of what a policy looked like at a point in time. They should also allow changes in the policy without requiring you to go back and manually update other “pictures” of the policy, cause that’s just asking for trouble. For everything changed, they need to know how to tell downstream systems (as described above) about the impact.

They do this by knowing how to handle insurance transactions. That is the fundamental distinction on what makes a pol admin system a polocy admin system. My example above was goofy, but it illustrated that things quickly get complicated. An admin system needs to handle any business transaction you throw at it. If you know that you do outstanding premium adjustments on your workers’ comp book for whole states, you need to ensure your admin system can handle that. Same thing if you know that you need to support split audits, or out of sequence endorsements, or any of the other crazy things that might happen over the course of a policy’s life.

 

Workflow

I mentioned tasks in the “Take Some Data In” section above, but what drives that capability is some sort of workflow engine. As stated, this is optional, some admin systems will have it, some will let you easily integrate with a stand-alone workflow engine, some provide nothing.

Basically, a workflow engine lets you define how you will route (and track) the work that people will do. Maybe submissions come int the door and a task gets assigned to one team for data entry. When they finish the submission, a task is sent to an underwriter to go ahead and quote it. When they’re done, a task is sent to an underwriting assistant to create the proposal and send to the agent. All that is workflow.

If you’re writing transactional, high complexity, low volume business this might not be necessary at all. But if you’re dealing with a very high volume of work spread across
multiple teams, it may be critical. Different pol admin systems will have different levels of workflow sophistication they can support. Some companies may offer “workflow
consultation” services to help drive you to an optimum workflow, others might just want to automate what you already do.

Workflow is one of those things that can cause a whole policy administration project to go sideways before it even starts. Before even setting out to evaluate policy
administration vendors, it’s important to know how much of your workflow is in scope for change, and how much automation you want to put around it.

Also, having some form of workflow functionality is required if you want to get operational data out of your reporting and analytics (see above) in addition to risk and
coverage information. If you want to know how long it’s taken, on average, to turn submissions into quotes for a given line of business, you need some workflow components in there capturing the relevant data.

 

Rating

Somehow, your pol admin system needs to take your quote or policy and figure out how much it’s going to cost. This is generally bucketed under the “rating” functionality.
It’s a huge topic, and I’m not here to break down how it all happens, suffice to say that it needs to happen.

There are three typical scenarios. The first is that you want a policy administration system that includes its own rating engine. If you don’t have a rating engine already, or are migrating from a system that has its own, this is great. You still need to evaluate the rating engine based on whether it can support your rating processes and on how
easy it is to make changes or implement new products, but at least it’s all integrated for you out of the box.

The second is that you have or want to leverage a stand-alone rating engine. Maybe your rating is very unique and you’ve built one yourself. Maybe you want to
buy one of the stand-alone vendor rating engines. Either way, you need a policy administration system that can call an external rating engine, send it the appropriate
data, store relevant premium information in the response, and correctly handle and interpret any errors.

The third is that you want the users to just enter the rate and/or premium. Maybe you’re loving your excel raters, or maybe the right premium is whatever customers can
pay. In this case, you want to just ensure that anything you want the underwriters to enter can be exposed as part of the user interface.

An important consideration for the second and third scenarios though is who will handle all the stuff that happens after the rating engine returns the premium. Pro-rat
ing, additional or return premium, etc. It’s important that even if the premium comes from an independent system, the pol admin system can still process that premium as
appropriate given the nature of the transaction that triggered rating.

So for example, if you issued a policy with a premium of $1,000, and then halfway through the policy term you doubled the exposure, the policy may now be WORTH
$2,000 if it had initially been issued that way, but the additional premium that the insured needs to pay may only be $500, because they already paid $1,000, and the extra exposure was only for half a year.

The best practice is that the rating engine should be a calculator. It should take in risk characteristics and return the best price. It shouldn’t need to understand the state
of the policy or the type of transaction. The policy administration system should be capable of determining the correct impact to that specific policy based on the calculation the rating engine did.

This may not always hold true, but it gets complicated. Understanding which system owns which bit of processing is an important thing to take into consideration.
Finally, it’s good to know where other things that impact the total cost of the policy reside. Where are commissions? How about state taxes? These are all things that don’t
necessarily belong in a rating engine, so the factors and the calculations probably need to be supported in the policy administration system.

 

Integrate With External Systems

There are many times you might want external systems to have a say in what’s going on with a policy. For property you may want to call out to ISO to get building data. You
might write a bespoke policy that requires some special calculation to determine available limits that you have in an external system. For auto you could want to per
form VIN lookups. When cancelling a policy, you might call out to a claims system to see if there are any open claims. There are lots and lots of times where getting data
from outside enriches your underwriting process.

Some of these integrations might happen directly in the user interface and some might happen behind the scenes, but a policy administration system needs to allow
them. There need to be “hooks” by which the system can make all these fancy integrations happen. It’s good to understand both what integrations policy administration
systems support “out of the box”, what your own IT team can build themselves, and what the vendor needs to do as part of a service engagement. Few things drive up costs and timelines as much as very complicated integrations.

 

Other Annoying Complexities

There are a few complex scenarios I just want to mention. These are things only some admin systems do well, and you should absolutely know whether or not you require
them. If you DO need one or more of the below pieces of functionality, and you were trying to find vendors that do a good job, my advice would be to look at those with
heavy footprints in the London market.

Multi-Currency

This speaks for itself. Do you write business where you need to consider multiple currencies? Do you have separate legal entities that each has a different accounting currency? Do you need to bill in different currencies? This is typically a bigger issue for billing and claims systems, but if you really need deep multi-currency functionality,
you need to find a vendor that differentiates itself on that.

 

Multi-Language

From a technical perspective, this is hard to do well. Not complex, just a lot of work. If you are operating in multiple geographies and want users to see their own language
depending on where they work, policy administration systems need to make special allowances to support that.

Multi-Locale

Maybe you’re writing offshore energy, and you want one policy for one client who has 10 rigs spread across 10 different jurisdictions. You’d need a system architected with
this capability in mind.

Layers

Imagine an aviation policy where you’re writing a 2 million limit excess of 2 million, and then 5 million limit excess of 5 million. Someone else has taken the layer in the
middle. Do you need both layers on a single policy? Do you want to see an “excess tower” of all the layers, and track where the underlying layers were placed? Again,
you’d need a more “niche” policy administration system geared towards these types of complex risks.

London Market

I spent 4 years at a P&C full-suite vendor based out of London, so I know enough to never, ever publicly speak about how I think the London Market works, because I’m al
ways wrong about something important. That being said, if you’re writing subscription business, integrating with Lloyd’s, etc. you’ll want a system purpose built to do just
that.

Conclusion

This was a lot. The crazy part is, I’m really just scratching the surface. People spend their whole careers thinking about P&C policy administration systems, it’s a deep top
ic, and it’s evolving as surely and slowly as P&C insurance is evolving.

I hope you walk out of here with three things though. First, an understanding that no matter how complex things are, we really are just taking some data in, doing things
to it, and spitting things out. You can always take the most complex piece of functionality and boil it back down to that concept. I find that a comforting thought. Second,
an understanding of what policy administration system needs to do, at a high level. Third, a rough inventory of the kinds of things that policy administration systems
sometimes do.

Thanks, and good luck!
-Luke Magnan
luke.magnan@combinedrat.io