# BriteLines

A modeling engine for insurance products

# 1 - Summary

BriteLines allows insurers to model the fields, rates, rules, and forms associated with the insurance products. Lines may be inherited from templates, versioned by date, and versioned by jurisdiction.

# 2 - Core Entities

Lines utilize a relatively simple core data structures organized in the following manner

  • Lines
    • Risk Types
      • Fields
      • Tables
      • Calculations
      • Line Items
        • Forms

# 2.1 - Lines

A Line of Business describes the product or set of related products that make up a particular insurance offering. It describes a “type” of insurance. LOBs are the highest hierarchical entity in a Lines configuration.

# 2.1.1 - A few common Lines of Business

Examples

  • Homeowners - Personal
  • Private Passenger Auto - Personal
  • Farmowners - Personal
  • Standard Fire & EC - Personal
  • Long Haul Truckers - Commercial
  • Commercial Liability - Commercial
  • Cargo - Commercial
  • Cyber Liability - Commercial

Click here to view a complete listing of Lines of Business by state in the US.

# 2.1.2 - Multiple Lines of Business

Policies may contain risks that are covered by more than one Line of Business. BriteCore classic only allows a single Line of Business per policy. We will only support this single LOB designation in V1 of BriteLines, but once we replace BritePolicies, we will fix this to support multiple LOBs on a single policy.

Fun Fact

The term Lines of Business comes from the NAIC standard annual financial filing for insurance companies. The financial filing is a physical yellow book creatively called the “Yellow Book”. In the Yellow Book, important financial metrics such as Premium Written, Premium Earned, Losses Incurred, Expense Ratio, etc. are separated by type of insurance (ie. Wind, Fire, Liability, Auto, etc). Yellow Book. Each type of insurance is represented on a separate physical line on the yellow book which leads to the term Lines of Business. This term stuck around and now the term “Line of Business” generically means the “type” of insurance you are writing.

# 2.2 - Risk Types

A Risk Type models the Fields, Rate Tables, Calculations, and Line Items that follow a particular type of risk. Lines are parents of Risk Types.

Example

The Personal Auto LOB includes an Auto and Driver risk type as the coverges that follow both entities represent the total exposure on the policy. Individual risks are instances of risk types on policies.

# 2.3 - Fields

Fields describe facts about a risk. Available fields are determined by our client and utilized within Risk Groups. Risk Types are parents of Fields.

# 2.3.1 - Field Type

Fields type represents the fundamental data type of a field in the data model. For Example a VIN number on an auto is a String type

# 2.3.2 - Name

A reference used by the internal calculation engine

# 2.3.3 - Label

The Interface label utilized for visual presentation..

# 2.3.4 - Values

# 2.3.4.1 - Default Value

The Default Value is the value populated by the system prior to any user interaction. Default Values may be overridden based on access controls.

# 2.3.4.2 - Lookup Values

Lookup values are populated by remote data call. Sometimes lookups are performed manually via a user event such as a button click and other times lookups are performed automatically once all payload dependencies are available.

# 2.3.5 - Validation

Validation rules place restrictions on the data a field will accept as valid input. A Validation library is provided as a convenience to quickly establish validation parameters for common data elements. For Example a VIN number should be 17 characters and only contain Capital Letters and numbers.

# 2.4 - Tables

Tables contain rows that store indexed values. Indexes can be layered into a multi-index. Risk Types are parents of Tables. An index may be built:

  • Manually - Enter the index values through user entry.
  • Automatically - Built from one or many enum field options.
  • Imported - Copied and pasted from a tabular data format (.csv, .xls, etc.)

The table index can be nested as deeply as needed, but lookup always resolve to a single value. Users can assign a lookup name to a table for reference in future calculations.

# 2.5 - Calculations

Calculations support the evaluation of restricted Python statements. Risk Types are parents of Calculations. Python statement access a dictionary that stores the output value of every named entity within a line. Initially, we are supporting raw restricted Python in the interest of delivery timeline. In the future, we will build full features spreadsheet-style statements.

# 2.6 - Lines Items

Line Items represent a fundamental unit of insurance. Risk Types are parents of Line Items

# 2.6.1 - Types

Line Items are categorized as one of five types: Coverage, Adjustment, Non-Rate, Fee, Calculation.

# 2.6.1.1 - Coverage

A coverage insures an exposure against a peril.

Examples

  • Coverage A - Homeowners coverage that Insures the primary dwelling against a list of named perils.
  • Collision - Personal Auto coverage that insures property damaged during a collision.
# 2.6.1.2 - Adjustment

An adjustment modifies policy premium without offering additional coverage.

Examples

  • Auto Home Discount - Provides a reduction in overall premium if a policyholder purchases both and private passenger auto and a homeowners policy from the same carrier.
  • Credit Surcharge - Increases total premium to account for the increased risk of an insured with a poor credit rating.
# 2.6.1.3 - Non Rate

Modifies policy language or coverage in some way that has no impact on premium.

Examples

  • Roof Exclusion - Attaches a roof exclusion agreement to the policy to exclude losses from a roof that is in poor condition.
  • Mine Subsidence - Notice that sinkholes from previous mining operations are covered by the state government instead of the primary carrier.
# 2.6.1.4 - Fee

Calculates a monetary amount, but designates the amount to fees collected instead of premium collected.

Examples

  • NY State Fire Fee - NY State requires that all homes within a responding fire district collect a premium tax which is remitted to local fire departments.
  • Membership Fee - Membership Fee charged to farmers joining a farmer’s union coop in order to purchase a farm insurance policy.
# 2.6.1.5 - Calculation

Calculates a monetary amount purely for the sake of storing the number later in premium records.

Examples

  • Standard Fire & EC - Standard Fire policies insure a dwelling against two perils only… fire and wind. Though the policy holder and agent want to see a single Dwelling coverage, the premium is calculated separately for fire and wind. Later we must report on the portion of the premium that is fire and the portion of the premium that is wind as they flow to separate annual statement lines on the Yellow Book.
  • By Peril Rating - Many of our customers utilize By-Peril rating which calculates each of 7 named perils following a different calculation path. Later, we must report on the amount premium charged per peril on individual coverages.

# 2.6.2 - Declarations

Line Items may optionally print on the Declaration page of a policy. Generally the cover page of a dec will display a listing of Line Items on the policy with the corresponding limit, deductible, and premium amounts.

# 2.6.3 - BriteData

BriteData writes written, earned, and unearned records for every line item on every policy every day. This makes Line Items the fundamental unit of granularity for policy level financial reporting.

# 2.7 - Forms

Insurance Forms are legal agreements that specify the details on the policy contract between the carrier and the policyholder. Line Items are the parents of Forms. When a Line Item is added to a policy, the forms are also attached to the policy and displayed on the Declaration page.

# 2.7.1 - Source

Forms are provided by forms agencies such as ISO or AAIS though carriers can elect to author their own forms as well. All forms are rigorously reviewed and approved by the Regulator with jurisdiction over the policy.

# 2.7.2 - Form Number

Form numbers are industry standard identifiers for specific legal agreements attached to insurance policies. As with policy numbers, form numbers are fully alphanumeric with special characters. The Line of Business “HomeOwners Form 3” is called such because the policy is generally defined by a legal agreement defined by ISO with the Form Number “HO-3”. Form 3 describes coverage for specific exposures against a list of named perils within predefined limits with exclusions applied. By adopting the HO-3, a carrier eliminates the need to develop their own policy language and apply for approval in all 50 states. ISO has done the compliance and filing work for them.

# 2.7.3 - Import

We will eventually support automatic import of forms from ISO and AAIS at a minimum as both provide electronic versions of these documents along with the suggested rate factors that meet statutory requirements in the various jurisdictions.

# 2.7.4 - Association

Insurance forms literally legally define the coverages modeled in BriteLines. Each Form is associated with a Line Item. As such, Forms should be associated with Line Items directly in the Lines Module.

# 2.7.5 - BriteDocs

While the association between insurance products and a list of forms belongs in BriteLines, Forms are stored as documents. Templates should be stored in BriteDocs and generated from BriteDocs when a render or export is required.

# 2.7.6 - Versioning

Forms are subject to versions as regulations evolve for a particular regulatory environment. ISO and AAIS both maintain Form Versions which insurers may elect to adopt or reject. This is distinct from BriteDocs versioning which is designed to track the evolution of a unique document template. Form Versions should be tracked in BriteLines as each version represents a unique legal agreement, not an ongoing draft of the same agreement. Form versions are typically represented by a version number such combined with the Form Number. Ex “HO-3 v13.24.A

# 2.7.7 - Declaration

Forms are listed on the Declaration page for a policy. In most jurisdictions, relevant form numbers must be printed clearly on the first page of the declaration page for all coverages on that policy. This is a fully automated process through ReportLab in the current stock Dec page in the Deliverables section of BriteCore classic. We need to coordinate with the BriteDocs team about how to handle this in the new BriteDocs paradigm.

# 2.7.8 - Delivery

Forms must be delivered with Declaration pages anytime the declaration page is delivered to a listed party on the policy. Delivery may occur via print, email, text, integration, or API lookup.

Note that many companies save printing and mailing costs by purchasing these forms in bulk on onion skin paper. In some circumstances, the system won’t actually print the form, but will just need to output a note that someone should attach the form to the mailing packet from a bin of onion skin copies.

Delivery will occur via BriteDelivery and not BriteLines.

# 3 - Versions

Versions store pointers to different configurations of core data elements. Versions allows us to maintain a persistent model mapping for consumption by external services while updating pointers for effective date modifications and inherited entities.

# 3.1 - Core Data Elements

Generally, all core data elements will have the following properties associated with them:

# 3.1.1 - Static References

A relatively static reference to a data element is provided to stabilize schemas, data lookups, naming conventions, etc. This is critical as many external system depend on stable model definitions to function correctly. (Ex. distribution portals, comparative raters, agency upload)

Example

If a carrier wants to automate their personal auto policies, they will build automation tools around items such as VIN lookup, driver histories, bank notification, etc. it is critical that BriteLines contains a persistent mapping to the the core data elements that make up the private passenger auto LOB. By mapping to the persistence layer, integrations can remain stable across versions of the Personal Auto LOB.

# 3.1.2 - Versions

Versions of an element are active at a particular datetime. Insurance products are subject to ongoing changes over time for a variety of underwriting, strategic, marketing, and regulatory reasons. Version information is important for several reasons:

# 3.1.2.1 - User Experience

The user experience of creating a new version should be as inline as possible. Users should be able to navigate to a particular core data element and create a new version easily.

The most recent date of the active version should be easily discoverable as well. A history of previous versions should also be easily accessible.

# 3.1.2.2 - Reporting

An audit log of changes over time is critical in BriteData later. This is a critical omission from BriteCore Classic and something we can address relatively easily with a formal version table. We need to know exactly what elements and values changed for a particular LOB over time and produce a report that details this for auditors and actuaries.

# 3.1.2.3 - Datetimes

Currently BriteCore Classic versions everything by day. This limits LOB versions to one per day which is suitable for a regional P&C insurer. However, insurance is moving to a more usage based model with real-time rating. Under a real-time rating scenario, insurance rating could logically reversion rate tables or factors via a live data source at microsecond granularity much as stock prices do today. Versions should receive a datetime stamp allowing many versions to exist over the course of a single day.

# 4 - Rating

Rating calculates the premium and fees due on a policy. Rating is composed of several components:

# 4.1 - Rate Engine

Risk facts are passed to the rating engine and it returns calculated rates.

# 4.1.1 - API Payloads

All data elements submitted to the Rating API must be defined in the LOB model of BriteLines to return a valid rate. Payload values that fail to resolve must return a descriptive error message that allows an API developer to quickly locate key or value errors. If descriptive schema validation is too slow for every rating call, we should accept an optional parameter that enables or disables descriptive error messages for a given rating call.

# 4.1.2 - Parallel Rating

Rating across a large policy can resolve to hundreds of thousands of separate nodes in a dependency tree. Rating initially builds a dependency map, then resolves each dependency on a discrete compute engine. Compute engines can be any scalable parallelized service such as Lambda, Fargate Containers, EC2 ASG, etc as long as rating capacity scales automatically and smoothly outside of the web server.

# 4.1.3 - Rate

Quotes return rate objects that contain all granular and summary rating snapshots of a returned rate object. Each rating function stores a quote.

# 4.2 - Policy Preview

Policy Preview is an interface template that displays all required fields for a particular policy model. Users follow a predetermined workflow that dynamically loads dependencies and solicits input for all user-entered fields. As required data is entered, rates are calculated on the fly.

# 4.2.1 - Policy Group

The Policy Risk Type is instantiated once per policy regardless of the number of risks on the policy. Items in the Policy Risk Type describe data about the policy itself, not data about a specific risk on the policy. All fields and items associated with the Policy Group display under the policy group in the Policy Preview.

# 4.2.2 - Risk Types

Risks represent individual exposures that may be insured on a policy. Risks can be instantiated more than once on a policy though multiple instantiated may be limited by rules. All fields and items associated with the Risk are displayed in the Risk Type display under the individual Risk on the policy.

# 4.2.3 - Items

The association between a risk and the insurance that applies to that risk is captured in Line Items. All items associated with a Risk or Policy Group are displayed through a selection UX.

# 4.2.3.1 - Simple Item Selector

Risks with a small number of potential Line Items (Ex: Private Passenger Auto), will use the Simple Item Selector. In the Simple Item Selector, users are presented with a list that displays the limited number of Items that might apply to the Risk Type. Users select Items from the list to add those Items to the Policy Preview.

# 4.2.3.2 - Complex Item Selector

Risks with a larger number of potential Line Items (Ex. Commercial Property), will use the Complex Item Selector. In the Complex Item Selector, users are presented with a search interface that allows them to search for Items that might be apply to the Risk. Users then select Items from the search results to add those Items to the Policy Preview.

# 4.2.3.3 - Default Items

Default Items are automatically added the policy when the risk is added to the policy.

# 4.2.3.4 - Rules Integration

Many Items will be automatically added or removed from a policy based on Underwriting Rules. These are evaluated in Drools. Every user action or API call might serve as a trigger to fire a rule.

# 4.3 - API Rating

BriteLines Rating is consumed by external systems via API integration.

# 4.3.1 - Comparative Raters

Comparative Raters are vendors that aggregate data from Agencies and submit the same general policy facts to as many carriers as possible to determine the lowest possible rate for the end consumer. Limited data results in a preliminary rate. If the preliminary rate is favorable, the user expects to move forward with a more detailed and complete quote in a different interface such as BriteQuote.

# 4.3.2 - Distribution Portals

Many of our customers support consumer-facing or systems-integrated portals for distribution. These portals allow the Carrier or InsurTech to control the end user experience while utilizing BriteLines to deliver accurate rates. Most of these customers want to issue a completely bound policy without ever leaving their own interface.

# 4.3.3 - Third Party Systems

Moving forward, BriteLines will become an industry-leading rating engine utilized in very large insurance software ecosystems. It will frequently be utilized as a standalone modeling and rating engine without the rest of the BriteCore suite including BriteQuote or BritePolicies.

# 5 - Inheritance

# 5.1 - Purpose

Inheritance allows models to share common definition ancestors. This allows common data elements to be defined in an upstream template LOB, then utilized repeatedly through inheritance into specific LOBs that extend the base template. For example, I might have a Homeowners template that defines 80% of all HO business, but then inherit HO-Common into HO-2, HO-3, and HO-5, each of which introduces new item, rates, and rules.

# 5.2 - Usage

We cannot control or know what hierarchical inheritance structure a carrier will utilize. Many smaller mutuals will likely setup a national template for standard LOBs that contains common elements, then inherit into the specific packages to extend further, and finally inherit into state specific variations as the actual products they will write. e.g.

  • HO-Common
    • HO-2
      • HO-2-MO
      • HO-2-KS
      • HO-2-OK
    • HO-3
      • HO-3-MO
      • HO-3-KS
      • HO-3-OK
    • HO-5
      • HO-5-MO
      • HO-5-KS
      • HO-5-OK

However, this could be organized very differently than this and we should assume nothing with our inheritance hierarchy. Parents should just be arbitrary common ancestors.

# 5.3 - External Exposure

# 5.3.1 - Exposed Entities

We should only expose the tips of the inheritance tree to actual product offerings. If a model is used as a common ancestor it is not exposed to outside product definitions. We will create an API call something close to lines/retrieveAvailableLines. In the example above, we would expose the following list to an actual product configuration system through this API call:

Example

  • HO-2-MO
  • HO-2-KS
  • HO-2-OK
  • HO-3-MO
  • HO-3-KS
  • HO-3-OK
  • HO-5-MO
  • HO-5-KS
  • HO-5-OK

# 5.3.2 - Categories

We can solve a huge range of categorization and workflow issues down the road by supporting arbitrary categories for LOBs. When returning the list of available LOBs, we should return all the categories associated with each LOB so business rules and presentation grouping can be applied by the front end system. Using the example above, a carrier would likely create a category for Line of Business, Form, and State. If they populated those with appropriate list values during LOB setup, we can return something like this mocked payload in the lines/retrieveAvailableLines API call. e.g.

Available_Lines: [
{
  `name`: “HO-2-KS”
  ‘Line’: “Homeowners”,
  ‘State’: “KS”
  ‘Form’: 2
},
{
  `name`: “HO-2-MO”
  ‘Line’: “Homeowners”,
  ‘State’: “MO”
  ‘Form’: 2
},
{
  `name`: “HO-2-OK”
  ‘Line’: “Homeowners”,
  ‘State’: “OK”
  ‘Form’: 2
},
{
  `name`: “HO-3-KS”
  ‘Line’: “Homeowners”,
  ‘State’: “KS”
  ‘Form’: 3
},
{
  `name`: “HO-3-MO”
  ‘Line’: “Homeowners”,
  ‘State’: “MO”
  ‘Form’: 3
}
..etc, etc, etc
]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 5.4 - Organization

We need a clear way to keep track of which LOBs are used as superclass templates and which are endpoints exposed for public consumption. The Design team can solve this problem however they see fit, but we will need to clearly and succinctly be able to identify the following:

# 5.4.1 - Template v Production LOBs

We need a clear delineation between which LOBs are templates versus production LOBs. Production LOBs must be at the tip of the inheritance tree. These could be labels, groups, separate lists, separate pages, whatever control makes sense as long as the contrast is obvious and easy to navigate.

# 5.4.2 - Inherited Elements

Any LOB that has inherited from another LOB has a variety of data elements that are defined in the parent, not in the local definition. Fields that are inherited should be uneditable within the inherited template with clear indicators that any edits would need to be made on the parent template.

# 5.4.3 - Children

Any LOB that is used as a template for another LOB should clearly show which LOBs spawn from it. Any change to a data element in a template should raise a warning that the change will update throughout the template structure.

We should also include a way to defeat this warning message for an experienced user so the process of updating templates on purpose isn’t incredibly tedious as the user clicks “Yes I understand” 4 million times.

# 6 - Secondary Data Elements

# 6.1 - Regulators

Insurance is a heavily regulated industry. Insurance products fall under the jurisdiction of various regulators who determine the legality of insurance forms, rates, and practices for that insurance product.

# 6.1.1 - Locations

Each state in the US houses an independent department of insurance. Each department is an independent regulator that governs insurance practices in that state. As such, Lines of Business are generally versioned “by state” in the US. However, insurance is not always regulated geographically on the global stage or even in the US as some products may be regulated by a national insurance office.

# 6.1.2 - Lines of Business

Generally, each regulatory authority will impose a unique statutory framework which will require unique product models within that jurisdiction. For example Massachusetts Personal Auto (Mass Auto) is very different from other Private Passenger Auto in other states. This would be defined as a unique Line of Business.

Example

Some insurance departments in the US allow Homeowners policies to include credit score as a rate factor while others do not. Generally insurers want to utilize credit scoring in actuarial modeling as credit score is a strong predictor of anticipated claims behavior. Most insurers will maintain separate HO models for states that do allow credit scoring and states that do not.

# 6.2 - Business Locations

Business Locations define geographic boundaries for risk locations. They are not core to insurance in general, but are used heavily in the US for location-based insurance products as facts in business rules triggers.

# 6.2.1 - Usage

Business locations are used in at least the following three ways by Lines.

# 6.2.1.1 - State Departments in the US

In the US, each state is governed by an independent Department of Insurance which servers as the regulator in that state. As such, domestic insurance has a 1:1 relationship between States and Regulators. However this is not true in many other parts of the world. We will need to track business locations for LOBs that are offered on a geographical basis, but this is ultimately a business rule and not a core data element.

# 6.2.1.2 - Authority

Location is used to trigger authority for insurance agents. US Agents are generally authorized to write new business in certain business locations only. Tracking all possible business locations allows us to build authority layers later that can determine if an agent is authorized to write in a specific location.

Example

Great agents filter out poor risks in the interest of long term loss ratio performance. Poor agents write substandard business to grow premium and commission. A carrier might allow a High-quality agent to bind business in East Saint Louis, but restrict binding authority for a low-quality agent to only saint louis county excluding the high-risk East Saint Louis area.

# 6.2.1.3 - Suspensions

Carriers can suspend new business quotes for a period of time based on geographic location. These suspensions may be broad across all distribution channels, or limited to a specific business location or agency class.

Example

When an impending hurricane is nearing the coast, carriers do not want to write new business in the path of the hurricane as no premium has been collected yet to offset the scope of anticipated losses.

# 6.3.2 - Implementation Details

Business locations are used in at least the following three ways by Lines.

# 6.3.2.1 - Granularity

Business Locations may defined by the nation, province/state, county, postal code, and arbitrary subdivisions of counties or postal codes. (Ex. Saint Louis city vs. Saint Louis Rural). Subdivisions are a manually managed list that subdivide otherwise standardized geographic classifications such as county and zip code.

# 6.3.2.2 - BriteCore Classic

In BriteCore Classic, Business Locations were used to determine which Lines of Business could be offered to the policy holder and which Regulator had jurisdiction. This design was very limited and only works well for location-based property risks as other forms of coverage such as liability are not restricted to geographic location, and regulators may span geographies outside of the US.

# 6.3.2.3 - BriteLines Implementation

We should maps business locations for companies that utilize them. These will be utilized by BriteRules later, but should in no way be core to our Lines modeling as they are used to trigger business rules.

# 7 - Rules

A significant number of underwriting and processing rules can apply to Line Items on a Policy.

# 7.1 - Inline BriteRules Editor

Most if not all of these Rules will be evaluated using BriteRules. HOWEVER, we should provide a convenience view into the editing of these rules along with helpful templates to reduce the friction of building these professing rules. The UX Team should be heavily involved in the design of this interface.

# 7.2 - BriteCore Classic Locations

In BriteCore Classic, these can be found in the following locations:

Lines  > Effective Date > Policy Type > Edit Line Item > Setup Tab
Lines > Effective Date > Policy Type > Edit Line Item > Rating Tab > Limit Link
Lines > Effective Date > Policy Type > Edit Line Item > Rating Tab > Minimum Premium Link
Lines > Effective Date > Policy Type > Edit Line Item > Rating Tab > Maximum Premium Link
Lines > Effective Date > Rules > Underwriting Rules
1
2
3
4
5

# 7.3 - Rules in the BriteCore Classic Interface

Initial underwriting rules enforcements should match the standard set up of underwriting rules available in the BriteCore Classic locations listed above. Examples.

# 8 - Vendors

Vendors are external services that perform return a data lookup or perform a workload outside of the main system.

# 8.1 - Implementation Details

# 8.1.1 - Registration

Vendors are managed through a central registrar that determines which external services are supported in a specific client deployment support.

# 8.1.2 - API Normalization

Vendors that perform a common function should be abstracted through a common API that normalizes input and output to the rest of BriteCore.

# 8.1.3 - Repos

Code for vendors lives in a separate repos from lines.

# 8.2 - Triggers

There are multiple ways a vendor could be triggered

# 8.2.1 - DOM Event

These originate from a standard onEvent DOM event such as onClick, onBlur, onKeyup, etc. These will need to be assignable from configurable UI components during the preview and quoting process.

# 8.2.2 - Dependency Fulfilled

Some vendor calls should happen the moment all dependencies are fulfilled. These callouts happen automatically as soon as we have collected all required data to submit the appropriate payload.

# 8.2.3 - Service to Service

These vendor lookups are performed as a component of another integrated function. A notable example here is a factor returned during a rating function call.

# 8.3 - Responses

Vendor calls return actionable data to the calling BriteLines services. The vendor definition and code should also understand what to do with the response data. As with BriteRule executions, these could return data inline to via a synchronous call that is handled directly within BriteLines, or through an API call back into BriteLines a synchronously.

# 9 - Policies

Policy Preview stages a list of policy facts and returns a rate given those facts. Those facts are the principle data stored on a policy.

# 9.1 - Revisions

Policies are organized as sequences of revisions in BriteCore. The facts and rates generated from the Policy Preview screen are stored as a revision in BriteCore Policies. Revisions are “committed” in the policy system, which sets the revision to an active status and applies all subsequent processing. Any new endorsement on the policy should send the policy fact object back to BriteLines. BriteLines then returns a rate object with all rates calculated.

# 9.2 - Declarations

Every change to a policy necessitates the generation of a new Declarations page. In BriteCore, a Dec is generated for every revision. We need make sure this process continues to function correctly.

# 9.3 - Revision Events

Revisions are generated for a range of reasons. In every event, the policy object must be passed back to the rating engine in BriteLines and a new rate object must be returned for storage with the revision. These events include:

# 9.3.1 - Quote / Application

The first revision on a policy is typically the initial quote / application revision. Currently BriteCore doesn’t support multiple overlapping quote versions for agents, though it does allow multiple overlapping quote revisions for underwriters. We will expand this functionality in the new BriteQuote.

# 9.3.2 - Initial Revision

The initial Revision on a policy is the first bound revision. Revisions are always re-rated prior to commit just to make sure rates are current. Rating is legally binding, so it is critical that we always display correct rates for a given set of policy facts. These revisions will require a round trip to rating.

# 9.3.3 - Endorsements

Endorsements are mid-term modifications to a policy. These frequently modify the rate which then requires another round trip to rating.

# 9.3.3.1 - Pro Rata Rates

Critical in Endorsement rating is calculating the pro-rata rates for the risk. Pro Rata rates take into account the term-rating entered in BriteLines, and then calculates the actual time the modification will be active on the policy and calculates the offset. We have well-established calculations in BriteCore for Pro-Rata logic.

Example Policy

Policy Term: 01/01/2018 - 12/31/2018
Term Length: 365 Days

REVISION 1
------------------

Revision Effective Date: 01/01/2018
Term Premium: $730
Pro-Rata Premium: $730
Schedule:
  - Line Item A
      > Term Premium: $365
      > Effective Date: 01/01/2018 - 12-31-2018
      > Pro-Rata Length: 365 Days
      > Pro-Rata Premium: $365
  - Line Item B
      > Term Premium: $365
      > Effective Date: 01/01/2018 - 12-31-2018
      > Pro-Rata Length: 365 Days
      > Pro-Rata Premium: $365


REVISION 2
------------------

Revision Effective Date: 07/01/2018
Term Premium: $1,095
Pro-Rata Premium: $913
Schedule:
  - Line Item A
      > Term Premium: $365
      > Effective Date: 01/01/2018 - 12-31-2018
      > Pro-Rata Length: 365 Days
      > Pro-Rata Premium: $365
  - Line Item B
      > Term Premium: $365
      > Effective Date: 01/01/2018 - 12-31-2018
      > Pro-Rata Length: 365 Days
      > Pro-Rata Premium: $365
  - Line Item C
      > Term Premium: $365
      > Effective Date: 07/01/2018 - 12-31-2018
      > Pro-Rata Length: 183 Days
      > Pro-Rata Premium: $183
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# 9.3.3.2 - Fully Earned

Many line items are triggered as Fully Earned Line items which means the entire term premium for that item is earned the moment the policy is issued. Pro-Rata premium equals term premium regardless of the effective date of the line item.

# 9.3.3.3 - Earned Units and Granularity

Pro-Rata premium in BriteCore Classic currently calculates on a day-by-day basis. As we move to more real time and usage based rating, we need to create a setting for each LOB for what Earned Unit we should utilize. We also need to understand how many of the units apply to the policy term. Premium could be earned per day as it is currently, or per other time unit such as hour, minute, or second. Premium could also be earned by a non temporal unit such as per event, per widget, or per mile. This is extremely complex and we should punt on implementing it fully for now. However, we should build in the fundamental support for unit type so we have a stub to support this in the future.

# 9.3.3.4 - Renewals

BriteCore automatically renews policies upon expiration of the current term if the policy is set to a renewal status of Auto-Renew. Renewal timing and logic is established in Policy settings and typically triggers renewals 30-60 days ahead of the expiration date of the current term. When the renewal is processed, a new revision is created that increments the policy term to a range that begins at the renewal date and extends the length of the policy term. Upon renewal, BriteLines must re-rate the policy using the newest Effective Dates on or before the renewal date.

This commonly modifies the policy facts in a several ways. For example, new mandatory coverages and endorsements are added to the policy. All age based rating factors increment by a year or a term. Line Items may age out as the risk becomes too old to qualify for discounts based on new property. Risk based scoring must be updated including credit scoring and loss history scoring. Many other factors may also apply and are determined by a combination of rating factors and underwriting rules.

BriteLines should return an updated rate object to the Policies system allowing Policies to bind and issue the renewal revision.

# Helpful Resources