The policy administration system (PAS) is the electronic heart and lungs of an insurance operation. The PAS stores information about each insured risk, generates the company’s top-line revenue numbers (direct written premiums), issues legally binding insurance agreements, tells the billing system how much it needs to collect, and validates whether or not claims are covered and payable. And yet there is no agreed definition of what a PAS actually consists of; indeed, some would argue not everything on the foregoing list is a vital function of a PAS. This fact is not just an interesting lexicographical foible. It is an important factor to be taken into account by any carrier that decides it needs to replace its PAS. How can a carrier successfully search for a new mission-critical system without knowing what constitutes the object of the search?
Time and again I have been involved with a client company intent on replacing a PAS where the search team has assumed the new system would have the same functional footprint as the legacy system and only one piece of software would be required to fit the bill. This often proves to be a false assumption that causes confusion and consternation.
There are two major variables along which the PAS varies in terms of its functional footprint. The first variable is chronological: Generally speaking, the newer the PAS, the smaller the functional footprint. Let me be clear about what I just said, or rather what I did not say. I did not say the newer PAS does less. The concept of a functional footprint essentially is a two-dimensional construct. It addresses the question of how much functional real estate the system covers. However, the true scope of a system is a three-dimensional construct that includes the critical element of depth. So, generally, what modern developers of the PAS have done is to focus on a deeper solution for a smaller problem set, which by definition is the problem set those vendors consider to be central to the role of a PAS. We will return to this central role later as it directly addresses the question: “What makes a PAS a PAS?”
The second variable relates to the size of carrier for which the vendor is developing software. For the most part, the smaller the carrier, the larger it wants the functional footprint to be. The small carrier is looking for “the biggest bang for its buck.” The larger the functional footprint, the thinking goes, the fewer other pieces of software will have to be purchased. The large carriers differ in some important ways from the small carriers: First, they have existing software components they wish to retain, and this creates a smaller “replacement space” for the new PAS; second, and related, large carriers have IT architects on their staff whose job it is to plan and map the use and reuse of various system assets, which reduces the need for “end-to-end solutions”; third, the larger carriers tend to have much more complex policy processing needs based on multiple insurance products and geographies as well as major scalability issues that the small carrier does not have; fourth, although I’m sure the large carrier CIO would wince to see it in writing, big carriers have a lot more money to spend.
So, having illustrated the fact that policy admin systems are not born equal, and having offered a couple of explanations, let’s get back to our central question: If these different PAS solutions have different functional footprints, what are the components that are common to all that define the essence of a PAS?
Let’s start with a catalog of the different functions that often are subsumed under the umbrella term of PAS. The following is a list of commonly referenced component functions you might expect to be part of a PAS. This list is not exhaustive and is the subject of some controversy:
• Rating: Clearly for a policy to have a price (premium) some kind of rating algorithm is required to create pricing based on a combination of risk facts, coverage choices, and rating variables. Rating is key to premium generation, but is rating an essential part of what we call a PAS? No. Given the number of stand-alone rating engines in the market and the number of more recently developed PAS solutions that do not include a rating function, it is clear rating is not a core component of a PAS.
• Product Definition: A PAS requires a repository of insurance product structural components—coverages, limits, deductibles, etc.—and rules that dictate the allowed relationships between these components as they are built into insurance products that vary across geographies and jurisdictions. Whether these components and rules are rendered in computer code and values (as is the case with legacy systems) or in data tables and rules (as tends to be the case with modern systems), this component function is central to the ability of every PAS to do its job. The product definition component is vital to the PAS.
• Policy Life Cycle: An insurance policy is subject to a (fairly) predictable set of life cycle events. These events, which we often refer to as transactions, are familiar and include quote, issue, endorse, cancel/reinstate/rewrite, renew/nonrenew, and (for certain types of commercial business and workers’ compensation) audit. Some of these transactions are event driven, such as endorsement and cancellation activity, and some are date driven, such as renewals. What they all have in common is they are the essential events that occur to policies, and the ability to support them is central to a PAS.
• Underwriting: Underwriting answers two questions about a risk: Does the carrier want to write the risk, and into which pricing tier does it fit (assuming the carrier has rate tiering)? Underwriting used to be based on a question/answer information gathering process but now relies extensively on electronic fact gathering and analysis, usually based on third-party data services. While the PAS may have some underwriting logic or rules built in and often is expected to store much of the resultant information, it usually is the domain of specialized underwriting and analytical engines to perform the fact gathering, analysis, and evaluation required to support automated underwriting.
• Workflow: Every PAS has an implied or explicit sequence of events it assumes in its processing flow. With modern PAS solutions, processing flows can be tailored for different lines of business and can be configured based on client preferred practices. However, this usually is a partial workflow solution and, like the underwriting solution, is more fully realized if the PAS is interfaced with a specialized third-party product.
• Print and Document Management: A PAS must be capable of generating all of the data and rules that are required to print a declarations page, an insuring agreement, and the various other documents and notices that are produced during the life cycle of an insurance policy. However, this does not mean the PAS should contain a print function, which like the underwriting and workflow functions, is a specialized capability that is best provided by a separate dedicated software product.
• Premium Accounting and Statistical Reporting: The generation and tracking of in-force and earned premiums and the reporting of various types of data to statistical bureaus in differing formats usually are accomplished by specialized “back-end” programs. These pieces of software, the oil sump of the administration engine and hidden from view, have virtually no meaningful operational interface and collect and aggregate data from systems (such as the PAS and claims) nearer the surface of the application architecture. These are the legacy systems that usually feed the majority of the data that data warehouses consume.
So, then, the irreducible core of a PAS is a product definition engine with a set of associated life cycle transactions. This is the narrow end of the PAS definition continuum. For reference, the broad end of the scale belongs to industry analyst Celent, which published PAS reviews that discuss whether or not the “PAS system” includes claims and billing functionality! The Celent usage of the term PAS equates to a complete core insurance administration system supporting all major business operations functions.
Let’s ask the “so what?” question: Does any of this matter? The point is not that a formal, agreed definition of a PAS is required so much as we simply recognize when different people use the term, they may mean significantly different things. This is especially important at the start of a PAS search when agreed definitions are required to minimize confusion and create an appropriate focus.
The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.