Rethinking Life, Annuity and Benefits PAS Systems Part 3

Now that we've defined the high-level purpose of the Product Engine and discussed the role of AI in core platforms, it's time to focus on the System of Record (SoR).

Eric Weisburg, a Senior Principal at Datos Insights concept of a "skinny admin system" which primarily focuses on separating the underwriting workbench from the Policy Administration System (PAS) is a logical first step. However, to truly modernize, we must go further. The goal is to define which capabilities are intrinsic to the SoR and which should be carved out into separate, modular components.

Why Deconstruct the Policy Administration System (PAS)?

Modularizing capabilities previously bundled in monolithic legacy PAS systems offers significant advantages: reduced complexity in development and maintenance, and greater flexibility to adapt to changing business and system ecosystems.

While a solution provider can still deliver an end-to-end platform, an architectural approach that separates core components acknowledges that the PAS may not be the sole core system and that integration into larger enterprise processes is often necessary.

The most critical part of this exercise is determining what must reside within the SoR versus what is better positioned externally. either in systems you build or in third-party solutions. This decision hinges on your business model: do you aim to land and expand revenue by owning as much of the core lifecycle as possible, or do you seek to become the predominant solution in a specific market while accepting integration with other components?

A prime example is the Benefits space. Long-tail claims like Short-Term Disability (STD) and Long-Term Disability (LTD) are frequently handled on separate, specialized systems or outsourced entirely to a Third-Party Administrator (TPA) because their capabilities differ significantly from Individual Life claims modules often included with PAS systems.

The Hierarchy of Product and Policy

For those building a distributed PAS, it's vital to understand the relationship between insurance products and policies and why they don’t necessarily live in the same module.

Products are the insurer's templates for the approved market offerings which should logically reside in the Product Engine. Products are templates and are never executed legal contracts.

Policies are the actual contracts with specific terms that the insured signs and which are managed daily. Policies are legal contracts and should live in the System of Record, separate from but closely linked to the Product Engine.

This distinction is key to defining the responsibilities of each component.

What Capabilities Are Intrinsic to the System of Record?

The System of Record's core purpose is to maintain and service the policy itself. The SoR's essential capabilities include:

Policy Maintenance: Maintaining the actual policy instance (individual or group plan) and all individual certificates.

Lifecycle Transaction Support: Providing the transactions necessary to service the policy lifecycle, contract provisions, regulatory requirements, and customer requests. Note: These are the complex internal processes that support an API-first approach, not human-facing workflow or business process orchestration.

Expert Administration Support: An embedded UI to support the expert policy service team and all system security and configuration functions. Customer service, self-service, and distribution management are supported by integrated CRM and other user experience platforms.

Internal Accounting: Supporting the recordkeeping required to manage transactions, including summarizing details for posting to the general ledger.

Reporting: Reporting on policy status, transaction history, and internal accounting.

Data Availability: Making policy-level information available to other systems in the core lifecycle as needed, primarily through APIs.

Capabilities Best Positioned Externally

Monolithic legacy core systems historically bundled numerous other functions. PAS vendors must decide which of these capabilities they will build, connect to, or partner for, based on their business model. Best practice dictates that these components should be connected to, not embedded in, the SoR.

Legacy PAS capabilities that are prime candidates for separation include:

• Underwriting

• Quoting/Sales Illustration

• Billing and Commissions

• Claims Management

• Payment Processing

• Document Management (CCM)

• Customer Service/Call Center Support

• Customer and Agent/Broker Portals

• Data Analytics of all types
  

Moving Forward

Defining what belongs in the SoR, the Product Engine, and external systems requires an ecosystem approach to system design. Done right, this deconstruction will enable digital transformation at a whole new level.

Next Time: Insurance process and workflow in the age of Agentic AI