Given the importance of policy administration systems (PAS) it seems useful to revisit the issue of what a PAS actually is. In previous articles we touched on the notion that although we commonly refer to and discuss PAS there actually is no common definition of what one is.

This led to the search for those minimal characteristics without which a PAS is not a PAS. The result of that reductionist exercise was to identify a product definition capability—coverages, limits, deductibles and rules; and a policy life cycle transaction set—quote, issue, endorse, cancel/reinstate, renew, audit—as being the core of what a PAS is.

While this is still correct it misses the modern day point that, like modern day Americans, policy systems are putting on weight. Most vendors offer functionality well beyond this minimal core so it's worth taking a tour around the PAS world in order to learn what you might expect to find.

I believe there has never been a better time for insurance carriers to buy third-party core systems. One of the several reasons for this statement is that the software provides more functionality for the same or fewer dollars.

The benchmark against which vendor PAS software is measured has been rising steadily for several years and that benchmark includes three major dimensions—general software quality, configurability, and business functionality. This article concerns the functionality dimension.

Generally, a PAS consists of a group of sub-systems which work together and also work through integrations with other external components to automate the administration of insurance policies. The core functions commonly supported by a PAS are product definition and pricing, policy lifecycle maintenance, and the associated production of legal and regulatory documents. The PAS may also support distribution channels; compliance; statistical, bureau and regulatory reporting; and work management. Here is a look see component by component:

Rating

Most but not all PAS contain a rating engine. If the PAS does not contain its own rating engine than it will have integration points to third-party products, of which there are several available in the marketplace.

The key function of a rating engine is to generate a price for the insurance coverage. In order to do this it needs at least two components—the ability to load, store and maintain a library of rates which vary by time, geography, and coverages; and rating algorithms which determine the costs (premiums) for individual coverages and the overall policy. The rating engine must be capable of supporting different types of algorithms, which reflect different rating methodologies and lines of business. The software should also support testing, debugging, and “what if” types of processing.

Bureau Content

Closely related to the rating engine functionality is the provision of bureau content. A rating engine without content is an empty capability that has to be populated with rate pages and algorithms. For those carriers that subscribe to bureaus such as ISO and NCCI the provision of this data is a significant starting point to implementing a new rating engine.

While few carriers use these rates (or loss cost data) without modification, the initial load allows the carrier to deal with the delta rather than start from scratch. An increasing number of vendors offer this service as part of their software implementation. Some carriers do this on a one time basis while others provide an ongoing service that allows carrier clients to take rate, rule and form changes over time.

Product Definition

A PAS would not get very far without having the ability to define the components of an insurance product and rules which govern the relationships between those components. In some ways a product definition engine is like a rating engine in that it has two major components: a library of allowable coverages, limits and deductibles; and a set of rules (algorithms) that define how these coverage elements can be related across time, geographies and lines of business.

However, product definition engines are not optional to a PAS in the same way rating engines are. It is neither easy, nor common, to implement a third-party product definition engine in the way it is with rating.

Policy Lifecycle

The policy lifecycle is the set of transactions that are required to create and maintain an in-force policy for a policy term and reflect the changes to coverage during that period. Most transactions are event driven and reflect changes in the real world—quoting, issuing, and endorsing are the most common; some transactions are the indirect result of other actions (or inactions) such as cancellations which may be triggered for nonpayment of premium and reinstatement for subsequent payment.

Renewal processing is date driven and reflects the creation of a new policy term in preparation for the expiration of the current term. Audit processing happens for certain lines of business e.g. workers' compensation, where estimated exposures are used for pricing and need to be finalized. The major complications to the policy lifecycle are regulatory and compliance details, which vary by line of business and by state and generate large numbers of exception conditions that must be accounted for.

Document Production

Insurance companies produce prodigious amounts of paper (and now, increasingly, electronic) documents. Many of these documents are related to the legal terms and conditions under which the policy provides coverage and vary in detail (again) by time, geography, and line of business. It is common for a carrier to have a library of several thousand forms in which not only the language is specified, but the placement and even fonts that are allowed.

So, like the rating engine and product engines the “print engine” must be capable of developing or importing and storing a library of document templates—with both static and variable content—and having those templates retrieved and incorporated into print streams by rules evoked by the policy and rating components.

The subsequent storage and archival of these outputs is often done by a document management component of an imaging/workflow system. The document creation capability is another “optional” PAS component. Some PAS solutions include a print capability while others integrate with third-party products, of which there are several in the marketplace.

Portals

Increasingly PAS also provide support for the carrier's distribution and service channels, which commonly include both agencies and self-served customers. As with the rating and document components there are third-party products that provide portal functionality that a PAS can integrate with if the functionality is not provided.

Portal functionality comes in two classes: for both agent and insured the portal should allow some combination of quote, issue, endorse, and inquiry. Billing functions such as payments are commonly included. For the agent the portal usually supports commission management and book-of-business inquiry and analysis.

Reporting

Reporting is one of those terms which can mean a lot or very little. Reporting can include basic operational reports, bureau and compliance reporting, data warehousing and analytics, and finally predictive analytics incorporating extensive third-party data.

Most PAS include some basic operational reporting and a robust feed for statistical reporting and data warehouse feeds; others provide a full warehousing and analytics database with regular feeds and others provide pre-built feeds to third-party warehouse products.

Other Functions

There are several additional functions which the PAS may include. Most modern systems are client-centric; that is they support a higher level or account view of the book of business. This allows the carrier to see where policies are—or aren't—cross sold and to track trends and store data at the level of the buying entity rather than repetitively at the policy level.

Some PAS have an underwriting component separate from the product definition engine which supports the development and maintenance of underwriting rules for risk selection and interacts with the rating engine to select rate tiers.

Some PAS include a significant amount of workflow management, which allows the carrier to vary system behavior to take account of differing compliance or underwriting requirements. And finally, some PAS include a reinsurance component to support various ceded reinsurance contracts.

In Conclusion

If this sounds like a lot of capabilities, it is. As we said above, the bar is rising constantly as vendors compete for carrier business. Add in the fact that most modern PAS also have capable integration and configuration toolkits and you conclude that a current PAS is a heavyweight piece of software.

Some, of course, are heavier than others, and most are stronger in some areas than others. While the news for carriers is generally good—and to repeat, there has never been a better time for insurance carriers to buy third-party core systems—the issue remains that it is up to each carrier to decide which combination of capabilities best suits its needs. The system with the most functionality is not always the automatic best choice. Happy hunting.

Special Reports /

Shop Talk: It&rsquo;s Not Heavy, It&rsquo;s My PAS

Related Stories

Recommended For You

Shop Talk: It’s Not Heavy, It’s My PAS