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

This led to the search for those minimal characteristics withoutwhich a PAS is not a PAS. The result of that reductionistexercise was to identify a product definition capability—coverages,limits, deductibles and rules; and a policy life cycle transactionset—quote, issue, endorse, cancel/reinstate, renew, audit—as beingthe 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 soit's worth taking a tour around the PAS world in order to learnwhat you might expect to find.

I believe there has never been a better time for insurancecarriers to buy third-party core systems. One of the severalreasons for this statement is that the software provides morefunctionality for the same or fewer dollars.

The benchmark against which vendor PAS software is measured hasbeen rising steadily for several years and that benchmark includesthree major dimensions—general software quality, configurability,and business functionality. This article concerns thefunctionality dimension.

Generally, a PAS consists of a group of sub-systems which worktogether and also work through integrations with other externalcomponents to automate the administration of insurancepolicies. The core functions commonly supported by a PAS areproduct definition and pricing, policy lifecycle maintenance, andthe associated production of legal and regulatory documents. The PAS may also support distribution channels; compliance;statistical, bureau and regulatory reporting; and workmanagement. Here is a look see component by component:

Rating

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

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

Bureau Content

Closely related to the rating engine functionality is theprovision of bureau content. A rating engine without contentis an empty capability that has to be populated with rate pages andalgorithms. For those carriers that subscribe to bureaus suchas ISO and NCCI the provision of this data is a significantstarting point to implementing a new rating engine.

While few carriers use these rates (or loss cost data) withoutmodification, the initial load allows the carrier to deal with thedelta rather than start from scratch. An increasing number ofvendors offer this service as part of their softwareimplementation. Some carriers do this on a one time basiswhile others provide an ongoing service that allows carrier clientsto take rate, rule and form changes over time.

Product Definition

A PAS would not get very far without having the ability todefine the components of an insurance product and rules whichgovern the relationships between those components. In some ways aproduct definition engine is like a rating engine in that it hastwo major components: a library of allowable coverages, limits anddeductibles; and a set of rules (algorithms) that define how thesecoverage elements can be related across time, geographies and linesof business.

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

Policy Lifecycle

The policy lifecycle is the set of transactions that arerequired to create and maintain an in-force policy for a policyterm and reflect the changes to coverage during that period. Most transactions are event driven and reflect changes in the realworld—quoting, issuing, and endorsing are the most common; sometransactions are the indirect result of other actions (orinactions) such as cancellations which may be triggered fornonpayment of premium and reinstatement for subsequentpayment.

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

Document Production

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

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

The subsequent storage and archival of these outputs is oftendone by a document management component of an imaging/workflowsystem. The document creation capability is another “optional” PAScomponent. Some PAS solutions include a print capabilitywhile others integrate with third-party products, of which thereare several in the marketplace.

Portals

Increasingly PAS also provide support for the carrier'sdistribution and service channels, which commonly include bothagencies and self-served customers. As with the rating anddocument components there are third-party products that provideportal functionality that a PAS can integrate with if thefunctionality is not provided.

Portal functionality comes in two classes: for both agent andinsured the portal should allow some combination of quote, issue,endorse, and inquiry. Billing functions such as payments arecommonly included. For the agent the portal usually supportscommission management and book-of-business inquiry andanalysis.

Reporting

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

Most PAS include some basic operational reporting and a robustfeed for statistical reporting and data warehouse feeds; othersprovide a full warehousing and analytics database with regularfeeds and others provide pre-built feeds to third-party warehouseproducts.

Other Functions

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

Some PAS have an underwriting component separate from theproduct definition engine which supports the development andmaintenance of underwriting rules for risk selection and interactswith 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 ofdiffering compliance or underwriting requirements. And finally,some PAS include a reinsurance component to support various cededreinsurance contracts.

In Conclusion

If this sounds like a lot of capabilities, it is. As wesaid above, the bar is rising constantly as vendors compete forcarrier business. Add in the fact that most modern PAS alsohave capable integration and configuration toolkits and youconclude that a current PAS is a heavyweight piece ofsoftware.

Some, of course, are heavier than others, and most are strongerin some areas than others. While the news for carriers isgenerally good—and to repeat, there has never been a better timefor insurance carriers to buy third-party core systems—the issueremains that it is up to each carrier to decide which combinationof capabilities best suits its needs. The system with the mostfunctionality is not always the automatic best choice. Happyhunting.