Hobbit Insurance Data Model Case Study

Hobbit Insurance
Insurance for the Little Guy
Implementation
of
Data Model
ACORD CORPORATION
ALL RIGHTS RESERVED
2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 0

Table of Contents
1 Introduction .......................................................................................................................................... 3
1.1 A Case Study: HOBBIT INSURANCE ............................................................................................... 3
1.2 Informal System Description ......................................................................................................... 5
2 Approach ............................................................................................................................................... 7
2.1 Technical Concepts ....................................................................................................................... 9
2.2 Mapping Concepts (Enterprise to Application) ........................................................................... 14
3 Develop Enterprise Data Model .......................................................................................................... 15
3.1.1 Enterprise Data Model ........................................................................................................ 18
4 Develop Business Area Data Modeling ............................................................................................... 22
4.1 Business Area Data Models......................................................................................................... 22
4.2 Party Model................................................................................................................................. 22
4.2.1 Party Model Design Choices............................................................................................... 23
4.2.2 Party Model Entity Description .......................................................................................... 25
4.2.3 Party Model Relationships .................................................................................................. 26
4.3 Product Specification .................................................................................................................. 28
4.3.1 Product Specification Model Design Choices..................................................................... 29
4.3.2 Product Specification Model Entity Description ................................................................ 32
4.3.3 Product Specification Relationships ................................................................................... 33
4.4 Policy ........................................................................................................................................... 34
4.4.1 Policy Model Design Choices ............................................................................................. 36
4.4.2 Policy Model Entity Description......................................................................................... 39
4.4.3 Policy Model Relationships ................................................................................................ 41
4.5 Claims Model .............................................................................................................................. 44
4.5.1 Claim Model Design Choices ............................................................................................. 46
4.5.2 Claim Model Entity Description ......................................................................................... 49
4.5.3 Claim Model Relationships ................................................................................................. 51
4.6 Finance Model............................................................................................................................. 53
4.6.1 Finance Model Design Choices .......................................................................................... 55
4.6.2 Finance Model Entity Description ...................................................................................... 59
4.6.3 Finance Model Relationships .............................................................................................. 60
4.7 Reinsurance Model ..................................................................................................................... 61

4.7.1 Reinsurance Model Design Choices ................................................................................... 63
4.7.2 Reinsurance Model Entity Description ............................................................................... 65
4.7.3 Reinsurance Model Relationships ....................................................................................... 66
5 Data Definition Language (DDL) Script................................................................................................ 67
6 Conclusion ........................................................................................................................................... 68

1 Introduction
The ACORD Data Model, one of the seven facets of the ACORD Reference Architecture,
represents a comprehensive picture of all the major data entities that a carrier must
represent in its systems, regardless of domain (Property & Casualty, Life & Annuity, or
Reinsurance) or geographical scope.
The ACORD Data Model is a logical data model, not necessarily designed to be
implemented directly as a physical data model. In the course of using the ACORD Data
Model, data architects from insurance companies will have to make judgments on
whether and how to make certain denormalization decisions in order to best
accommodate their enterprise’s needs.
In addition, the ACORD Data Model has some data entities that are common across all
insurance lines of business (e.g., Agreement or Party), but also has some specific data
entities that may only be applicable to Life carriers or to Property & Casualty carriers.
Furthermore, the actual physical design of an insurance data model may differ depending
on how it is used. An architect may make different decisions if the data model is used for
a transactional system vs. an operational data store vs. a data warehouse.
This document is designed to provide a case study in which we will use the ACORD Data
Model to provide a suggested implementation for the staging of transactional data from
multiple disparate systems of a fictional insurer into an enterprise standard physical data
model.
The ACORD Data Model provides best practices developed with input from its member
and partner organizations. However, every organization must determine their own
approach to meet their needs and requirements. This document will provide guidance
and suggestions for assisting implementers in this process.
1.1 A Case Study: HOBBIT INSURANCE
Hobbit Insurance is a 50-year-old midsize carrier serving primarily the Eastern US with a
subsidiary in Quebec and the Atlantic Provinces of Canada. It was originally founded as a
Personal Lines company, but now it also serves Property & Casualty needs for small to
midsize businesses – some “standard” products (BOP, Commercial Auto), as well as some
specialized lines of business (various E&O/Professional Liability lines, Kidnap & Ransom).
Because of several mergers in the past 20 years, Hobbit has at least two of every type of
insurance system (e.g., Policy Admin, Claims, Billing), and several smaller processes that
are maintained in complex spreadsheets or Access databases. The IT initiative that the

Hobbit data modelers are working on is preparation for building Hobbit’s first-generation
data warehouse. This requires them to build an operational data store where they can
define policies and claims in a single way in order to aid reporting.
Hobbit Insurance would like to have a system that provides the ability to have a customer
focused view of all its insurance data throughout the organization. This system should
facilitate business metrics around c policy administration, underwriting, claims, billing,
and all customer engagements. Currently, analyzing metrics is a cumbersome process
done in Excel since there is no one single source for the information. Management has
just approved the project to create the first-generation Data Warehouse for the Hobbit
Insurance Company.
Hobbit’s CEO, Dr. Peregrine Took, has stated that he

wants to make this investment on this project so that he and his management team can
quickly get information that crosses all the business units that are part of Hobbit. In
particular, he wants to be able to see a complete picture of his business summed by either
customer, broker, or geographical location. About 50% of Hobbit’s business is property
insurance and he is concerned about catastrophe risks, especially windstorm, as they have
many clients along the Atlantic coast. Hobbit also has a significant number of large
customers for whom they write many lines of business. Dr. Took wants to be able to
analyze customer and/or insured industry profitability, rather than take a simpler policy
by policy approach

1.2 Informal System Description
AS-IS Systems
Hobbit’s original and most used IT system is SAURON (System for Accumulating
Underwriting, Risks, Or Named insureds), which was originally developed for tracking
Insureds and their submissions and policies. It was enhanced over the years to provide
monolithic functionality across underwriting, claims, and billing for all the Personal Lines
parts of Hobbit’s business and some specialty Commercial lines.
The SAURON system supports personal automobile, homeowners, and umbrella insurance
through a single data model. These models establish a comprehensive data architecture
supporting the entire organization.
Hobbit Insurance continues to rely heavily on some systems developed by the companies
they acquired over the years.
One significant example is SMAUG (System Measuring Accounting & Underwriting
Growth). This system was acquired when Hobbit made its first major acquisition, when it
acquired a carrier focused on Commercial Lines, primarily covering small manufacturing
and small retail customers.
The third major source system that supports Hobbit’s business is SMEAGOL (System for
Medical malpractice, Errors & omissions, Architects and accountants, Gardeners, and
Officers Liability), the system that was acquired when they merged with a specialty
Professional Lines carrier. SMEAGOL provides functionality to support specialized lines of
Property & Casualty, primarily in the many subtypes of Professional Liability lines.
All three major systems cover the functionality to support the following aspects of the
Insurance business.
 Customer Management
 Sales and Marketing -- the submission/policy lifecycle
 Policy/Coverage Administration
 Claims Management
 Financial Reporting
 Needs Assessment for product offering for Personal and Commercial lines
o Home Insurance
o Renters Insurance
o Vehicles consisting of Automobile, Motorcycle, and Recreational Vehicles
o Windstorm Insurance

Some functionality is present in some systems, but not others. For example, getting
Reinsurance coverage was important in Personal Lines and Commercial Lines, but less so
in Professional Liability.
In addition, there are several smaller systems, which are less comprehensive in scope,
which will need to be fed into the end reporting system.
TO-BE System
All the Systems have some ability to generate management reporting for the lines of
business under their purview. However, the three systems have slightly different
definitions of the same concepts, and there is no non manual way to combine the results
across systems. This makes it very cumbersome when management wants a complete
view of the customer. Since the source of information resides in multiple different
databases, users extract data from each of the systems to consolidate reports in Excel for
management reporting.
Hobbit IT has been tasked with designing SAM (System for providing Answers to
Management). The objective for the new system is to create an integrated enterprise
wide database to ensure that there is a single version of the truth and a comprehensive
view of enterprise reporting. The data store will be the central repository for corporate
information representing the integrated data requirements of the enterprise and
designed to support the analytics, decision support, and reporting requirements of the
entire organization.
The data warehouse is characterized by:
 Based upon a comprehensive enterprise model

 Provides integrated data to the organization from all transactional systems.
 Serves a broad user community
 Contains cleaned, consistent data having organization definitions
 Data is at granular level of detail
 Contains time-based "historical" data (Snapshot)
 Driven by analytic requirements
 Structured by aligned business areas
 Database addresses evolving information needs over time or into the future

2 Approach
Our approach is to design a data warehouse and structure it consistently with the business
area defined in the ACORD Information Model and Data Model. Many implementation
decisions need to be made before a final physical data model can be created. This
document will provide the approach used for the Hobbit Insurance use case. Depending
on your specific needs, your approach may vary, but most of the principles will be the
same.
The ACORD Data Model is a highly normalized view of insurance concepts. As the first
step, our approach was to establish an enterprise-wide conceptual data model for the
overall framework of Property and Casualty lines of business.
The following is the approach we used to building the data warehouse for Hobbit Insurance
Company. We started with a best-practice industry set of data models (the ACORD Data
Model). Then, we did the following steps:
 Develop the Enterprise Model, taking advantage of the ACORD Data Model at a high
level. This required us to make decisions on how entities will be modelled, how to apply
subtype rules, how to resolve many-to-many relationships, and which additional
attributes are needed to support an enterprise-wide organization. In our approach, we
identified six major concepts and relationships of importance, which took into account
all seventeen subject areas represented in the ACORD Data Model. The ACORD Data
Model provided the needed 'blueprint' or picture of the target data structures that can
be used to establish a data architecture supporting the needs of an organization for its
current and future needs.
 Develop the Business/Subject Area Models specific to the requirements for Hobbit’s
Property and Casualty business. Subject area models demonstrate how various options
were considered as making decisions on which aspects of the ACORD Data Model to
include. This also requires us to decide which aspects of the enterprise model are not
applicable to this application and remove those. For example, the Investment section in
the ACORD data model is primarily used for Life Insurance. Since Hobbit is a P&C
carrier, that subject area is of limited importance to us. The six subject areas where
Hobbit decided to focus its work were Party, Product, Policy, Claim, Finance, and
Reinsurance. Note that we combined multiple ACORD subject areas into one at times.
For example, both the Agreement and Physical Object areas of the ACORD data model
were collapsed into Hobbit’s Policy subject area.

 Elicit the necessary Physical Data Entities from the ACORD logical design. The logical
Data Model from ACORD makes heavy use of superclasses and subclasses. Sometimes a
logical superclass is created from common real-world entities (e.g. Physical Object is an
artificial superclass that realizes that autos, building, ships, and horse are all objects that
are insured). Sometimes, many subclasses are created from a given superclass,
regardless of the real-world importance of separating that subclass from others of its
kind (the Party superclass has dozens of subtypes such as Law Firm, TPA, and Claims
Adjuster that might not have any specific attributes that are worth storing outside a
generic Party table). The Data Model from ACORD makes no denormalization decisions.
For instance, it defines relationships between parent entities and children entities even
when easy denormalization decisions are commonly made. An example would be the
relationship between Party and Party Phone Number. While a full-blown CRM system
would need to store multiple phone numbers for an Insured (e.g., home, cell, fax, work,
telex, etc.), a common practice would be to denormalize “main” phone number onto
Party and either eliminate the Party Phone table or leave it out there only for
exceptions.
 Define Key Attributes, both logical primary keys and foreign keys. The ACORD data
model does not attempt to list all possible data elements for a given entity. Instead, it
focuses on just “important”, nearly universally common fields. For example, for the
Claim table, ACORD lists “important” data elements such as Date of Loss and Claim
Status, as well as a Primary Key of Claim Number and Foreign Keys such as Policy
Number or Claimant ID. The complete list of Claim data elements varies widely between
carriers, or even systems with a given carrier. Hobbit is using the important fields in the
ACORD Data Model to start its approach to coming up with a complete list.

2.1 Technical Concepts
This use case study is designed to provide suggestions to support implementers of the
ACORD Data Model. However, the guidance provided here should not be considered as
the only way to implement the model. Implementers should determine their approach
based on their unique implementation needs. This section covers some of the technical
considerations used while making these decisions.
Entity Definitions
Business concepts to tables: The ACORD Data Model allows you the flexibility to model
any situation. However, realistically, data modelers will need to model for specific
scenarios. This starts with determining supertype and subtype entities and considerations
for creating tables. Subject areas in ACORD Data Model consist of three main concepts.
You need to make decisions around how you would want to implement core entities and
then sub-types as well as code lists.
NOTE: Entities in the Data Model that have parent as “Information Model Object” are
the base concepts. These base entities are the foundation of conceptual model.

Application Specific data
Adding application-specific data details: Some common attributes and constraints
specific to an application are specified in the model. However, you will certainly add
additional attributes required for your needs. This also includes specifying if a column is
required or optional. At Hobbit, we focused on adding just core attributes.
Naming Conventions
Regarding the naming conventions, we use standards such as:
 Table naming often corresponds to class naming in the ACORD Data Model. In some
cases, we did change names from the ACORD standard to some common names used in
the industry. For example, what’s commonly called “Policy” by P&C and Life insurers is
called “Agreement” in the ACORD Data Model. This was done by ACORD for two main
reasons: a) Policy would be misleading for a reinsurance company, and b) Agreement is a
supertype word that not only covers insurance contracts (e.g., policies or treaties), but
can also cover other types of agreements such as employment agreements or service
provider agreements. Since the focus of Hobbit’s project is just our insurance data, and
not enterprise-wide GL data, all our Agreements will be insurance policies, and thus the
Hobbit name is Policy.
 Column names correspond to attribute naming.
 Every table is provided a single column entity primary key id.
Object Definition and Conversion Considerations

Entity Definition: An entity represents a person, organization, place, thing, or concept of
interest having the same meaning across your organization. An Entity can be very broad
(Party) or it can be very specific (e.g., Employee, Reinsurance Contract, Watercraft,
Reserve Transaction).
Subtype Definition: Subtypes show data that are represented in a more specific way. For
example, in the Party Model, there is an overarching Party (which house very common
attributes like name), there are major subtypes of parties (e.g., Person, Organization,
which capture differing information – Person has birthdate or gender while Organization
has a type of business and a CEO), and there are specific subtypes that capture data
unique to a Party’s role (e.g., Insured vs. Witness vs. Underwriter). Subtype in this context
is used in the ACORD logical model but may not be implemented the same way in the
Hobbit physical data model.
Attribute Definition: Attributes are named generically within the context of the entity,
except if it is a primary key. For instance, if you have 2 entities, employee and customer,
then Employee ID and Customer ID will be unique. However, for customer name and

employee name there is no need to prefix this by entity name as the attribute name. It is
clear “Name” in the employee entity is employee name and “Name” in the customer
entity is customer name.
Code values: This is the common and standard set of values that are used throughout the
organization. Code or Reference lists or tables can be managed as master data; they have
a relatively small number of rows and tend to add or change infrequently. For example,
Operating Countries can be a standard list of country codes where an organization has
business operations. Every insurance organization has dozens and dozens of Codes tables
in its physical data model. For clarity’s sake, we will not be showing codes tables in our
physical data model, as they are relatively uninteresting from a physical design point of
view.
Reference data is tremendously important because it provides the frame of reference to
data, which makes it become information. Reference data allows organizations to
understand operational data and analyze disparately collected data effectively. In our
examples, we are using ACORD provided code lists. As an organization, you will want to
have a master data strategy to include code lists, taxonomies, and hierarchies of data.
Adding primary key fields: All tables have primary key fields with conventional name id
and stereotype <<PK>> to each of the tables. We also added <<FK>> to those tables
where we are referencing related entities.
Specifying data types: we need to choose and specify database-specific data types for
table fields. Our main focus for the data model was to ensure key attributes are provided.
Additional attributes can be added based on your specific needs and assigned appropriate
data types.
This section addresses some of the technical concepts to consider while making
implementation decisions.
Figure 2.0: Basic Entity Definition: Entity, Attributes, and Relationships.

Relationships
(Mapping relationships to foreign keys): relationships between two concepts should be
represented by foreign key constraints between tables. Relationships that are one-to-one are
implemented as a foreign key association, where the primary key of the more general table is a
foreign key on the more specialized table. Relationships that are one-to-many are
implemented as the primary key of the “parent” table being stored as a foreign key on the child
table (the one with the multiplicity of many). Mapping relationships of many-to-many requires
adding a third mapping table with foreign keys to both tables corresponding to related entities.
Figure 2.1: Exclusive Relationship: Party Name can be person name or organization name but not
both. This is resolved by having a name kind code

Identifying and Non-Identifying Relationships: The first attributes usually defined within an
entity is the primary key, which may be one or more columns. Attributes above the horizontal
line near the top of the rectangle are part of the primary key.
Figure 2.2 Identifying Relationship
 An identifying relationship is when the existence of a row in a child table absolutely

depends on a row in a parent table existing. The way to represent this is to make the
foreign key part of the child's primary key. The logical relationship is that the child cannot
exist without the parent.
Example: A book, however, is written by an author, and the author could have written
multiple books. But the book needs to be written by an author - it cannot exist without an
author. Therefore, the relationship between the book and the author is an identifying
relationship.
(Stackflow, 2017, What's the difference between identifying and non-identifying relationships?)
 A non-identifying relationship is when the primary key attributes of the parent are
not part of the primary key attributes of the child.
Example: A book belongs to an owner, and an owner can own multiple books. But the
book can exist also without the owner, and ownership of it can change from one owner to
another. The relationship between a book and an owner is a non-identifying relationship.
(Stackflow, 2017, What's the difference between identifying and non-identifying relationships?)
A non-identifying relationship can be optional or mandatory, which means the foreign key
column allows NULL or disallows NULL, respectively.

Associative Entities for mapping many-to-many relationship: For mapping many to many
relationships between Reinsurance Agreement and Policies we have created an intermediary
mapping table Reinsurance Policy Mapping storing the primary keys to both parent tables
(Reinsurance Agreement key and Policy key) as pairs of foreign keys on the Reinsurance Policy
Mapping table.
Figure 2.3: Associative Entities
2.2 Mapping Concepts (Enterprise to Application)

The mapping of most database concepts to elements is somewhat intuitive. For this use case,
we did not cover constraints and triggers, since those are handled differently in most relational
implementations.
DB Concept Stereotype Additional Description
Schema <<schema>> Stereotype icon is provided
Table/Class <<table>> Stereotype icon is provided; contains tagged value for specifying table type
Column/Attribute Attribute types must correspond to data types supported in target database
Constraint Behavioral Various database constraints are mapped to specific stereotypes on class attributes or
Feature are presented as operations
Trigger <<trigger>> Presented as operation and contains tagged values for defining trigger action parameters
Index <<index>> Presented as operation with argument of indexed field
Primary key <<PK>> Primary Key is usually applied on a single attribute. Attributes above the line are Primary
Key Attributes.
Foreign key <<FK>> Foreign key is represented as a directed association with named ends and operations.
Uniqueness <<unique>> Unique stereotype is usually applied on a single attribute or is represented as an
operation
Null Represented as attribute multiplicity 0..1
Not null Represented as attribute multiplicity 1
Identifying <<identifying>> Applies on foreign key associations if the relationship is one-to-one. This is represented
Association a solid line
Non identifying <<non- Applies on foreign key associations if the relationship is one-to-many or by default. This
identifying>> is represented as a dotted line.
Association

3 Develop Enterprise Data Model
Our first step was to use the ACORD Data Model to develop a high-level conceptual model
that identifies major entities and relationships of importance to the business for Hobbit
Insurance. The ACORD Data Model serves as a reference or core model that cover all
common data entities transcending all insurance business processes. The ACORD Data
Model represents:
 Business Concept Entities

 Business concept properties represented as attributes common to insurance business.
 Relationships between concepts are represented as named and directed associations
with specified end multiplicities.
 Associated relationships. (Note: Our expectation is that mapping entities will be
designed by implementers based on their approach.)
 Code Lists are represented by attributes as referenced entities.
Figure 3.0: ACORD Data Model (Conceptual Model)

The business concepts model can be changed into implementation-specific models by performing specific
transformations and adding details.

In our approach for Data Model is to focus on customer view of Hobbit Insurance
Company. We have logically divided the entire insurance data model into the following
six core subject areas. This will enable us to think about what our needs are in each
area to further our goal of giving the Hobbit executives a 360 view of customer data.
The “top down” order in which we think about the subject areas is:
1. Party and all related logical entities
2. Product Specification for Types of Insurance - Auto, Home, etc.
3. Agreements covering all aspects of insurance policies for our Insureds
4. Claim and claim settlement
5. Finance entities to cover accounting Transactions and Payments & Receipts for
premium and claims settlements.
6. Reinsurance concepts from Hobbit’s point of view as a Cedent.
Figure 3.1: Hobbit Insurance Data Model (Conceptual Model)

The business concepts model is transformed into an implementation-specific model for Hobbit Insurance.

Identify Master Data Concepts
Our approach was to first identify master data business concepts. Much of the data that
needs to be the foundation of the data warehouse are the master data entities such as
Party (Insured and Broker), Products, and Locations (Contacts and Place). ACORD breaks
these into separate subject areas, but we at Hobbit will combine some of these with other
areas for simplicity as we have a focus on transactional data. There is also another section
in the ACORD Data Model called “Kind Code lists” which represent codes tables that we
talked about earlier. We will distribute these among the more business-related subject
areas for analysis purposes.

3.1.1 Enterprise Data Model
Property and Casualty Insurance Enterprise Logical Data Model
The enterprise conceptual data model was designed to represent the most important
data entities in major subject areas and their relationships with each other. This will
serve as the roadmap to present more detailed enterprise physical model as the next
step. The below picture (Figure 3.2) can be found in an accompanying pdf or in the
Erwin Model.
Figure 3.2: Entity Relationship Model

Below is an example of how claim entities are represented in Enterprise Relationship
Model (above diagram in Figure 3.2)
Figure 3.3: Entity Relationship Model-Claim Entities

(The business concepts model is transformed into an implementation-specific model for Hobbit Insurance
The property and casualty Data Model identify major entities and relationships of
importance to the business. The legend in the model diagram makes use of color to
highlight the major subject areas. Next section highlights the major features of each of
the subject areas in the Data Model.
3.1.1.1 Definitions of Data Model Subject Areas

Some of the major functions of the core entities are:
 Party is a major entity that relates to almost all other major entities. It defines
how people and organizations are involved in the insurance business.
o Party has a domicile which serves as a primary address and legal
jurisdiction
o Party has a communication profile (Phone, email, address) which
provides mechanisms for sharing information.
o Party plays one or more roles in agreements such as insured, broker,
additional interest, etc.
o Party plays one or more roles in claims such as claimant who submits a
claim.
o Party plays one or more roles in physical objects such as owner of house,
driver of an auto, etc. which can be referenced in the agreements and
claims for these objects.

 Product Specification is master data which insurance companies can use to
manage their coverage and rules they need to apply. Product Specifications
resemble Agreement structure because product specifications are used for
constructing agreements specific to a party. A product can be thought of as a
class object while an agreement/policy is an instantiation of that class.
o Product composition is the key linking coverage to agreement
o Insurable Objects can be defined with respect to coverage specifications
and rules.
 Policy (Agreement) is a focal point for all insurance / reinsurance or financial

contracts. It is a manifestation of agreement composition and rules. For our
development work at Hobbit, we will only focus on Policy and Reinsurance
agreements.
o The core components that make up policies are deductibles, limits, and
coverages, which impacts premium.
o Agreement composition is the key linking policy to claim.
o Policy coverage is key link among Policy, Claim and Reinsurance.
o Policy ties to coverage and product composition.
o Insurable Objects are defined with respect to parties owning physical
objects and can be referenced by multiple policies.
NOTE: Product, Coverage and Rules, and Location are examples of Master
“reference” Data concepts that can improve data quality.
 Claim is tied to Party, Physical Object, Policy & Coverage and Reinsurance
through Agreement.
o Claim is tied to Policy through Policy coverage.
o Claim can represent compensation for covered loss based on policy
coverage, but need not be tied to the exchange of money as an FNOL
might not develop, or a reserve can be put up precautionary
 Finance is a common entity consisting of financial accounting and money

transactions such as premium payments or claim settlements. For an Insurance
agreement, it is a contract between insurance company and insured.
o An insurance company promises to pay out losses to the insured in
exchange for the insured to pay regular premiums to the insurance
company.
o The Finance subject area consists of financial transactions types such as:
 Premium, commission, taxes, fees, and surcharges on Policies
 Claim Loss amounts and Claim Reserve amounts
 Subrogation or salvage amounts
 Reinsurance transactions both to and from the reinsurers
 Money coming in or out of Hobbit due to policy related
transactions. Note that the scope of the Hobbit project does not

include non-insurance financial obligations such as salaries, rents,
equipment, etc.
 Reinsurance can optionally be used for any insurance agreements. Reinsurance

essentially is an extension of insurance in that insurance risk is spread among
many carriers. Because Hobbit has an extensive exposure to catastrophic risks
such as Atlantic coastal storms, they are extensive users of reinsurance capacity.
In the Hobbit project, we are capturing three basic functional aspects of
reinsurance -- Agreement, Share, and Financial transactions.
o Reinsurance has relationship to Policy
o Reinsurance has relationship to Claims
o Reinsurance has relationship to Financial Provision

4 Develop Business Area Data Modeling
4.1 Business Area Data Models
This next section presents our strategy for transforming the enterprise data model
(business concepts enterprise model) to individual subject area data models.
The deliverables represent six subject area data models for our Property and Casualty
business to group all of our data entities into discrete areas to aid understanding.
4.2 Party Model

Party is one of the master data subject areas of the model. It is a supertype class,
intended to cover all organizations and persons with whom a carrier interacts with during
its business. It has two overlapping types of supertypes.
The first is Organization vs. Person. While parties of both types have many similar
attributes (e.g., they both have names, addresses, and bank accounts), they have many
attributes that correspond to just one or the other. Persons have genders, titles, and eye
colors, while organizations may have date established, agency ratings, or type of business.
Note that not every attribute is needed in all cases for all insurance. Gender may be an
important attribute for life insurance rating but may be meaningless in a property claims
context.
The second is Role – whether a party is an Insured or a Broker or a Claimant or a Reinsurer
or an Annuitant or an MGA. There are potentially dozens of Roles of varying importance.
Note that a given Party could serve two different roles on a given Policy (or across
Policies). For example, it would be common to have the Insured on a property policy also
be a Claimant, whereas it would be theoretically possible but very unlikely for the Broker
to also be a Claimant.
Note that these two types of subtypes are not hierarchical. An Insured can be a Person or
an Organization, whereas a Reinsurer is almost definitely an Organization.
Narrative
Well, let me think. Since I’m a P&C primary insurer, there are a bunch of ACORD organization
roles that are outside of my scope – e.g., Beneficiary, Guarantor, Annuitant, etc. Furthermore,
while I can imagine that my systems deal with many possible roles, for most of them, I really
only care about a limited set of information like name, and address, and phone/email. So which
types do I really care about having detailed data elements? Probably Insured, Broker, Reinsurer.
So, I will have a Party table, with a bunch of children tables, such as PartyAddress, PartyEmail,
and PartyPhone to allow for multiples per Party. For my developers’ sake, I will denormalize the
primary address and phone and email onto the Party table. I’ll create separate tables for
Insured and Broker and Reinsurer to house specific data elements. These will have the PartyID
as an FK on them. I’ll also create a PartyType table which is many to one with Party to allow for
common cases where a Party serves in multiple roles (e.g. both an Insured and a Claimant)

4.2.1 Party Model Design Choices
Party is a major entity that relates to almost all other major entities. Party represents
people or organizations involved in insurance interacting with agreements, policies,
claims, etc. For Hobbit Insurance, we have identified a few roles we thought are
important where we need to capture specific information in a separate entity.
4.2.1.1 Implement Subtypes (Evaluate Children Table)
As discussed earlier, there are dozens of subtypes of Party that may be used in our
Hobbit Insurance data model. There are only a handful of subtypes where we may store
information other than name and address basics.
INSURED is probably the most important, and we will model that as a separate table as
Insured represents the customer view. In addition, there are enough different details
that need to be captured for types of individuals (INSURED PERSON) and organizations
(INSURED ORGANIZATION) to warrant the creation of separate tables. Also, Insured
contains other related reference entities such as INSURED DETAIL to capture financial as
well as non-financial relationships such as Accounts, Affiliations, Group, preferences,
etc.

BROKER, CLAIMANT, DRIVER, REINSURER are the other subtypes where we will make a
separate table to capture unique specifics. For these types of roles, all profile and
demographic attributes are kept in a single entity which is a subtype to Party.
PARTY is a catchall subtype that will be used for all other subtypes (e.g., MGA, TPA, Law
Firm, Witness, Police Officer) to capture basic name information. It will also have an
entry for the five specific subtypes mentioned in the previous two paragraphs. Other
many-to-one children entities such as PARTY NAME, PARTY ADDRESS, PARTY PHONE,
PARTY EMAIL ADDRESS, will be created for use for both the five specific subtypes and all
the generic subtypes.
4.2.1.2 Implement Enumeration Values (Evaluate Code Lists)
We have used the following code lists in our model to demonstrate usage of reference
data. In our examples, we are using ACORD provided code lists. As an organization, you
may want to evaluate your master data strategy to include code lists, taxonomies, and
hierarchies of data.
 Company Status Code List

 Domicile Tax Code List
 Education Level Code List
 Ethnicity Code List
 Income Type Code List
 Marital Status Code List
 Organization Kind Code List
 Organization Name Usage Code List
 Organization Status Code List
 Organization Status Kind Code List
 Ownership Type Code List
 Party Kind Code List

4.2.2 Party Model Entity Description
Table Name Definition

HB_Party This is the supertype for all organizations and persons.
HB_Party_Name Party Name includes name details common to persons and
organizations.
HB_Party_Social_Address This concept represents a means of identifying social media profile
addresses for persons and organizations, such as Facebook, twitter,
LinkedIn, etc.
HB_Party_Email_Address This concept represents a means of identifying email address for both
persons and organizations. Further identification of types of addresses
allow to differentiate business or personal
HB_Party_Telephone This concept represents Types of Phone Numbers. Further identification
of types of Telephone Numbers allow to differentiate business or
personal or any other purpose
HB_Party_Address This concept represents a means of identifying and locating street
address. Common addresses include a postal address, shipping address,
etc. Additional attributes such as Intersection Address can also be
drafted in this model
HB_Insured This is the supertype for all insureds, a person or organization who buys
insurance or is a policy holder.
HB_InsuredOrganization A business concern or organizations (legal entity), who buys insurance.
This concept captures various details that are specific to an organization
such as legal status, nature of operations, Years in Business, etc.
HB_InsuredPerson A human being who buys insurance. This concept captures details that
are specific to a person such as gender, age, marital status, etc.
HB_Insured_Detail This concept is a generalizing concept providing further details about an
insured person or an organization. Detail type would allow elements to
capture items such as
 Person specific details: birth and marriage details-
 Organization specific details: financial results for instance, fiscal
residence, tax file, memberships, etc.
HB_Broker This concept describes a person or an organization who arranges
transactions between insurer (Seller) and insured (Buyer).
HB_Driver This concept describes set of information needed to define the profile of
a driver as related to a policy (e.g. driver on a personal automobile
insurance policy).
HB_Other_Party_Roles Party is the supertype for all organizations and persons. This concept
represents information needed to define other types of roles that are
less important such as witness in a claim. Most likely, you would just
need name, address, and contact information.
HB_Claimant This concept describes information needed for a person or organization
that files a claim for benefits under the provisions of an insurance policy.

4.2.3 Party Model Relationships
Below are relationship of CORE Entities for Party and Contact & Place
Relationship Parent Entity Relationship

Child Entity Name
Name Name Type Relationship Definition
Broker on Non-
Policy HB_Broker HB_Policy Identifying This relationship links a party role (Broker) in Policy
Broker ON
Reinsurance HB_Reinsurance Non- This relationship links a party role (Broker) in Reinsurance
Agreement HB_Broker Agreement Identifying Agreement
Insured ON This relationship links a party role (Insured) to additional
Insured Detail HB_Insured HB_Insured Detail Identifying details regardless of person or organization
Insured ON
Insured HB_InsuredOrganiz This relationship links a party role (Insured) is an
Organization HB_Insured ation Subtype organization
Insured ON
Insured Person HB_Insured HB_InsuredPerson Subtype This relationship links a party role (Insured) is a person
Insured on Non-
Policy HB_Insured HB_Policy Identifying This relationship links a party role (Insured) to Policy
Organization
Owns
OrganizationSt HB_InsuredOr Organization Non-
atus ganization Status Identifying This relationship links an organization to a status.
Organization
Plays
RegistryAuthor HB_InsuredOr Non- This relationship links an organization to one or more
ity ganization Registry Authority Identifying registry authority roles.
This relationship links a civil registration with a person (e.g.
CivilRegistratio HB_InsuredPer Non- registrant) participating in the registration (e.g. man and
n On Person son Civil Registration Identifying woman as persons associated with a marriage certificate).
PersonRegistra HB_InsuredPer Non- This relationship links a person registration to the
tion On Person son Person Registration Identifying corresponding person (e.g. registrant).
Party ON Party
Address HB_Party HB_Party Address Identifying This relationship links a postal street address with party
Party ON Party HB_Party Email
Email Address HB_Party Address Identifying This relationship links a email address with party
Party ON Party
Name HB_Party HB_Party Name Identifying This relationship links a name with party
Party ON Party HB_Party
Telephone HB_Party Telephone Identifying This relationship links a Telephone with party
Party ON HB_Party Social This relationship links a Social Address with party (i.e.
Social Address HB_Party Address Identifying Linkedin, facebook, etc.)
Party Plays
Party Role HB_Party HB_Claimant Subtype This relationship links party playing Claimant Role
Party Plays
Party Role HB_Party HB_Driver Subtype This relationship links party playing Driver Role
Party Plays
Party Role HB_Party HB_Reinsurer Subtype This relationship links party playing Reinsurer Role

Relationship Parent Entity Relationship
Child Entity Name
Party Plays
Party Role HB_Party HB_Broker Subtype This relationship links party playing Broker Role
Party Plays HB_Other Party
Party Role HB_Party Roles Subtype This relationship links party playing Other Party Role
Party Plays
Party Role HB_Party HB_Insured Subtype This relationship links party playing Insured Role
This relationship links a party with one or more party roles
Party Plays Non- (being played by the party). For example, the party "Hobbit
PartyRole HB_Party Party Role Identifying Insurance" may be associated with the party role "Insurer".
Party
(Reserve) ON
Financial HB_Financial Non- This relationship links a Party Role with Financial Provision
Provision HB_Party Provision Identifying (Reserve)
Party
(Subrogation)
ON Claim Non-
Provision HB_Party HB_Claim Provision Identifying This relationship links a Party Claim Provision (Subrogation)
PartyRole On HB_Party Non- This relationship links a party role to a party name for the
PartyName Name Party Role Identifying role.

4.3 Product Specification
Product specification provides a detailed description of the coverage types, amounts, and
provisions to be used in a proposal to an insured. It describes the characteristics of what
the customer will be able to do and what obligations are owed him once he purchases the
insurance product. Product Specification consists of component descriptions and rules
from the perspective of the service provider (insurer).
Insurers can incorporate components to encourage social or environmental behaviors into
product offerings. For example, you can offer a discount on low emissions vehicles or
discount for safe driving record. Product Specification may also consist of components to
limit risk by placing limits on deductibles in product offering.
The product specification shows entities involved in defining the company products and
coverages. Like Party, this is the framework for defining master data for the offerings. It
is used in defining policy data, but it is NOT the policy. It is the template for the policy.
The Product Specification subject area provides you the flexibility to have a catalog of
product offerings. Once we get into the actual policy, you will see both Product
Specification and Policy share the same structure.
Narrative
As a P&C insurer, my product line deals with a wide range of commercial and personal
property & casualty insurance coverages. Our homeowner's insurance covers losses and
damages to residence, furnishings and other possessions. Renter's insurance is property
insurance that covers possessions and liability. At Hobbit, we also provide commercial policies
that provide coverage for damage to assets, liability that covers both physical and non-
physical claims. We also offer special coverage for very different types of business -- for
example, restaurants will need coverage for fire caused by accident in the kitchen as well as
liability where customer may slip and fall on a banana peel on premises. Architects and
accountants and lawyers and medical professionals will all need different kinds of professional
liability insurance in case they are sued by one of their customers. Some companies may take
out kidnap & ransom insurance on their executives. Some organizations might sponsor
fundraisers based on unlikely probabilities such as “hole in one” events.
The ACORD Data Model provides a supertype “product base” and many subtypes that deal
with various types of coverages, provisions, limits, etc. While this may provide a more
comprehensive design for some organizations. I really only care about the most important
ones such as Coverage, Deductibles and Limits. My model will have a Product Specification
table to store core attributes that define the product and it would have master data
relationships to define Broad Line of Business, Lines of Business as well as other code lists. This
would provide core attributes to be used in analytics. I have decided to create child tables that
deal with core components to identify coverage, limit and deductibles. I also decided to create
a separate entity to capture “All other” types of components in a single table having type
codes -- this will give me the flexibility to model things I cannot predict right now without
dramatically changing the model.

The ACORD Data Model provides a way to model rules for products that are offered. Since we
are building a data warehouse, we don’t need to capture how rules are created and applied.
We don’t need to be able to re-create a rating or pricing decision. The purpose for the Data
warehouse is not to have transactional rules in the Data Repository. We only to capture which
rule or calculation is applied but not how it is applied to the product specification.
4.3.1 Product Specification Model Design Choices
Product Specification is reference data which insurance companies can use to manage
their coverage and rules used for constructing policies. The ACORD Product specification
model provides extensive functionality to specify products and rules that can be applied
to technical design such as attribute rules, or rules that can be part of coverage such as
calculation rules. For this phase of the design, we decided to focus on core entities of
product specification and did not implement rule specifications.

ACORD provides structure around three main areas when providing elements to
construct product offerings
 Product Component Specification – provides a design reference of options and

configurations available when constructing a policy.
 Product Rule Specification – This is a supertype of most of the detailed elements
for a given product definition. You can define various types of rules such as
calculation rules, attribute rules, etc. Hobbit decided not to use this supertype.
We don’t need to know the rules for calculations as this information is relevant
in a transactional rating or pricing system, and not in a data warehouse. In our
data repository, we will store the type of calculation as a referenced attribute
and will store the calculated amount in the Policy subject area.
 Finance Rule Specification – Is a place to define investment or trade rules. As
this part of the ACORD Data Model is more pertinent for life insurers, Hobbit
decided not to use this section at this time.
We decided to have a Product Specification table to capture detailed product data
elements. You can use master reference attributes such as Broad Line of Business, Line
of Business, and Product Type.
Component Specifications
Core components that make up most insurance policies are the coverages, deductibles,
limits, and clauses. The combination of the previous correlates directly to the premium
calculated for the policy. We created separate tables to capture these core components
that make up a product offering. These core components can be children of either the
high-level product, or a coverage in the high-level product. For example, you can have a
per accident deductible on either or both of an overall personal auto policy or a
particular coverage on the personal auto policy. These children tables will have Product
Key ID and Product Coverage Key ID on them as FKs, one of which will be null. This
design provides the flexibility to have components defined for Coverage and/or for
Product.
We created a Coverage Specification table, which is a child table of Product
Specification. You can have different combinations of coverages being offered, and this
table captures core attributes on each type of coverage. Hobbit’s core business is
property and casualty, so types of coverage specifications will be for Property Coverage
Specification, Commercial Auto Coverage Specification, Legal Professional Liability
Coverage Specification, etc. In the future, if other products are added to Hobbit’s mix of
business, we should not have to change the design but use the same structure for
additions. Usage of code lists will facilitate this flexibility for future expansion.
In the example of the Product Specification Structure for the personal automobile
offering, we will have a coverage for physical damage to your automobile and liability
coverage to protect you from any litigation resulting from a claim in an automobile
accident. We will model this as one product providing two coverages and each coverage
having its own core components of limits and deductibles.
 Deductibles Specifications is a child entity to the Product Specification as well as to

the Coverage Specification. It will have a nullable Product Key ID as FK to provide
flexibility for association. Deductible component provides options for a specific
amount the insured will pay out-of-pocket before the insurer pays the claim.
Deductible can apply per policy, per claim, or per coverage. For example, for a
personal automobile policy, there can be a deductible of $500 for damages to a
car, per claim. There can also be liability coverage for personal injury which could
have deductible of $1000 per coverage.
 Limit Specifications is a child entity to product specification as well as to Coverage

Specification. The limit component describes the maximum amount an insurer will
pay for a covered loss. Limits may describe if it is by period (annual or policy
term), per loss or injury, or over the life of the policy. Product Limit Specification
allow the management of variations of attributes that make up limits. Limits can
apply per policy, per claim, or per coverage. As a result, it will have a nullable
Product Key ID as FK on the table.
 Clause Specifications is a child table to Product Specification as well as to Coverage

Specification. It will have a nullable Product Key ID as FK to provide flexibility for
association. For example, if there is a coinsurance clause on property insurance,
this clause can be added to the coverage where Hobbit is responsible for 80% and
the insured is responsible for 20% after the deductible.
Businesses may require special types of insurance policies that insure against specific
types of risk faced by a particular business. For example, a fast-food restaurant owner
needs a policy that covers damages or injury that occurs as a result of cooking with a deep
fryer. This could be a separate Clause added to the Policy. Similarly, an auto dealer is not
subject to risk associated with a restaurant but does require coverage for damage or
injury that could occur when a customer is test driving a car.
data.

 Broad Line Of Business Code List
 Line Of Business Code List
 Product Specification Kind Code List
 Product Status Code List
 Deductible Applies To Code List
 Deductible Type Code List
 Liability Coverage Code List
 Property Coverage Code List
 Limit Applies To Code List
 Limit Type Code List
 Product Component Specification Kind Code List
4.3.2 Product Specification Model Entity Description

HB_Product_Specification A product specification is the design outline from which a policy can be
produced. The product specification describes the rules and options available or
needed to describe an offer that can be used when constructing a policy.
HB_Coverage_Specification This is a product component specification for a corresponding coverage in a
policy. For example, Property coverage would have a protection against damage
to personal or business property. Similarly, Liability component provides
protection against legal liability for damages caused to someone else’s property.
HB_Limit_Specification This is a product component specification for a corresponding limits
component. Limit component describes the maximum amount an insurer will
pay toward a claim. Insurer may have different tiers of amounts which can be
directly correlated to amount of premium. The higher the coverage limit, the
higher the premium may be.
HB_Deductible_Specification This is a product component specification for a corresponding deductible
amount.
Homeowners insurance deductible is the amount of money that you are
responsible for before your insurance company will pay you for the loss in a
claim. In product offering, you may have different tiers of deductibles which
can be directly correlated to amount of premium
HB_Other_Specification For flexibility, you can define other types of components by using Product
Component Specification Kind Code List

4.3.3 Product Specification Relationships
Below are relationship of CORE Entities for Product Master
Relationship Parent Entity Child Entity

Name Name Name Relationship Type Relationship Definition
Coverage This relationship links a product association with an
Specification included product specification Clause (e.g. product
For Clause HB_Coverage HB_Clause specification components) in support of product
Specification Specification Specification Non-Identifying design/composition.
Specification included product specification deductible (e.g.
For Dedutible HB_Coverage HB_Deductible product specification components) in support of
Specification Specification Specification Non-Identifying product design/composition.
Specification included product specification limits (e.g. product
For Limit HB_Coverage HB_Limit specification components) in support of product
Specification Specification Specification Non-Identifying design/composition.
Specification included product specification Other Specifications
ON Other HB_Coverage HB_Other (e.g. product specification components) in support
Specification Specification Specification Non-Identifying of product design/composition.
Product
Specification
ON Coverage HB_Product HB_Coverage This relationship links a product specification to a
Specification Specification Specification Identifying product coverage specification.
This relationship links a product specification to a
policy. For example, in product specification, we
Product could have gold, silver, and bronze plans. When
Specification HB_Product specifications are instantiated into a given policy, it
ON Policy Specification HB_Policy Identifying will be one plan (e.g., gold).

4.4 Policy
Property and casualty insurance are specifically designed to help protect your possessions
from theft or destruction. It also may protect your assets from being depleted through
disaster or litigation claims brought against you. Many organizations set up Product
Specifications as master data to describe coverage types, amounts, and provisions used in
selling policies to insureds.
Policy structure is aligned with the product structure and definitions. In addition to the
entities referenced in product specifications, the Policy subject area also covers the
ACORD Data Model section of Physical Objects. Property policies provide coverage for
physical items, such as homes, commercial buildings, motor vehicles, and personal
possessions or business inventory. Types of property insurance include homeowner’s
insurance, fire insurance, flood or earthquake insurance, and automobile insurance.
These insurance policies may have an “open perils” or a “named perils” clause. The open
perils clause covers losses for reasons that are NOT specifically excluded in the policy,
such as earthquakes, floods, and acts of terrorism or war. A named perils clause requires
the actual cause of loss (Peril) to be listed in the policy, such as windstorm, tornado,
pandemics, flood, and theft. For example, depending on the named perils included, water
damage may be covered from a water heater leak, but if the same water damage were
caused by a flood from hurricane, it may not be covered.
Casualty/Liability coverage covers you for losses that you may cause to another individual
or business. For example, if you have liability insurance on your car and another party is
injured in a collision caused by you, your liability insurance will take care of the other
person’s medical and repair costs. In addition, if someone sues you because of harm you
may have caused to him or to his possessions, your casualty insurance may cover the cost.
Both individuals and businesses can purchase property and casualty insurance. Personal
policies include homeowner’s insurance, renter’s insurance, and automobile insurance,
whereas commercial policies are written specifically for businesses and other
organizations and may include commercial general liability, and commercial property
insurance.
Narrative
We are making similar decisions in the Policy area around Coverages, Limits, Deductibles, and Clauses
that we made in the Product Specification subject area. We view the Policy as an instance of the
Product Class so they will have parallel structures. In the model, we are aligning the Policy structure
the same way. First, we created a Policy table that would hold core single valued attributes that are
relevant of all lines of business (such as effective date, policy number, date bound) as well as well as all
foreign keys and associations (such as underwriter, insured, broker, various lines or classes of
business). We also decided to instantiate core components as separate tables such as coverage, limits,
deductibles and clauses. Since we are building a data warehouse, we don’t need to create separate

tables for all the components, so we decided we would use a table for all other types of component
attributes and use code lists to determine type of component information we store. Transactional
rating or pricing systems may have a lot more components, however, we do not need to have all of
them in our Data Warehouse.
We are modeling agreements for Insurance Policies and Reinsurance Agreements separately. The
ACORD Data Model treats them both as Agreements, which would be a good design if Hobbit were a
combination insurer and reinsurer (as many Bermuda companies are). However, at Hobbit, we only
sell insurance and only buy reinsurance, and we always do gross, ceded, and net calculations. Thus,
we will treat Insurance Policies and Reinsurance Agreements as two entirely different physical tables in
two different subject areas, even though ACORD considers them subtypes of Agreement.
Another area of focus was how we chose to model Physical Objects we are insuring. We decided not to
create just one physical object supertype table that would store all types of information for buildings
as well as vehicles, watercraft, livestock, jewelry, etc. This table, if instantiated, will be one
humongous table having lots of columns for all types of objects in the coverage and you would
constantly be adding more columns as needed. We evaluated our business and realized our
underwriting activity weighed heavily towards automobiles and water boats as well as houses,
businesses, structures, etc. Our focus on object subtypes was to instantiate entities for insurable
objects that require specialized information. Our decision was to instantiate building, land vehicles
and watercraft to store attributes that are very different from each type of object. For building we
may information about type of roof, how many floors, etc. For land vehicles, we can have how many
passengers, make, model and year of car. Of course, watercraft attributes are even different from
land vehicles. We can also make use of a generic Physical Object table if we need to keep track of just
basic name and description information (e.g., jewelry or fine art).
NOTE: In the diagrams, we show a specific coverages for leisure aircraft, we did not actually
instantiate this table, but we did include this in the subject area model for illustration purposes. If
there is a need to create specific physical object entities in the future, this is how it would look like.
For example, if we start insuring thoroughbred horses, we could make a separate Horse table with
specific data elements such as lineage, trainer, jockey, and medical conditions, and divorce it from
the generic Physical Object table.
Our supertype Physical Object has unique key ids that are referenced on all the subtype type tables.
I’ll create separate tables for Land Vehicle and Watercraft and Building to house specific data
elements. These will have the PhysicalObjectKeyID as an FK on them. One of the reasons we took this
approach was to support data warehouse reporting functionality. Having Physical Object table will
help having customer focused information where developers can easily aggregate information by
policy or by physical object characteristic.

4.4.1 Policy Model Design Choices
Policy is the focal point for all insurance contracts. It is composed of Policy components
and rules. Tables in Product Specification and Policy share the same structure because
they store the same information. The difference between the two is that in product
specification, we store all possible offers that can be presented to a client, whereas in
Policy, it is the exact policy assigned to a client.
Decision on Agreement Component Subtypes

Making use of the ACORD Data Model, we made decisions to create separate tables for
the component subtypes of Policy Coverage, Policy Deductible, Policy Limit, and Policy
Clause. Our model has Policy and Policy Coverage tables where we have policy key ID on
policy coverage as an FK for the one to many relationship between Policy and Policy
Coverage. The Policy table will store core attributes such as foreign keys to parties,
policy descriptions and numbers, and the various lifecycle dates of the policy. In
addition, we instantiated core components such as limits, deductibles and policy clauses
as child tables to Policy Coverage. The ACORD Data Model has many more components
such as benefits, waiting period, etc. For other less important additional details related
to coverage, we decided to use a component type Code List for specifying details in the
Policy Other Components table. Our focus was to instantiate only important entities

required for reporting purposes in the data warehouse. Design considerations would
differ if this was an operational system.
For example, for a BOP policy, there will be a single row in Policy, and several rows in
Policy Coverage, one for property, one for liability, and one for commercial auto. For
each coverage row, there may be one or more rows in Policy Limit or Policy Deductible.
In addition, there may be a Policy Limit row that is the direct child of Policy without a
Coverage in between.
Example:
Bilbo has coverage for Store A, Warehouse B, and Office C at International Drive in Bag
End which covers fire and water damage. However, if the fire is caused by an
earthquake and the peril is clearly stated in Policy Peril for exclusion, there is no
coverage. In addition, he will have coverage for personal property for Store A, where he
is operating his own business, which covers any machinery, desks and office equipment
in the building. He is renting Warehouse B, so, in addition, he has a Policy Clause to
exclude property coverage for Warehouse B because the renter is responsible for buying
his own insurance for his personal property. He can also have a clause for coinsurance if
loss was due to renter’s negligence in Warehouse B. Subtype components can be
applied to Policy or Policy Coverage level of granularity. Policy Deductible, Policy Limit,
and Policy Clause have an FK to the Policy table that is nullable to allow relationship to
either Policy or Policy Coverage. For example, Limit Component of Policy Coverage,
Bilbo can have LIMIT on Coverage of $100,000 on Property in Store A. He can also have
another maximum limit on the Policy, in case loss is to both buildings, his business and
renter’s business of 1M, based on the assessment (Policy Assessment) of the building.
His policy can also have a Policy Deductible amount that is uniform everywhere.
Results:
Insured (1 row) -- Bilbo Baggins
Policy (1 row) -- BOP policy
Policy Coverage (3 rows) -- Property, Commercial Auto, Liability
Policy Limit (6+ rows) -- $1M overall limit, $500K per claim limit (attached to null
coverage), $800K property limit, $500K CA limit, $500K liability limit, $100K limit on
property in Store A
Policy Deductible (1 row) -- $1000 per claim deductible

Policy Clauses (10+ rows) -- mostly around Commercial Auto, some around rental of
office to others
Policy Peril (4 rows) -- Includes Windstorm and Fire. Excludes Earthquake and Nazgul.
Location (1 row) – Bag End
Building (3 rows) -- 1 store, 1 warehouse, 1 office
Vehicles (3 rows) – 3 different wagons
Physical Objects (8 rows) -- 1 location, 3 buildings, 3 vehicle, 1 gold ring
Decision on Party Roles in Agreement

Party Roles in the context of policy describe how a person or organization interacts with
Hobbit in the context of a given policy, claim, or money exchange. For example, a
person may have two policies with Hobbit, one for Home and one for Personal Auto.
Nick adds Manreen as another driver on his auto policy. Party Roles in Agreement
would identify the particular context in which Nick and Manreen have relationships with
us. Both Nick and Manreen are identified as Drivers on a Car that is covered under the
policy. Nick is the Insured with Hobbit. We have identified a few relationship subtypes
where we would create a table to capture detailed information about the relationship.
On the other hand, there might be other relationships that can be stored in the generic
Other Policy Roles table.
 Driver Party Role
 Insured
 Broker
 Underwriter of Record
 Other Policy Roles (i.e. Lender, Lienholder, etc.)
Decision on Financial Provision in Agreement

Insurance Premium pricing is determined by risk levels and there are many factors
actuaries use to determine the premiums. For this project, we are not interested in how
the calculation of premiums or fees was made. We only care about the results which
we will store. Financial Provision will store calculated amounts.

data. We recommend usage of code lists and master reference data is one of the master
data subjects every organization needs to decide how to implement.
 Agreement Component Kind Code List

 Agreement Component Status Code List
 Agreement Kind Code List
 Agreement Status Code List
 Cancellation Reason Code List
 Insured Type Code List
 Qualified Plan Type Code List
 Underwriting Sub Classification Code List
 Vehicle Use Code List
4.4.2 Policy Model Entity Description

HB_Policy This supertype contains attributes relevant to insurance agreement and
components. Policy will specify the insured and association to other tables
with details about limits and insured objects.
HB_Policy_Coverage This instantiation of Agreement Component provides details for
corresponding coverage in a policy. For example, Property coverage would
have a protection against damage to personal or business property. Similarly,
Liability coverage provides protection against legal liability for damages
caused to someone else’s property or person. Coverage component provides
details about the circumstances under which an amount of risk or liability is
covered.
HB_Policy_Limit This is a policy component for a corresponding limits component. Limit
component describes the maximum amount an insurer will pay toward a
claim. Limits can be directly correlated to amount of premium. The higher
the coverage limit, the higher the premium may be.
HB_Policy_Deductible An amount the insurer will deduct from the loss before making payment.
Deductible is the amount insured will pay of pocket.
Homeowners insurance deductible is the amount of money that you are
responsible for before your insurance company will pay you for the loss in a
claim.
HB_Policy_Clause This component of a policy deals with a particular subject of the Policy. It
may have a coinsurance clause, where Hobbit may be responsible for 80% of
the loss and the insured is responsible for the 20%.
HB_Policy_Other_Components There can be many other components. This could be a specific situation
needing documentation that could lead to occurrence of a loss.
HB_Policy_Peril You can specify what perils are insured in a policy. For example, if you live in
Florida, you may have policy that covers the named peril of Hurricane.

HB_Physical_Object This concept defines all physical assets likely to be involved in an insurance
policy. For example, House, Building, Location, Auto, Boat, etc.
HB_PhysicalObject_Coverage_M This concept defines the many to many relationship between physical object
apping and coverage. You can have many physical objects scheduled with a coverage
OR you can have many coverages for a physical object.
HB_Location This concept defines the geo location of one or more buildings. Hobbit may
insure the location of Rivendell which is made up of a number of homes,
meeting halls, and valuable trees
HB_Building This concept represents a physical Building. In context of commercial
property, this is the building and any equipment that is permanently installed
HB_Building_Address This concept represents the street address of a building.
HB_Land_Vehicle This concept gives particular features of a vehicle that is covered in the
policy. It is generally defined to mean a device capable of transporting people
or property which is self-propelled by mechanical or electrical power. Land
vehicle would include automobiles, motorcycles, and off-road vehicles
HB_Driver This concept is subtype of Party that is driver. In context of Policy, it
describes information needed to define the profile of a driver as related to a
policy (e.g. driver on a personal automobile insurance policy).
HB_Driver_Vehicle_Mapping Driver mapping table describes the many to many relationships between
drivers and vehicles. You can have many drivers for a vehicle OR you can
have many vehicles to a driver.
HB_Aircraft This concept gives particular features of an aircraft, which may include
information about size of the engine, passenger capacity, etc.
HB_Watercraft This concept gives particular features of a watercraft, which might include
type of hull, year in service, etc.
HB_Policy_Assessment_Result The result of an evaluation, based on an expert opinion, that gives financial
valuations of physical objects and conditions of places or physical objects.
HB_Policy_Assessment_Result_St This represents the status of an assessment for physical objects covered in a
atus policy.

4.4.3 Policy Model Relationships
Relationship Parent Entity Child Entity Relationship

Name Name Name Type Relationship Definition
Aircraft ON This relationship links the result of an
Claim assessment and the physical object
Assessment HB_Claim_Assessment Non- that served as the subject of the
Result HB_Aircraft Result Identifying assessment.
Aircraft ON
Physical Object This relationship links a particular
Coverage HB_PhysicalObject Non- aircraft to one or more coverages on
Mapping HB_Aircraft Coverage Mapping Identifying a Policy
Aircraft ON This relationship links the result of an
Policy assessment and the physical object
Assessment HB_Policy_Assessment Non- that served as the subject of the
Result HB_Aircraft Result Identifying assessment.
Building Having
Building Non- This relationship links a physical
Address HB_Building HB_Building Address Identifying object building to building address.
Building ON This relationship links the result of an
Result HB_Building Result Identifying assessment.
Building ON This relationship links a particular
Physical Object building to one or more coverages on
Coverage HB_PhysicalObject Non- a Policy
Mapping HB_Building Coverage Mapping Identifying
Building ON This relationship links the result of an
Result HB_Building Result Identifying assessment.
Driver ON
Driver Vehicle HB_Driver Vehicle This relationship links a party role
Mapping HB_Driver Mapping Identifying (Driver) to Vehicle in Policy Coverage
Land Vehicle This relationship links the result of an
ON Claim assessment and the physical object
Result HB_Land Vehicle Result Identifying assessment.
Land Vehicle
ON Land Driver
Vehicle HB_Driver Vehicle This relationship links Land Vehicle to
Mapping HB_Land Vehicle Mapping Identifying Driver for many-to-many relationship
Land Vehicle
ON Physical This relationship links a particular
Object land vehicle to one or more
Coverage HB_PhysicalObject Non- coverages on a Policy
Mapping HB_Land Vehicle Coverage Mapping Identifying
Land Vehicle This relationship links the result of an
ON Policy assessment and the physical object
Result HB_Land Vehicle Result Identifying assessment.

Location OF Non- This relationship links Location to
Building HB_Location HB_Building Identifying Building
Location ON This relationship links the result of an
Result HB_Location Result Identifying assessment.
Location ON This relationship links a particular
Physical Object location to one or more coverages on
Coverage HB_PhysicalObject Non- a Policy
Mapping HB_Location Coverage Mapping Identifying
Location ON This relationship links the result of an
Result HB_Location Result Identifying assessment.
Physical Object Relationship identifies Physical
AS Aircraft HB_Physical Object HB_Aircraft Subtype Object type of aircraft
As Building HB_Physical Object HB_Building Subtype Object type of building
AS Land Vehicle HB_Physical Object HB_Land Vehicle Subtype Object type of land vehicle
AS Location HB_Physical Object HB_Location Subtype Object type of location
AS Watercraft HB_Physical Object HB_Watercraft Subtype Object type of watercraft
Physical Object This relationship links the result of an
ON Policy assessment and the physical object
Result HB_Physical Object Result Identifying assessment.
Physical Object This relationship links a generic
TO Physical physical object to one or more
Coverage HB_PhysicalObject coverages on a Policy
Mapping HB_Physical Object Coverage Mapping Identifying
Other Party Non- This relationship links policy to other
Roles ON Policy HB_Policy HB_Other Party Roles Identifying party roles
Policy For Policy This relationship links a policy
Peril HB_Policy HB_Policy Coverage Identifying coverage to the related policy.
This relationship links a policy
coverage to the related peril. This
Policy ON Policy could include or exclude the peril on
Coverage HB_Policy HB_Policy Peril Identifying policy
Policy ON Policy
Status HB_Policy HB_Policy Status Identifying This relates to status for a policy
Policy ON This relationship links many policies
Reinsurance HB_Reinsurance Policy with a corresponding reinsurance
Policy Mapping HB_Policy Mapg Identifying agreement
Non- This relationship links a claim to the
Policy TO Claim HB_Policy HB_Claim Identifying related policy
Policy Coverage Non- This relationship links party playing
For Driver HB_Policy Coverage HB_Driver Identifying Driver Role to Policy Coverage

Policy Coverage This relationship links a policy
ON Claim Non- coverage to the related claim
Coverage HB_Policy Coverage HB_Claim Coverage Identifying coverage
on Financial coverage to Financial Provision for
Provision HB_Policy Coverage HB_Financial Provision Identifying Premiums, Fees, etc.
ON Policy Other HB_Policy Non- coverage to the related other policy
Components HB_Policy Coverage Other_Components Identifying components
TO Physical HB_PhysicalObject coverage to Physical object for many-
Object Mapping HB_Policy Coverage Coverage Mapping Identifying to-many relationship in a Policy
Policy Coverage
TO Policy Non- This relationship links a policy
Clause HB_Policy Coverage HB_Policy Clause Identifying coverage to the related policy clause
TO Policy Non- coverage to the related policy
Dedutible HB_Policy Coverage HB_Policy Deductible Identifying deductible
Policy Coverage Non- This relationship links a policy
TO Policy Limit HB_Policy Coverage HB_Policy Limit Identifying coverage to the related policy limits
Policy
Assessment
Result ON
Policy
Assessment HB_Policy_Assessment HB_Policy_Assessment This relationship links an assessment
Result Status Result Result Status Identifying result to a status.
Watercraft ON This relationship links the result of an
Result HB_Watercraft Result Identifying assessment.
Watercraft ON This relationship links a particular
Physical Object watercraft to one or more coverages
Coverage HB_PhysicalObject Non- on a Policy
Mapping HB_Watercraft Coverage Mapping Identifying
Watercraft ON This relationship links the result of an
Result HB_Watercraft Result Identifying assessment.

4.5 Claims Model
A claim is a request by a party (Insured or other) to an insurance company for

compensation on a loss that a loss that occurred, covered by a policy. For a carrier
specializing in property and casualty, claims can involve compensation for physical
damage to property (home or auto) and liability resulting from such things as driving a car
or liability for loss of life. Claims can be based on damage you caused, or it can also be a
result of natural disasters such as earthquakes, hurricanes, floods, etc.
A claim is dependent on the terms and conditions that are defined in a policy. The
coverage component of policy provides the details for the circumstances under which a
loss will be paid. For example, in case of fire, a homeowner will be paid for the damage to
his house because he has fire coverage on property in the policy. If a mailman slips and
falls on the porch steps, the mailman will be paid for any medical expenses under liability
coverage of the homeowner policy. There is a close relationship between a claim and
policy.
Narrative
The claim area covers the major entities defined in claims management. The process
begins with an event resulting in one claim or multiple claims. Claim offers represent
multiple versions of claim details as they are being investigated and negotiated. Claim
settlement represents the financial movements as reserves and payments are being
decided. The relationship of claim coverage to policy coverage is shown as these are the
losses covered under the claim are attached to the appropriate sections of the policy.
The ACORD Data Model has a relationship between Loss Event and Loss Occurrence. A
Loss Event may be unique to a particular claim (e.g., a fender-bender) or may be
recognized by the industry as a whole (e.g., a named windstorm). The concept of a loss
occurrence is the basis of one or several claims (e.g., multiple claims may be filed for a
single loss occurrence, as when a claim is filed by each driver in a fender-bender). The
loss occurrence is characterized by a date, a location, a type, a potential cause, and the
eventual circumstances. For our model, we decided to implement a Loss Event table
which is optional (Loss Event Key is nullable FK on Claim Table), the purpose is to capture
event and occurrence information in a single entity.
NOTE: In the subject area model, we do show a relationship between Loss Event to Loss
Occurrence and Loss Occurrence to Claim for reference. This may be important for
operational system however, for Hobbit’s purposes we did not need this level of
granularity.

Losses to physical objects for both covered objects under the policy or damage to third
party objects require an evaluation of these objects. Our approach to defining physical
objects is to use the same entities instantiated for insurable objects as defined in the
Policy subject area, such as Land Vehicle, Building, Watercraft, etc. For our approach to
claim assessment which may require specialized information related to varied objects
that can be involved in a claim, we instantiated a separate table Claim Assessment.
The Claim subject area will cover topics that associate parties with claims, policies with
claims, and claim reserves and payments.

4.5.1 Claim Model Design Choices
Claim is tied to party, physical object, and policy coverage through foreign keys. A claim
pays for benefits or losses covered in a policy. Claims are validated, then the carrier may
present different offers for the claim, and once approved, the carrier makes payment to
the insured or the impacted party.
When a claim occurs, the general sequence involves:

(1) Associating the claim to the related insurance policy
(2) Determining whether the agreement includes coverage that corresponds to
the damage
(3) Determining whether the damage is covered by the applicable coverage in a
manner that will result in benefits being paid by the insurer (e.g. the damage
may be covered, but falls below the applicable deductible amount)
(4) Managing the applicable coverage as a "claim coverage" to which amounts
can be managed involving limits and/or deductibles, as well as amounts paid
or reserved and to which a status may be applied.
Eggshell Eddie was driving his Volvo with his two children, Robin and Wren. As he
proceeds through an intersection on a green light, defendant Crazy Craig runs a red
light and strikes Eggshell’s vehicle causing serious injuries to Eggshell, Robin and Wren.
After striking Eggshell’s car, Crazy’s vehicle impacts vehicle number two that was
stopped at the intersection waiting to turn left. Vehicle two was operated by Professor
Timmy Tyler. Eggshell Eddie, Robin and Wren all suffered serious injuries. Professor
Tyler suffered relatively minor injuries.
Crazy Craig was insured by Hobbit Insurance Company under a $50,000 per
person/$100,000 per accident automobile insurance policy. Crazy had no assets.
(Based on Copley, R. K. (2012). Insurer’s duties when policy limits demands involve multiple claimants.
Para. 1)
Let’s view this claim to see how it relates to the model for Hobbit and how we decided to
implement it using the ACORD Data Model as the basis.
Claim 1: Eggshell Eddie is the claimant and files a claim with Crazy Craig’s Insurance
Company (Hobbit Insurance Company).

 Claim is for Medical services to Eggshell Eddie, Robin, and Wren
 Claim is for Damage to Eggshell Eddie’s Car.
Claim 2: Professor Tyler is the second claimant and files a claim with Crazy Craig’s
Insurance Company (Hobbit Insurance Company).
 Claim is for Damage to Professor Tyler’s Car
Claim 3: Crazy Craig is the claimant and files a claim with his Insurance Company (Hobbit
Insurance Company).
 Claim is for Damages to his car, which is totaled.
Below are some of the key decisions on how we modeled the Claim subject area for
Hobbit.
Loss Event: A loss event is the base of one or several claims. We decided that we are only
going to use loss event for industry recognized events, such as named catastrophes like
hurricanes or earthquakes or pollution events. As this is not the case here, the nullable
Loss Event id on both Loss Occurrence and Claim can remain null.
Loss Occurrence: A loss occurrence is the base of one or several closely related claims.
We decided that it is not necessary to physically instantiate this table. In our scenario, we
could have three claims being generated from the one accident, but we will have an entry
in the Loss Occurrence table. However, it’s unlikely that our source systems tie these
three claims together as they could have come on different times (in in practice, one or
more of the claims may be going through another insurer). Thus, the difficulty of tying
these claims together and the limited value that can be gotten from that leads us to the
decision that we don’t need the table.
Claim: Claim is the base table to store details of claim. Policy ID is associated to Claim as
an FK in Claim.
Party Roles in Claim: Various party roles such as claimant, driver, and witness will be
associated to Claim. We decided to have Claimant as a table because there is specific
information related to this role. If there is a need to identify other parties (witness)
involved in the claim, Other Party Roles table will be used along with Party Kind Code List.
Decision on Party Role in Claim
o Witness
o Claimant
o Claim Adjuster
o Driver
o Etc.

Financial Provision: Claim reserves are set aside for future payment of incurred claims on
this policy. We are not storing information on what method is used to calculate the
reserved amount. Due to nature of severity of injuries to Eggshell Eddie’s family, Hobbit
Insurance Company may need to set aside a large amount for potential liability.
In addition, there are subrogation claims, where an insurer may pursue the party that
caused an insurance loss to the insured in an attempt to recover funds paid in the claim.
We decided this will be handled similarly to regular Claim payments and reserves, where
we can capture subrogation party and store information in the Claim Provision table.
Subrogation and Claim Reserve are Financial Transaction Types for the Claim and we
decided to use codes list to differentiate the type of transaction.
Claim Coverage: Claim coverage stores information about the policy coverage that
corresponds to the damage or loss.
Decision on Claim Component Subtypes
ACORD has modeled Claim Component subtypes for Limits, Waiting Periods, Deductibles,
etc. Unlike in the Policy area where we decided to have separate physical tables for Policy
Limit or Policy Deductibles, in the Claims area, we decided to implement claim coverage
component as just a supertype table that holds different kinds of Claims Components.
Claim Offer: Based on the damage, Hobbit may make a few offers to the claimant,
because of the learning of new information or negotiation with the parties. For example,
for Eggshell Eddie’s car, there can be an option to offer payout on the entire value of the
car since it was damaged very badly OR to offer the amount it takes to fix the car.
Claim Provision: Determining whether the damage is covered by the applicable coverage
in a manner that will result in benefits being paid by the insurer (e.g. the damage may be
covered but falls below the applicable deductible amount). Claim provision would hold all
the details of elements that are used in claim settlement. If Claim Provision results in a
reserve or a paid loss, payment amount will have details in Financial Provision table.
Claim Assessment: This table will store the assessment results (such as Professor Tyler’s
car evaluation or health exam results for Robin and Wren).
Decision on Physical Objects and Assessment
The ACORD Data Model uses a single supertype table for both the assessment result for
claim damages as well as the assessment results used in the underwriting, rating, and
pricing of the policy itself. However, we decided to separate the two. One would be for
the Policy assessment results which would store the actuarial analysis as well as condition
of physical objects in the policy. The other would be the Claim Assessment Results which
would store claim related information which could be physical objects that are covered in
the policy or physical objects that are in a claim. Information for a policy can be very

different from what is required for claim assessment. For example, for Crazy Craig
insurance policy, claim assessment can be the claim adjuster’s information on condition of
the car involved in accident that is covered under Crazy Craig policy, as well as the
conditions that affected the accident. This could also have another claim adjuster’s
information on the condition of Eggshell Eddie’s car which is NOT covered with another
carrier.
We decided to use the same tables to store physical object details (information) on each
of subtype tables. i.e. Land Vehicle, Watercraft, Building and Location. These tables are
used for Policy and Claim assessment. Claim assessment will have a Physical Object Key as
an FK on the table. The same physical object (think factory) can be on many claims over a
period.
data. We recommend usage of code lists and master reference data as one of the master
data subjects every organization needs to decide how to implement.
 Claim Component Kind Code List

 Claim Kind Code List
 Claim Offer Status Code List
 Claim Offer Status Reason Code List
 Claim Settlement Method Code List
 Claim Status Code List
4.5.2 Claim Model Entity Description
The claims section below defines the major entities involved in claims management,
beginning with an event resulting in claims. As with other major business areas, the
relationships and party roles for claims is defined for the major entities. The relationship
of coverage to claim is shown along with financial aspect related to claim settlement.

HB_Claim A claim is a request by a party to obtain compensation related to a Policy.
Claim can be created as a result of Loss Event such as catastrophe or
accident. One event may generate several claims. Claims can be associated
with other claims, each of them being related to a policy and possibly many
claim coverages.
HB_Claim_Status This represents the status of a claim.
HB_Claim_Coverage A claim coverage corresponds to a policy coverage involved in a claim as well
as the assessment of coverage and offers on the claim coverage.
HB_Claim_Coverage_Status This represents the status of a claim coverage.
HB_Claim_Provision This object handles all financial information related to the coverage
deductible and limits from the perspective of the claim with a relationship to
the corresponding coverage deductible on the policy.
A claim provision may or may not result in a corresponding entry in financial
provision if the claim has met a deductible and the claimant needs to be paid.
HB_Claim_Offer An offer can be made by a carrier to a claimant or third party in the context
of a claim. Sometimes, alternative offers are made so that the claimant has
different options to settle the claim. Each of these options is represented by a
different claim offer.
HB_Claim_Offer_Status This represents the status of a claim offer. From multiple offers, only one
offer should have the status of accepted where others are declined or
rescinded.
HB_Loss_Event Loss event is a general event that is the origin of potentially many loss
occurrences. Events like a hurricane, flood, any other disaster, are generally
the source of several loss events. It might be used for natural disaster
management or any loss event, which needs to regroup loss events and
claims under the same base. It is qualified by a range of dates, hours, and
locations.
HB_Claim_Assessment_Result The result of an evaluation based on an examination on physical objects.
HB_Claim_Assessment_Result_St This represents the assessment status of physical objects in a claim.
atus
HB_Claimant This concept is type of Party that is claimant. In context of Claim, it describes
information needed to define the profile of a claimant as related to a claim

4.5.3 Claim Model Relationships
Relationship Relationship
Parent Entity Name Child Entity Name
Name Type Relationship Definition
This relationship links a claim with
Claim ON Claim a corresponding claim coverage
Coverage HB_Claim HB_Claim Coverage Identifying component.
This relationship links one or more
claim offers to a claim to
Claim ON Claim represent the composition of a
Offer HB_Claim HB_Claim Offer Identifying claim offer.
Claim ON Claim This relationship links a claim to a
Status HB_Claim HB_Claim Status Identifying status at a point in time
Claim ON
Claimant Party Non- This relationship links a party role
Role HB_Claim HB_Claimant Identifying (Claimant) in a claim
Claim ON Other Non- This relationship links a party role
Party Roles HB_Claim HB_Other Party Roles Identifying (Other Party Roles) in a claim
Claim Coverage
ON Claim HB_Claim Coverage This relationship links a claim
Coverage Status HB_Claim Coverage Status Identifying coverage to a status.
Claim Coverage This relationship links the result of
to Claim an assessment and the physical
Assessment HB_Claim_Assessment Non- object that served as the subject
Result HB_Claim Coverage Result Identifying of the assessment.
This relationship links a claim
provision with a claim coverage.
This relationship determines how
Claim Coverage limits and deductibles are utilized
TO Claim and determine the actual claim
Provision HB_Claim Coverage HB_Claim Provision Identifying amounts
Claim Offer ON
Claim Offer This relationship links a claim
Status HB_Claim Offer HB_Claim Offer Status Identifying offer to a status.
component to a related claim
ClaimComponent component. For example, a claim
Comprises HB_Claim HB_Claim Non- deductible may be associated
ClaimComponent Other_Components Other_Components Identifying with a claim coverage.
Claim Provision provision with a financial
TO Financial Non- provision that actually hits the
Provision HB_Claim Provision HB_Financial Provision Identifying ledgers of Hobbit.
Reinsurance provision with a Reinsurance
Claim Provision Claim provision, This is when it is
ON Claim HB_Reinsurance Claim determined that claim is linked to
Provision HB_Claim Provision Provision Identifying reinsurance agreement
Claim
Assessment HB_Claim_Assessment HB_Claim_Assessment This relationship links an
Result ON Claim Result Result Status Identifying assessment result to a status.

Relationship Relationship
Parent Entity Name Child Entity Name
Assessment
Result Status
Loss Event This relationship links the claim
Originating Claim Non- with the loss evnt. A single loss
Loss HB_Loss Event HB_Claim Identifying event can have many claims.

4.6 Finance Model
Finance is a common subject area that represents the financial amounts in context of Policy
amounts (premiums, fees, etc.) or claim amounts (claim settlement/payout). This subject area
covers two subareas – financial transactions that are assets and liabilities (e.g., premiums,
commissions, taxes, fees, surcharges, claim reserves, claims paid losses, IBNR, etc.), and the cash
flow transactions (e.g., premium coming in, losses going out, invoices, write-offs, etc.).
Narrative
In an organization, the Finance function covers many aspects such as paying employees,
receiving money from revenue streams, accounting and general ledger management,
Operating expenses, Corporate Balance Sheets. For the SAM project at Hobbit, I am
interested in only considering insurance related transactions. Thus, I am interested in
underwriting revenues that come from cash collected on policy premiums and money paid out
on claims. This SAM system will not cover non-insurance related money streams – payroll,
rent, investment income, for example. To get a full picture of Hobbit’s financials, Dr. Took will
have to look at reports coming out of the General Ledger system, which may be an extension
to this project someday. Also as noted before, this system is focused on reporting results as
they were entered – it is out of scope to be able to re-create the exact logic for why a
premium was $1000 rather than $1200, or why a large claim payout was $93,000, not
$104,000. As a best practice, we do not want to recalculate any financial information coming
from the operational systems.
The Insurance Revenue streams for Hobbit Insurance are the revenues generated from
premiums paid by insureds, plus claims paid to Hobbit from Reinsurers. Monies paid out from
Hobbit would be settlement for claims and premium share for reinsurers. Essentially, these
are just the monies coming in and monies going out. (Note this includes Reserves, which have
not actually gone out yet, but are earmarked for going out). We created a Financial Provision
table for storing details about all transactions resulting from these four activities. This table
will have premium, commissions, taxes, fees, surcharges, reserves, subrogation, claim
payments amount, reinsurance payables, reinsurance receivables, etc. The ACORD Data
Model provides an option to create separate entities for Financial Provision such as Fees,
commissions, premiums, taxes, etc. These entities might be needed in an operational system,
due to the complexity of calculations and rules that need to apply at that level of granularity.
As mentioned above, our objective is to store the relevant results (we don’t need to show our
work, just the answers). We can use this supertype table that can differentiate the types of
entry using the code lists.
Even though Financial Provision is the core table, we needed other tables to store details that
are geared towards our reporting needs. The ACORD Data Model has a supertype table that

handles both insurance and reinsurance. We will physically separate these into different
tables because of several reasons: a) they have slightly different primary key structures
because of participant, b) The majority of our reporting needs are just gross reports which we
can get from just Financial Provision; we can handle net and ceded reports by viewing both
tables together, and c) the cardinality of reinsurance transactions to insurance transactions is
many to one, but with a very high standard deviation. Most “inward” transactions have zero
“outward” transactions, but very high dollar value claim transactions can have thousands of
outward claims transactions. So, we created the tables of Reinsurance Financial Provision for
details of reinsurer share of policy amounts. Similarly, we created a Reinsurance Claim
Provision table for claim amount reflecting reinsurer share amount based on the Claim
Provision table.
As opposed to asset and liability transactions above, we decided to split off the subtype tables
of Financial Transaction for all Cash Flow activities. We decided to store Payment and
Payment Due, as these are the actual payment transactions (Money Received and Money
Sent) into a single table called Financial Transaction. We did instantiate a separate table for
Payment Settlement used for reconciliation between Financial Provision and Financial
Transaction.

4.6.1 Finance Model Design Choices
Finance is a subject area consisting of financial accounting (premiums and losses) and
money transactions such as premium receipts or claim payments. The focus for the
Hobbit Data Model is to address Finance in context of Insurance related transactions
only. We will not be incorporating non-insurance General Ledger or Investment aspects
into this model.
Claim Provision: Claim provision is the place where we store ground up losses and
reserves for claim settlement. Claim Provision will store information about claim
payment as well as components such as deductible eligibility or limits applied as per the
Policy. For example, an auto policy might have a $1000 deductible and clauses around
what types of losses are covered. When the First Notice of Loss comes in, we may not
know the exact amounts of the loss or whether the investigation will show that the
coverage conditions are fully met. We may put in a placeholder row in Claim Provision
saying it is a $5000 rough loss. Later on, if we determine that half the $5000 was not
covered and that the deductible did apply, that $5000 Claim Provision may translate to a
$1500 loss in Financial Provision which is the actual amount that we pay. There may be
cases where there is no Financial Provision row because the claim amount did not
exceed the deductible or the loss was not covered at all. Claim Provision is a child entity
to Claim Coverage since actual compensation for the claim is determined by the
coverage.
Reinsurance: A reinsurance agreement is made between a ceding company (Insurer) and

a reinsurance company (reinsurer). The reinsurer shares the risk; the reinsurer receives
a portion of the premiums generated by the ceding company’s policy or portfolio. For a
claim, the reinsurer bears a portion of the losses based on ceded share percentage.
Reinsurance Claim Provision: We decided to create a Reinsurance Claim Provision table

like Claim Provision that represents the money composition based on reinsurance
agreement share. This is the reinsurer share of the loss amount based on percentage in
the agreement. This will be covered in detail in the next section.
Financial Provision: A financial provision represents a granular accounting transaction

for all types of Insurance transactions. For example, financial provision types include
premium, fees, commissions, taxes, etc. as well as claims types such as paid losses, case
reserves, and IBNR.
Reinsurance Financial Provision: We created a Reinsurance Financial Provision that

represents the reinsurers’ portions of policy premiums and losses due to Hobbit. This

captures that all money composition associated with business acquisition, which may
include any processing costs the reinsurers share. This will also be covered in detail in
the next section.
Looking at the ACORD Data Model with the large variety of subtypes on Financial
Provisions, while we decided to split the insurance and reinsurance subtypes into
different physical tables, we decided not to split the individual transactions types (e.g.,
Premium, Commissions, Paid Losses) into separate tables as nearly all reporting needs
mix those subtypes. Instead, we will have a Provision Type code list on the Financial
Provision Table. We also decided not to implement the ACORD Financial Provision
Summary, as information can be summarized using Financial Provision details as seen in
the example below.
Below is a sample of how money provision will be represented in the table

Party Party Type ID Type Type Amount
111A Insured 1001Home Policy Premium 850
111A Insured 1001Home Policy Tax 85
111A Insured 1001Home Policy Fee 50
111A Insured 2001Auto Policy Premium 500
111A Insured 2001Auto Policy Tax 50
222A Claimant CL001 Claim Claim Payment 51
111A Insured CL001 Claim Claim Reserve 1000
Decision on Financial Transaction Subtypes

Payment Transaction: The ACORD Data Model has the concept of Financial Transaction,
with separate subtypes for Money In and Money Out transactions (Payments and
Receipts). However, we decided not to implement Financial Transaction Subtypes into
separate entities. The Financial Transactions table is used to capture both. We decided
to use a Financial Transaction Kind Code List to differentiate between payments and
payments due. We also decided to use Payment Method Kind Code List for representing
how payment was made via check, cash, money order, etc. The ACORD Data Model is
very normalized, so we decided having attributes with code lists is a better design for us.
We have renamed ACORD’s Financial Transaction to Payment Transaction to better
differentiate it from Financial Provision.
Payment Settlement: From the ACORD Financial Transaction Subtypes, we implemented

a Payment Settlement concept. This is the association between what is owed to us (e.g.,
premium obligations on Financial Provisions) and what money comes in the door to
cover those obligations (checks from Payment Transaction). It also covers the inverse –

the association between money that we owe (e.g., Paid Loss amounts on Financial
Provision) and money we send out the door (e.g., claims payments on Payment
Transactions).
Here’s the relationship between Financial Provision, Payment Transaction, and Payment
Settlement.
Business Event 1 – Let’s suppose that Hobbit sells a BOP Policy to Nick’s Bagel Shoppe
that has coverage for Property and Commercial Auto, totaling $10,000, split evenly
between the two coverages. Of that $10,000, $1000 goes to Sean the Broker for
commission, $500 goes to the State of New York for a combination of taxes and fees,
and the remaining $8500 is our written premium. That would get entered as six rows in
Financial Provision (three provision types for each of two coverages, it would be more if
the policy were set up with installments).
Business Event 2 – Hobbit would then generate an invoice to Nick for the entire
$10,000. This would be a single row in Payment Transaction with a type code of Invoice
(the invoice lines behind that invoice would be the Financial Provision rows.
Business Event 3 -- Nick would then send us an EFT for $10,000. This would be a single
row in Payment Transaction with a type code of Payment.
Business Event 4 – Somebody at Hobbit would have the job function of matching the
payment to the invoice. That would create six associative rows in the Payment
Settlement table, each of which would be marked as fully paid.
Business Event 5 – In another business event three months later, elderly customer
Howard carelessly breaks the glass display container in the Shoppe by repeatedly
banging on it with his cane. Nick files an FNOL stating that he thinks it will cost $8,000
to fix. Hobbit enters a single row in Claim Provision (one coverage, one claimant, one
date, a reserve)
Business Event 6 – After investigation, it is determined that it will cost $12,000 to

replace. Nick has a $1000 deductible. This updates the row in Claim Provision from
$8,000 to $12,000, and inserts a row in Financial Provision for an $11,000 reserve.
Business Event 7 – Hobbit mails Nick a check for $11,000. This adds a negative reserve
in Financial Provision, adds a Paid Loss row in Financial Provision, creates a row in
Payment Transaction of type code “Payment”, and creates a row in Payment Settlement
linking the Payment to the Paid Loss.
Decision on Financial Scheduler Subtypes

Payment Scheduler: While Financial Provision represents the definition of the amounts
and their composition, the Payment Scheduler defines how the money will be paid,
when it will be paid, and who will pay or receive it.
Payment Invoice Header: Payment Invoice Header represents summary of money
provision elements represented in Financial Provision table and frequency from
Payment Scheduler Table. As stated above, the Payment Invoice header gets
instantiated as a row type in the Payment Transaction table. The Invoice detail is not
instantiated, as its details can be found in the money composition from Financial
Provision Table.
We have used the following code lists in our model to demonstrate usage of reference data. We
recommend usage of code lists and master reference data as one of the master data subjects
every organization needs to decide how to implement.
 Financial Provision (Financial Provision Key)

 Commission
 Fee
 Premium
 Tax
 Financial Transaction (Financial Transaction Key)
 Payment Due
 Payment
 Payment Method (Payment Method Key)
 Cash Method
 Bank Transfer Method
 Check Method
 Card Method
 Money Order Method

4.6.2 Finance Model Entity Description

HB_Financial_Provision A financial provision represents a money amount and money type. It is
comprised of such transactions as premiums, commissions, fees, claim
payments, claim reserves, taxes, etc.
HB_Reinsurance_Financial_Provision Reinsurance Financial Provision represents the reinsurer portion of policy
premiums and losses sold by the insurer. This represents the all money
composition associated with business acquisition, which may include any
processing costs reinsurer shares.
HB_Reinsurance_Claim_Provision Reinsurance Claim Provision like Claim provision represents the money
composition based on reinsurance agreement share. This is the reinsurer
share of loss based on percentage in the agreement.
HB_Claim_Provision Claim provision is the financial aspect of money composition for claim
settlement. For example, Claim Provision will store information about claim
payment as well as components such as deductible eligibility or Limits applied
as per the Policy. Based on all the elements of the composition, Claim
provision may result in a Financial Provision where money will be exchanged
to settle the claim. There may be a case where there is no Financial Provision
because the claim amount did not exceed the deductible or limits rules.
HB_Payment_Schedular While Financial Provision represent the definition of the amounts and their
composition, the money scheduler defines how the money will be paid, when
it will be paid and who will pay and receive it.
HB_Payment_Transaction A transfer of money between two parties. This represents payments made or
payments received.
HB_Payment_Invoice_Header These details are derived from the money provision element parts that are
attached to the money provisions for this money scheduler.
HB_Payment_Settlement Payment settlement represents the cash application to match payment due
from Financial Provision and Payments received from Financial Transaction.

4.6.3 Finance Model Relationships
Child Entity Relationship

Relationship Name Parent Entity Name
This relationship links reinsurance
Financial Provision HB_Reinsurance financial provision to financial
ON Reinsurance Financial provision for underwriting activities by
Financial Provision HB_Financial Provision Provision Identifying the cedent
Financial Provision This relationship links financial
ON Payment HB_Payment provision to payment settlement for
Settlement HB_Financial Provision Settlement Identifying financial
Payment Invoice
Detail for Payment HB_Payment HB_Payment Non- This relationship links Invoice Header
Invoice Header Invoice_Header Invoice_Detail Identifying to Invoice Detail
This relationship links financial
transaction to payment settlement for
Payment Invoice financial. Financial transactions are
Header for Financial HB_Payment HB_Financial Non- both money in and money out type of
Provision Invoice_Header Provision Identifying transactions.
This relationship links financial
Payment Transaction transactions to payment settlements.
for Payment HB_Payment HB_Payment Financial transactions are both money
Settlement Transaction Settlement Identifying in and money out type of transactions.
Payment Scheduler
For Payment Invoice HB_Payment This relationship links scheduler to
Header HB_Payment_Schedular Invoice_Header Identifying invoices

4.7 Reinsurance Model
The Reinsurance subject represents agreements between a Cedent and a reinsurer. The
two basic methods of reinsurance are Facultative and Treaty. Within the scope of each
of these two methods, there are two broad types - Proportional reinsurance and Non-
Proportional reinsurance.
Facultative reinsurance is a method, under which the ceding company or Cedent offers
each risk individually to the reinsurer for its consideration. The reinsurer receives full
details of each underwriting policy offered, and has the option to reject the offer or to
accept.
Treaty reinsurance is an obligation based on an agreement concluded for a specified
period covering a defined set of risks (e.g., all homes located on Cape Cod against
windstorm risks). The Cedent is obliged to cede all risks falling within the scope of the
agreement, and the reinsurer is obliged to accept all such cessions without the option to
decline or to ask for improved terms. Offer and acceptance are thus automatic.
Definition of proportional reinsurance, the Cedent and the reinsurer share the risk and
they also share the premiums and claims in a set proportion. This concept could be
applied to an individual risk (facultative) or to several risks covered by a single contract
(treaty).
Narrative
As a P&C insurer, Hobbit’s product line deals with commercial and personal property
insurance coverages for personal and commercial business. Our insurance covers losses and
damage to residence and commercial lines in the eastern part of the US and Canada, as well
as several other states elsewhere. The risk of losses due to catastrophic windstorms is much
higher on the coastline than places like Ohio. Some of the high-risk policies that are written
on the Eastern Seaboard are reinsured with other carriers.
The ACORD Data Model provides a way to model underwriting of policies, facultative and
treaty agreements. For the data warehouse project, my focus is to capture accurate data on
both inward policies and outward treaties and fac certs, as well as to keep track of all
financial transactions related to any inward or outward contracts, so that I can do Gross,
Ceded, and Net reporting at any degree. I don’t need to capture all the elaborate rules for
what criteria makes a given Hobbit policy attach or not attach to a given treaty – I will
assume that the master data about the contracts and the transactional data about the
financial results is the core to my needs.

Using the ACORD supertype concept of agreements, we separated out inward contracts
(Policy) from outward contracts (Reinsurance Agreements). We also created separate tables
to store concepts of Reinsurance Agreement and Participant Share. We also built an
associative table between inward and outward contracts to see which policy attaches to
which reinsurance agreement, and vice versa. These core concepts were then extended to
build relationships with policy management and claims management. We thus are able to
represent the Reinsurance Tower Structure, whereby a single inward policy could have its
huge losses distributed among many reinsurance contracts with different limits and
attachment types.

4.7.1 Reinsurance Model Design Choices
The concept of insurance risk means policies can exist without reinsurance and we, at
Hobbit would bear the full 100% of obligation. However, because our risks can be
correlated (for example, a Hurricane Sandy type of event would have wiped out decades
of underwriting profit if we had had to bear it without benefit of reinsurance),
reinsurance means that our risks are distributed across a wider basis. Reinsurance starts
with a simple concept where the reinsurer gets a certain amount of premium from its
Cedent (insurer) and shares in the Cedent’s risk in an agreed upon proportion or on an
agreed amount. In our Data warehouse, we are not concerned with the process of how
the reinsurance contract is created and managed on a day to day basis and how you
decide which policies are covered under an agreement. Our focus was to capture
details of the agreement that can be reported on and to know which policies and claims
are subject to reinsurance arrangement.
Bag End Brokers is a reinsurance broker to a ceding company (Hobbit Insurance). As the
Cedent’s broker, Bag End secured a reinsurance group composed of several property
and casualty reinsurers, including Rivendell Re, which has agreed to serve as the lead
reinsurer in the consortium. Other respected members of the reinsurance community
such as Lothlorien Associate, Gondor Re, and Rohan Re. The members of the
participating reinsurance companies entered into a reinsurance agreement through
which the reinsurer participants agreed to reinsure the risks covered by certain
insurance policies issued by the Cedent (insurer- Hobbit). Terms of the contract are in
the reinsurer agreement.
Decision on Reinsurance Agreement
Our focus for the reinsurance subject area was to capture the reinsurance agreement
and participant details. From the ACORD Data Model Agreement supertype, we created
a Reinsurance Agreement table to store details about the overall reinsurance contract
terms. contract with reinsuring property and casualty insurance companies that are the
reinsurers. For share of participation, Reinsurance Share was created to store either
percentage or amount of risk of all the participants. Reinsurance Share is a child table
with FKs to Reinsurance Agreement and Reinsurer (Party) for all the participants in the
agreement. In a reinsurance arrangement, there is a many-to-many relationship
between inward policies and reinsurance agreements. To accommodate this, we
created a Reinsurance Policy Mapping table that will list all the inward policies with
what outward agreements cover them, as well as all the individual policies that are in
the purview of a given outward agreement. Creating this mapping table facilitates the
below information in the Data warehouse

==> Using the existing claim to policy relationships, we will be able to derive all the
claims that are processed for policies in the reinsurance agreement
==> Once we have established the relationship of policies and claims associated to a
reinsurance agreement, financial apportionment for participating reinsuring companies
can be determined for premiums and claims (see below).
Decision on Reinsurance Financial Provision
Based on the number and total premium of all these inward policies, the Cedent
(Hobbit) would send premium to the reinsurer participants based on their share of the
risk.
The Reinsurance Financial Provision table is a child table to Reinsurance Share. To get
the premium amount, you would use Reinsurance Share’s relationship to Reinsurance
Agreement and Reinsurance Policy Mapping for policy and then policy relationship with
Financial Provision to get the amount of premium due.
Reinsurance Financial Provision will provide a detailed list of policies and amounts along
with other financial information required for payments to the reinsurers. Reinsurance
Financial Provision information would be used for premium bordereau reporting.
Decision on Reinsurance Claim Provision
Upon the Cedent’s determination that a claim loss is due under one of its reinsurance
agreements (Reinsurer, Reinsurance Share, Policy, Claim Relationship), we would ask for
payment due from the appropriate reinsurer of the claim. The Reinsurance Claim
Provision and Reinsurance Financial Provision tables are used for these generation of
statements. Details of the amounts will be determined in the same way as Reinsurance
Financial Provision was used for premiums. In addition, we could use the policy to claim
relationship to find out which claims that are covered for the agreement. As a note, any
payments received from the reinsurers will be captured in the Financial Transaction
table.

4.7.2 Reinsurance Model Entity Description

HB_Reinsurer This concept is type of Party that is a reinsurer. In the context of a
reinsurer agreement, it describes information needed to define the
profile of a reinsurer as related to an agreement.
HB_Reinsurance_Share Under proportional reinsurance, the Cedent and the reinsurer share
the risk, and they also share the premiums and claims in the same
proportion.
HB_Reinsurance_Agreement An agreement subtype that identifies the reinsured subject and the
nature of the reinsurance arrangement.
HB_Reinsurance_Agreement_ You can specify which perils are included or excluded in an agreement.
Peril For example, if the agreement was designed to cover windstorm
losses in Florida, the agreement may have a named peril for
Hurricanes include and also have earthquakes excluded
HB_Reinsurance_Policy_Mapp The Cedent and the reinsurer share the premiums and claims. An
int agreement can have many participants and there can be many policies
that reinsurers share. This is a mapping table to handle the many-to-
many relationship between the agreement and policies.
HB_Reinsurance_Claim_Provis This object handles all information related to the coverage deductible
ion from the perspective of the claim with a relationship to the
corresponding coverage deductible on the agreement.
HB_Reinsurance_Financial_Pr Reinsurance Financial Provision represents the reinsurer portion of
ovision premiums and losses. This also includes all costs associated with
business acquisition, which may include any outward commission or
processing costs.

4.7.3 Reinsurance Model Relationships
Parent Entity Child Entity Relationship

Relationship Name
This relationship links a reinsurance
Reinsurance agreement to perils. A reinsurance
Agreement for agreement is usually linked to specific
Reinsurance HB_Reinsurance HB_Reinsurance kinds of perils such as earthquakes,
Agreement Peril Agreement Agreement Peril Non-Identifying windstorms, flooding, etc.
Reinsurance
Agreement ON
Reinsurance Policy HB_Reinsurance HB_Reinsurance This relationship links many reinsurance
Mapping Agreement Policy Mapping Identifying agreements with a corresponding policy.
Reinsurance This relationship links a reinsurance
Agreement TO HB_Reinsurance HB_Reinsurance share for participants to a related
Reinsurance Share Agreement Share Identifying reinsurance agreement.
share for participants to a related
Reinsurance Share HB_Reinsurance reinsurance financial provision. This will
ON Reinsurance HB_Reinsurance Financial be the share of underwriting activity for
Financial Provision Share Provision Identifying a given reinsurer
share for participants to a related
Reinsurer Share ON reinsurance claim provision. This will be
Reinsurance Claim HB_Reinsurance HB_Reinsurance the share of claim loss activity for a given
Provision Share Claim Provision Identifying reinsurer
Reinsurer ON HB_Reinsurance This relationship links party role
Reinsurer Share HB_Reinsurer Share Non-Identifying (reinsurer) to the reinsurance agreement

5 Data Definition Language (DDL) Script
Applying the above discussed strategy, we have created the relational model in both DDL
and in the erwin data model format. We have used data types specific to SQL Server, so if
you are using another DBMS, there would be an equivalent. DDL Script is provided in a
separate document.
DDL script
CREATE TABLE [HB_Aircraft]

(
[Aircraft_Type_Code_List] [Aircraft_Type_Code_List] ,
[Aircraft_Storage_Type_Code_List] [Aircraft_Storage_Type_Code_List] ,
[Airport_Type_Code_List] [Airport_Type_Code_List] ,
[Aircraft_Key] [00_Entity_Key] NOT NULL ,
[Physical_Object_Key] [00_Entity_Key] NOT NULL ,
[Physical_Object_Kind] [Physical_Object_Kind_Code_List]
)
go
ALTER TABLE [HB_Aircraft]

ADD CONSTRAINT [XPKHB_Aircraft] PRIMARY KEY CLUSTERED ([Aircraft_Key]
ASC,[Physical_Object_Key] ASC)
go
CREATE TABLE [HB_Broker]

(
[Broker_Kind] [Party_Kind_Code_List] ,
[Broker_Kind_Code_List] [Party_Kind_Code_List] ,
[Broker_Name] char(18) NULL ,
[Organization_Name] char(18) NULL ,
[Broker_Key.Party_Key] [00_Entity_Key] NOT NULL
)
go
ALTER TABLE [HB_Broker]

ADD CONSTRAINT [XPKHB_Broker] PRIMARY KEY CLUSTERED ([Broker_Key.Party_Key]
ASC)
go

6 Conclusion
In this paper, we have discussed the method of applying the ACORD Data Model structures to
create a data store for the Hobbit Insurance company. This will be used to build their first-
generation data warehouse. We introduced the benefits of using the ACORD Data Model for
database modeling and gave a short review of approaches to important aspects of subject areas
covered in this review.
A case study of applying this approach for modeling Property and Casualty line of business for
an insurance system was given. A practical strategy for transforming ACORD’s conceptual highly
normalized model into a business specific physical model was presented for the use case.
We also indicated the most important task is to validate the interpretation and transformation
of the ACORD model. This effort is lengthy; a designer needs to evaluate and make decisions
entity by entity and relationship by relationship using real-life business scenarios for their
organization.
However, each organization must determine their approach to meet their needs and
requirements. This document is designed to provide guidance and suggestions for assisting
implementers in this process.
We have presented the details of the data model and following supporting information as
separate documents
 Erwin Data Model elements
 DDL scripts for Hobbit Data Model
 PDF of Data Model Diagrams
 PDF of ACORD Code List Values (
NOTE: Code List Names are provided in the erwin Model. However,
this report provides the enumeration values in the ACORD Data
Model.
Implementable Data Model

For organizations wanting to see the implementation of this Data Model, major data
entities can be implemented as represented in this document.

Hobbit Insurance Data Model Case Study

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hobbit Insurance Data Model Case Study

Uploaded by

Copyright:

Available Formats

Hobbit Insurance

Insurance for the Little Guy

ALL RIGHTS RESERVED

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 0

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 1

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 2

1.1 A Case Study: HOBBIT INSURANCE

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 3

Hobbit’s CEO, Dr. Peregrine Took, has stated that he

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 4

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 5

 Based upon a comprehensive enterprise model

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 6

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 7

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 8

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 9

Object Definition and Conversion Considerations

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 10

Figure 2.0: Basic Entity Definition: Entity, Attributes, and Relationships.

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 11

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 12

Figure 2.2 Identifying Relationship

 An identifying relationship is when the existence of a row in a child table absolutely

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 13

Figure 2.3: Associative Entities

2.2 Mapping Concepts (Enterprise to Application)

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 14

 Business Concept Entities

Figure 3.0: ACORD Data Model (Conceptual Model)

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 15

Figure 3.1: Hobbit Insurance Data Model (Conceptual Model)

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 16

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 17

Property and Casualty Insurance Enterprise Logical Data Model

Figure 3.2: Entity Relationship Model

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 18

Figure 3.3: Entity Relationship Model-Claim Entities

3.1.1.1 Definitions of Data Model Subject Areas

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 19

 Policy (Agreement) is a focal point for all insurance / reinsurance or financial

 Finance is a common entity consisting of financial accounting and money

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 20

 Reinsurance can optionally be used for any insurance agreements. Reinsurance

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 21

4.2 Party Model

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 22

4.2.1.1 Implement Subtypes (Evaluate Children Table)

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 23

4.2.1.2 Implement Enumeration Values (Evaluate Code Lists)

 Company Status Code List

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 24

Table Name Definition

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 25

Relationship Parent Entity Relationship

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 26

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 27

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 28

4.3.1 Product Specification Model Design Choices

2020 ACORD CORPORATION – ALL RIGHTS RESERVED Page 29

 Product Component Specification – provides a design reference of options and

 Deductibles Specifications is a child entity to the Product Specification as well as to

 Limit Specifications is a child entity to product specification as well as to Coverage