Prepare Your Insurance Data Model Part 4: Policy | Coverage | Risks

pankaj_bazaari · 5 hours ago

Prepare Your Insurance Data Model: Policy | Coverage | Risk

Objective

This article is part of the Prepare Your Insurance Data Model series. It covers the policy and what it protects: the Policy, the Coverage that applies under it, and the Risk being protected. It explains how FSO represents each concept, which tables sit behind them, and the decisions to make before you configure. It is written for implementers, solution consultants, and partners designing an insurance data model. If you’re new to the series, start with Part 1: Overview for the full map of the building blocks. If you already know the model, go straight to the configuration decisions your policy, coverage, and risk design needs to answer.

The Policy

The Policy concept answers the question: what does the customer actually hold? A policy is the customer-specific instance issued from a product definition. It contains coverages, protects specific risks, and has participants with defined authority. Servicing and claims work are performed against the policy and its related context.

Figure 4. The Policy in the Insurance Data Model

Figure 4 places Policy at the center, connecting policyholder, coverage, risk, authority, and work into one servicing context.

What the Policy Concept Represents

The policy is the operational anchor for servicing. It is where the abstract offering becomes a contractual customer-specific record. Most servicing and claims questions eventually need policy context: who owns the policy, what coverage applies, which risk is protected, who has authority, and what work is being requested.

A Personal Auto policy connects an individual policyholder, a vehicle, liability coverage, collision coverage, drivers, and service or claim activity.
A Commercial Property policy connects a business account, broker, covered locations, property coverage, certificate requests, and property claims.
A Group Life policy connects an employer group, employees, dependents, beneficiaries, coverage amounts, and benefit-related servicing work.

Policy context in the visual	What it represents
Policyholder Context	Consumer, Account, Contact, or Household connected to the policy.
Product / Offering Context	The product definition from which the policy was created.
Coverage Context	One or more coverages included in the policy.
Risk Context	The vehicle, dwelling, building, employee, or other object protected by coverage.
Authority Context	Participants with authority, such as named insured, beneficiary, producer of record, or authorized representative.
Work Context	Policy servicing and claims activity, such as endorsements, COI requests, FNOL, investigation, reserves, and payments.

How Policy Is Configured in FSO

FSO Core Insurance provides a parent Insurance Policy table and line-of-business policy tables. The policy configuration should capture the right line-of-business table, related coverage, related insured property or risk, and participant / authority structure.

Configuration bucket	Table examples	How to use it
Core Policy Table	sn_bom_ins_policy	Parent table for insurance policy records across lines of business.
Line of Business Policy Tables	• sn_bom_auto_ins_policy • sn_bom_homeowner_ins_policy • sn_bom_cp_ins_policy • sn_bom_ca_ins_policy • sn_bom_group_life_ins_policy • sn_bom_indiv_life_policy	Use the most specific policy table available for the line of business.
Policy Coverage	sn_bom_policy_coverage	Use to connect the policy to the coverages carried under the policy.
Insured Property / Risk	sn_bom_insured_property	Use to connect the policy to the property or object being protected.
Policy Participant	sn_bom_policy_participant	Use to represent parties connected to the policy and their roles or authority patterns.

Insurance Policy Tables

Policy table	Table name	How to use it
Insurance Policy	sn_bom_ins_policy	Use as the common parent / anchor for insurance policy records.
Personal Auto Policy	sn_bom_auto_ins_policy	Use for personal auto policies.
Homeowner Policy	sn_bom_homeowner_ins_policy	Use for homeowner policies.
Commercial Auto Policy	sn_bom_ca_ins_policy	Use for commercial auto policies.
Commercial Property Policy	sn_bom_cp_ins_policy	Use for commercial property policies.
Group Life Insurance Policy	sn_bom_group_life_ins_policy	Use for employer-sponsored group life policies.
Individual Life Policy	sn_bom_indiv_life_policy	Use for individual life policies.

Policy Decisions Before Moving to Coverage and Risk

Decision	Why it matters
Which policy tables are in scope by line of business?	Determines which policy classes and fields need to be configured or extended.
Is FSO the policy system of record or a servicing context layer?	Determines whether policy data is stored locally, synchronized, looked up, or accessed remotely.
Does Producer of Record belong at customer, policy, coverage, or risk level?	Prevents visibility and routing mistakes when producer authority varies across policies or lines.
Which policy participants must be represented?	Sets up the authority model for named insured, beneficiary, additional insured, loss payee, drivers, and other participants.
Which servicing and claims work must reference the policy?	Ensures Policy Servicing and Claims Operations have the context needed for triage, routing, and resolution.

Key Takeaways

Policy is the sold or issued instance for a customer.
Policy becomes the anchor because it connects people, an offering, coverages, risks, authority, and work.
Use the most specific line-of-business policy table available, while keeping shared logic at the parent Insurance Policy level where appropriate.
Policy decisions should be made before configuring coverage, risk, policy participants, and work patterns.

Policy is the anchor. Coverage and Risk explain what protection applies and what it protects.

The Coverage

The Coverage concept answers the question: what protection applies under the policy? A policy can include multiple coverages, and each coverage can apply to one or more risks. Coverage is the bridge between the customer-specific policy and the risk being protected.

Figure 5. The Coverage in the Insurance Data Model

Figure 5 highlights Coverage: how it connects to policy, product / offering, risk, and authority.

What the Coverage Concept Represents

Coverage defines the specific protection included under a policy. It is not the same as the policy itself. The policy is the sold instance; coverage describes the protections, options, limits, deductibles, dates, and pricing that apply within that policy context.

An auto policy may include liability, collision, comprehensive, uninsured motorist, or medical payments coverage.
A homeowners policy may include dwelling, personal property, personal liability, or additional living expense coverage.
A commercial property policy may include property damage, business interruption, equipment breakdown, or scheduled location coverage.
A life policy may include life benefit, rider, waiver, or other coverage options depending on the product and policy design.

Coverage context in the visual	What it represents
Policy Context	Coverage exists within a policy and defines the type of protection included under that policy.
Product / Offering Context	Coverage is made available by the product model or offering and may include coverage types, options, default limits, and pricing rules.
Risk Context	Coverage applies to one or more risks, such as a vehicle, dwelling, location, person, building, or other insurable asset.
Authority Context	Authority determines who can view, manage, change, endorse, or use the coverage in servicing and claims.
Work Context	Coverage drives servicing outcomes, eligibility, limits, payments, claim handling, and settlement decisions.

How Coverage Is Configured in FSO

The bottom strip in Figure 5 shows the coverage configuration flow. Start with coverage types, define options and parameters, map them to the product model, include them on the issued policy, manage policy changes over time, and use the coverage context in servicing and claims.

Configuration step	What to configure	Why it matters
Define Coverage Types	Create coverage types that represent the protection offered.	Establishes the reusable coverage categories available to products and policies.
Define Options	Define limits, deductibles, sublimits, parameters, and options for each coverage type.	Captures the choices and boundaries that shape policy coverage.
Map to Product Model	Associate coverage types and options to product models for availability.	Prevents coverage from being configured ad hoc only at policy level.
Include on Policy	Select and include coverages when the policy is quoted or issued.	Connects the policy to its actual protection set.
Manage on Policy	Update, add, remove, or endorse coverages over the policy lifecycle.	Supports policy servicing and change workflows.
Use in Servicing and Claims	Use coverages to drive eligibility, limits, payments, and claim settlement.	Provides the context needed for servicing and claims decisions.

Coverage Tables

Coverage configuration should be validated against the target release and installed plugins, using the FSO Core Insurance Tables reference linked below. Policy Coverage, Coverage Type, and Coverage Type Option are confirmed anchor tables; the remaining rows are not shipped out of the box and are marked as candidates for a custom extension in your own application scope.

Configuration bucket	Table examples	How to use it
Policy Coverage	sn_bom_policy_coverage	Use to represent the actual coverage carried on a specific policy.
Coverage Type	sn_bom_coverage_type	Use to represent reusable coverage types such as liability, collision, dwelling, or life benefit.
Product Coverage Type	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if you need coverage types tied directly to product availability.
Coverage Type Option	sn_bom_coverage_type_option	Use for coverage options, limits, deductibles, sublimits, and parameters.
Coverage Option Pricing	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if coverage option pricing needs to be configured or referenced directly.
Policy Coverage Document	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if documents or supporting evidence must be associated directly with policy coverage.

Coverage Decisions Before Moving to Risk

Decision	Why it matters
Which coverage types are available for each product / offering?	Determines what can be selected or included on policies.
Which options, limits, deductibles, and sublimits apply?	Determines how coverage should be interpreted during servicing and claims.
Does coverage apply to the policy broadly or to specific risks?	Determines whether coverage needs to be associated with vehicles, dwellings, locations, people, or other insured objects.
Who can change, endorse, or use the coverage?	Connects coverage to authority and participant patterns.
Which service requests and claims depend on coverage?	Connects coverage to work, eligibility, payment, and settlement decisions.

Key Takeaways

Coverage defines the protection provided under a policy.
A policy can include multiple coverages, and each coverage can protect one or more risks.
Coverage should be connected to Product / Offering before it is selected on a policy.
Coverage context is essential for policy servicing, claims eligibility, limits, payments, and settlement decisions.

Coverage explains the protection. Risk explains what that protection applies to.

The Risk

The Risk concept answers the question: what is being protected? Risk represents the asset, person, liability, financial exposure, or other insurable interest that is covered by the policy through one or more coverages. If coverage describes the protection, risk describes the object or exposure the protection applies to.

Figure 6 highlights Risk: what it is, its attributes, who is connected to it, and how it relates to the other concepts.

What the Risk Concept Represents

Risk is the thing, person, liability, exposure, or interest that the insurer is protecting. In FSO, risk should be represented clearly enough for servicing and claims teams to understand what is covered, which coverage applies, who is connected to the risk, and what work can be performed against it.

For Personal Auto, the risk may be the insured vehicle and relevant drivers or usage context.
For Homeowners, the risk may be the dwelling, personal property, detached structures, or personal liability exposure.
For Commercial Property, the risk may be buildings, locations, equipment, contents, or scheduled property.
For Group Life, the risk may be covered employees, dependents, or other people-related coverage context.
For liability-focused products, the risk may be operations, premises, professional exposure, or other liability context.

Risk concept	What it means
What Is Risk?	Assets, people, liabilities, financial exposures, or other insurable interests that are protected.
Risk Attributes	Type, classification, location, characteristics, specifications, values, deductibles, and limits.
Risk Ownership and Connection	Who owns, benefits from, is associated with, or has an interest in the risk.
Why Risk Matters	Risk determines pricing, underwriting, coverage applicability, servicing actions, and claims evaluation.
Examples	Vehicle, dwelling, building, equipment, employee, liability exposure, operation, or location.

How Risk Relates to Other Concepts

Concept	Risk relationship
Policyholder / Account	The customer owns, uses, benefits from, or is responsible for the risk.
Product / Offering	The product defines which risk types it can cover.
Policy	The policy includes risk information and ties it to coverage and authority.
Coverage	Coverage specifies which risks are covered and how.
Authority	Authority determines who can act regarding the risk.
Work	Servicing and claims work can be performed against the risk.

How Risk Is Configured in FSO

The Risk section should clearly distinguish risk records from coverage records. Coverage defines the protection; risk defines what is being protected. Insured Property is confirmed against the FSO Core Insurance Tables reference; the remaining risk-related rows below are not shipped out of the box and are marked as candidates for a custom extension in your own application scope.

Configuration bucket	Table examples	How to use it
Customer Property	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if a generic customer property or risk-related item needs its own record.
Insured Property	sn_bom_insured_property	Use to represent properties covered by an insurance policy.
Vehicle	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if vehicle-specific risk details need their own dedicated record.
Location	Not shipped OOB: custom extension	Plan as a custom extension in your own application scope if physical location or premises information needs its own dedicated record.
Person / Covered Person	Person or participant pattern	Use for people-related risks such as employee, dependent, or life coverage context.
Risk-to-Policy / Risk-to-Coverage Association	Implementation-specific association pattern	Use where risk must be associated to a specific policy and coverage. Validate exact table design in target release.

Risk Decisions Before Moving to Work

Decision	Why it matters
Which risk types are in scope?	Determines whether the implementation needs vehicles, buildings, locations, people, liability exposures, or other risk objects.
What attributes must be captured for each risk type?	Supports underwriting, servicing, coverage applicability, and claims evaluation.
Does one coverage protect one risk or multiple risks?	Determines how coverage and risk records should be associated.
Who owns, uses, benefits from, or has authority over the risk?	Connects risk to policyholders, participants, producers, and authority patterns.
Which work depends on risk details?	Ensures claims, endorsements, inspections, and service requests have the right context.

Key Takeaways

Risk is what is being protected; Coverage is the protection that applies to it.
A policy can cover one or more risks, and one risk may have one or more applicable coverages.
Risk records should capture enough detail to support servicing, claims, underwriting context, and reporting.
Risk should be connected to Policy, Coverage, Authority, and Work so the implementation can scale across lines of business.

Risk defines what’s protected. Work is where all of it (people, policy, coverage, and risk) turns into servicing and claims activity.

Note: Table names should be validated against the target release, installed plugins, and implementation scope before configuration.

What’s Next

Related articles:

Reference documentation:

Get Involved:

FSO Community Forum

Comment below with questions, or share how your insurance data model is coming together.