<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Property &amp;amp; Casualty Insurance Lakehouse in Community Articles</title>
    <link>https://community.databricks.com/t5/community-articles/property-amp-casualty-insurance-lakehouse/m-p/169210#M1581</link>
    <description>&lt;P&gt;When building a Property &amp;amp; Casualty Insurance Lakehouse, one of the first things to understand is:&lt;/P&gt;&lt;P&gt;A Claim is not just a Claim Amount.&lt;/P&gt;&lt;P&gt;Consider a simple auto claim.&lt;/P&gt;&lt;P&gt;At different points in the lifecycle, the same claim might have:&lt;/P&gt;&lt;P&gt;Indemnity Reserve = $15,000&lt;BR /&gt;Medical Reserve = $8,000&lt;BR /&gt;Legal/Defense Reserve = $4,000&lt;/P&gt;&lt;P&gt;Then actual payments start:&lt;/P&gt;&lt;P&gt;Indemnity Paid = $10,000&lt;BR /&gt;Medical Paid = $3,000&lt;BR /&gt;Legal Expense Paid = $1,500&lt;/P&gt;&lt;P&gt;And later the carrier may recover:&lt;/P&gt;&lt;P&gt;Subrogation Recovery = $6,000&lt;BR /&gt;Salvage Recovery = $1,000&lt;/P&gt;&lt;P&gt;This is where the data modeling becomes interesting.&lt;/P&gt;&lt;P&gt;If our Lakehouse has only:&lt;/P&gt;&lt;P&gt;claim_id | claim_amount&lt;/P&gt;&lt;P&gt;we have already lost much of the business context.&lt;/P&gt;&lt;P&gt;Instead, the model needs to preserve the relationship between:&lt;/P&gt;&lt;P&gt;Policy&lt;BR /&gt;→ Policy Term&lt;BR /&gt;→ Coverage&lt;BR /&gt;→ Insured Risk&lt;BR /&gt;→ Claim&lt;BR /&gt;→ Claim Exposure&lt;BR /&gt;→ Claim Financials&lt;/P&gt;&lt;P&gt;And Claim Financials themselves need to distinguish:&lt;/P&gt;&lt;P&gt;Reserve&lt;BR /&gt;Payment&lt;BR /&gt;Expense&lt;BR /&gt;Recovery&lt;/P&gt;&lt;P&gt;with additional classifications such as indemnity, medical, legal, subrogation and salvage.&lt;/P&gt;&lt;P&gt;Why does this matter?&lt;/P&gt;&lt;P&gt;Because the Lakehouse should eventually be able to answer questions such as:&lt;/P&gt;&lt;P&gt;What is the outstanding reserve?&lt;/P&gt;&lt;P&gt;How much has actually been paid?&lt;/P&gt;&lt;P&gt;How much of the loss is indemnity vs expense?&lt;/P&gt;&lt;P&gt;How much has been recovered through subrogation?&lt;/P&gt;&lt;P&gt;What was the applicable coverage when the loss occurred?&lt;/P&gt;&lt;P&gt;What is the incurred loss at a given point in time?&lt;/P&gt;&lt;P&gt;What is the loss ratio by coverage, risk, geography or line of business?&lt;/P&gt;&lt;P&gt;This is why I find industry data models interesting.&lt;/P&gt;&lt;P&gt;The value isn't simply having hundreds of tables.&lt;/P&gt;&lt;P&gt;The value is preserving the business grain and relationships so that downstream analytics can reconstruct what actually happened.&lt;/P&gt;&lt;P&gt;In Part 2 of my exploration of Databricks Lakehouse Industry Data Models, I went deeper into what a P&amp;amp;C Insurance reference architecture could look like — from Party, Submission and Policy through Coverage, Risk, Premium, Claims, Claim Financials, Reinsurance and Catastrophe.&lt;/P&gt;&lt;P&gt;Full article:&lt;/P&gt;&lt;P&gt;&lt;A href="https://dataengineeringcopilot.com/blog/databricks-pc-insurance-data-model" target="_blank"&gt;https://dataengineeringcopilot.com/blog/databricks-pc-insurance-data-model&lt;/A&gt;&lt;/P&gt;&lt;P&gt;My next step is to take this from architecture to implementation.&lt;/P&gt;&lt;P&gt;I want to build a small P&amp;amp;C Lakehouse on Databricks:&lt;/P&gt;&lt;P&gt;Bronze → raw policy, claim and financial transactions&lt;/P&gt;&lt;P&gt;Silver → standardized policy, coverage, claim exposure, reserve, payment and recovery data&lt;/P&gt;&lt;P&gt;Gold → Policy 360, Claim 360 and insurance KPIs such as paid loss, outstanding reserve, incurred loss and loss ratio&lt;/P&gt;&lt;P&gt;That is where an industry data model becomes much more than an ER diagram.&lt;/P&gt;&lt;P&gt;It becomes the semantic foundation of the Lakehouse.&lt;/P&gt;&lt;P&gt;#Databricks #Lakehouse #DataEngineering #Insurance #PropertyAndCasualty #DataModeling #DeltaLake #Claims #DataArchitecture&lt;/P&gt;</description>
    <pubDate>Sun, 20 Sep 2026 03:42:47 GMT</pubDate>
    <dc:creator>AmitDECopilot</dc:creator>
    <dc:date>2026-09-20T03:42:47Z</dc:date>
    <item>
      <title>Property &amp; Casualty Insurance Lakehouse</title>
      <link>https://community.databricks.com/t5/community-articles/property-amp-casualty-insurance-lakehouse/m-p/169210#M1581</link>
      <description>&lt;P&gt;When building a Property &amp;amp; Casualty Insurance Lakehouse, one of the first things to understand is:&lt;/P&gt;&lt;P&gt;A Claim is not just a Claim Amount.&lt;/P&gt;&lt;P&gt;Consider a simple auto claim.&lt;/P&gt;&lt;P&gt;At different points in the lifecycle, the same claim might have:&lt;/P&gt;&lt;P&gt;Indemnity Reserve = $15,000&lt;BR /&gt;Medical Reserve = $8,000&lt;BR /&gt;Legal/Defense Reserve = $4,000&lt;/P&gt;&lt;P&gt;Then actual payments start:&lt;/P&gt;&lt;P&gt;Indemnity Paid = $10,000&lt;BR /&gt;Medical Paid = $3,000&lt;BR /&gt;Legal Expense Paid = $1,500&lt;/P&gt;&lt;P&gt;And later the carrier may recover:&lt;/P&gt;&lt;P&gt;Subrogation Recovery = $6,000&lt;BR /&gt;Salvage Recovery = $1,000&lt;/P&gt;&lt;P&gt;This is where the data modeling becomes interesting.&lt;/P&gt;&lt;P&gt;If our Lakehouse has only:&lt;/P&gt;&lt;P&gt;claim_id | claim_amount&lt;/P&gt;&lt;P&gt;we have already lost much of the business context.&lt;/P&gt;&lt;P&gt;Instead, the model needs to preserve the relationship between:&lt;/P&gt;&lt;P&gt;Policy&lt;BR /&gt;→ Policy Term&lt;BR /&gt;→ Coverage&lt;BR /&gt;→ Insured Risk&lt;BR /&gt;→ Claim&lt;BR /&gt;→ Claim Exposure&lt;BR /&gt;→ Claim Financials&lt;/P&gt;&lt;P&gt;And Claim Financials themselves need to distinguish:&lt;/P&gt;&lt;P&gt;Reserve&lt;BR /&gt;Payment&lt;BR /&gt;Expense&lt;BR /&gt;Recovery&lt;/P&gt;&lt;P&gt;with additional classifications such as indemnity, medical, legal, subrogation and salvage.&lt;/P&gt;&lt;P&gt;Why does this matter?&lt;/P&gt;&lt;P&gt;Because the Lakehouse should eventually be able to answer questions such as:&lt;/P&gt;&lt;P&gt;What is the outstanding reserve?&lt;/P&gt;&lt;P&gt;How much has actually been paid?&lt;/P&gt;&lt;P&gt;How much of the loss is indemnity vs expense?&lt;/P&gt;&lt;P&gt;How much has been recovered through subrogation?&lt;/P&gt;&lt;P&gt;What was the applicable coverage when the loss occurred?&lt;/P&gt;&lt;P&gt;What is the incurred loss at a given point in time?&lt;/P&gt;&lt;P&gt;What is the loss ratio by coverage, risk, geography or line of business?&lt;/P&gt;&lt;P&gt;This is why I find industry data models interesting.&lt;/P&gt;&lt;P&gt;The value isn't simply having hundreds of tables.&lt;/P&gt;&lt;P&gt;The value is preserving the business grain and relationships so that downstream analytics can reconstruct what actually happened.&lt;/P&gt;&lt;P&gt;In Part 2 of my exploration of Databricks Lakehouse Industry Data Models, I went deeper into what a P&amp;amp;C Insurance reference architecture could look like — from Party, Submission and Policy through Coverage, Risk, Premium, Claims, Claim Financials, Reinsurance and Catastrophe.&lt;/P&gt;&lt;P&gt;Full article:&lt;/P&gt;&lt;P&gt;&lt;A href="https://dataengineeringcopilot.com/blog/databricks-pc-insurance-data-model" target="_blank"&gt;https://dataengineeringcopilot.com/blog/databricks-pc-insurance-data-model&lt;/A&gt;&lt;/P&gt;&lt;P&gt;My next step is to take this from architecture to implementation.&lt;/P&gt;&lt;P&gt;I want to build a small P&amp;amp;C Lakehouse on Databricks:&lt;/P&gt;&lt;P&gt;Bronze → raw policy, claim and financial transactions&lt;/P&gt;&lt;P&gt;Silver → standardized policy, coverage, claim exposure, reserve, payment and recovery data&lt;/P&gt;&lt;P&gt;Gold → Policy 360, Claim 360 and insurance KPIs such as paid loss, outstanding reserve, incurred loss and loss ratio&lt;/P&gt;&lt;P&gt;That is where an industry data model becomes much more than an ER diagram.&lt;/P&gt;&lt;P&gt;It becomes the semantic foundation of the Lakehouse.&lt;/P&gt;&lt;P&gt;#Databricks #Lakehouse #DataEngineering #Insurance #PropertyAndCasualty #DataModeling #DeltaLake #Claims #DataArchitecture&lt;/P&gt;</description>
      <pubDate>Sun, 20 Sep 2026 03:42:47 GMT</pubDate>
      <guid>https://community.databricks.com/t5/community-articles/property-amp-casualty-insurance-lakehouse/m-p/169210#M1581</guid>
      <dc:creator>AmitDECopilot</dc:creator>
      <dc:date>2026-09-20T03:42:47Z</dc:date>
    </item>
  </channel>
</rss>

