Apache Superset for General Insurers: Claims Triangles, Loss Ratios, GWP Dashboards

Table of Contents

1. Why General Insurers Need Apache Superset
2. Understanding Claims Triangles and Loss Development
3. Building Loss Ratio Dashboards in Superset
4. Gross Written Premium (GWP) Analytics and Tracking
5. Real-World Deployment: D23.io Managed Stack Architecture
6. Agentic AI Integration for Self-Service Analytics
7. Performance Optimisation and Scaling
8. Security, Compliance, and Audit-Readiness
9. Implementation Timeline and Next Steps

---

Why General Insurers Need Apache Superset

General insurance is a data-intensive business. Every claim filed, every policy issued, and every loss event generates data that shapes underwriting decisions, reserve adequacy, and profitability. Yet most insurers still rely on legacy reporting tools—spreadsheets, custom SQL queries, or expensive vendor platforms—that slow down decision-making and lock analytics into IT silos.

Apache Superset changes that. It’s a fast, lightweight, open-source data visualisation platform purpose-built for business users and data engineers. Unlike traditional BI tools that require months to deploy and thousands in licensing fees, Superset runs on commodity infrastructure, integrates with any data warehouse, and lets non-technical users build dashboards in hours, not weeks.

For general insurers, this matters because:

Speed to insight. Claims triangles—the foundational tool for loss reserving—must be updated monthly or quarterly. Superset dashboards refresh in seconds, not days. When a large claim develops unexpectedly, your actuaries and underwriters see it immediately.

Cost efficiency. You avoid per-seat licensing fees. One deployment serves 50 users or 500. At $50K for a complete rollout (architecture, SSO, semantic layer, dashboards, and training), Superset costs less than a year of Tableau or Qlik licenses.

Flexibility. Claims triangles, loss ratios, GWP trends, frequency-severity analysis, reserve adequacy—Superset handles all of it. You’re not constrained by vendor templates; you build exactly what your business needs.

Compliance readiness. Superset integrates with SSO (SAML, LDAP, OAuth), supports audit logging, and runs on secure infrastructure. When you’re preparing for SOC 2 or ISO 27001 audits, Superset dashboards are transparent, traceable, and auditable—unlike shadow analytics in spreadsheets.

At PADISO, we’ve deployed Apache Superset for Australian general insurers covering claims development triangles, loss ratios by class, and GWP analytics on D23.io’s managed stack. The result: actuaries get real-time visibility into loss development without waiting for IT reports, underwriters make faster pricing decisions based on current loss experience, and CFOs have confidence in reserve adequacy.

Let’s walk through how to build this capability for your insurer.

---

Understanding Claims Triangles and Loss Development

What Are Claims Triangles?

A claims triangle—also called a loss triangle or development triangle—is the foundational analytical structure in general insurance reserving. It shows how claims from a given underwriting year develop over time, revealing patterns in claim frequency, severity, and settlement speed.

Here’s the basic structure:

• Rows represent underwriting years (2019, 2020, 2021, etc.)
• Columns represent development periods (months or years since underwriting, e.g., 0–12 months, 12–24 months, etc.)
• Cells contain cumulative incurred losses, paid losses, or claim counts

For example, a 10×10 claims triangle for a general insurer might show:

Underwriting Year	12 Months	24 Months	36 Months	48 Months	…	120 Months
2014	$5.2M	$7.1M	$8.3M	$8.9M	…	$9.4M
2015	$4.8M	$6.5M	$7.6M	$8.2M	…	$8.7M
2016	$5.5M	$7.3M	$8.5M	$9.1M	…	—
2017	$6.1M	$8.2M	$9.4M	—	…	—
…	…	…	…	…	…	—

Actuaries use this triangle to:

1. Calculate development factors (link ratios) showing how claims evolve from one period to the next
2. Project future development for open underwriting years
3. Estimate total incurred losses and adequacy of reserves
4. Identify trends in claim inflation, settlement patterns, or emerging exposures

For a deeper understanding of claims triangles and link ratios, Sparkco’s guide provides detailed actuarial context. The Casualty Actuarial Society also publishes a comprehensive tutorial that covers the mechanics of claims triangle construction and development factor calculation.

Why Dashboards Matter for Claims Triangles

Traditionally, claims triangles live in Excel or in actuarial software (like Emblem or Prophet). They’re updated quarterly or annually, then printed or emailed as PDFs. This creates friction:

• Underwriters can’t see current loss development without asking actuaries
• Claims managers don’t know if their claims are developing faster than expected
• Finance can’t track reserve adequacy in real-time
• Auditors must request historical triangles; they can’t explore trends interactively

Apache Superset solves this by making claims triangles live, interactive, and accessible. Your actuaries load data into your data warehouse (Snowflake, BigQuery, PostgreSQL—any SQL database), and Superset builds dashboards that update automatically. Non-actuaries can filter by line of business, accident year, or development period without touching SQL.

Building Your First Claims Triangle in Superset

To build a claims triangle dashboard in Superset, you need:

1. Data structure: A table with columns for underwriting_year, development_period, incurred_loss, paid_loss, claim_count, line_of_business, etc.
2. Semantic layer: A Superset dataset that defines how these columns relate (e.g., “development_period” is a time dimension)
3. Visualisation: A heatmap or table chart showing the triangle, with drill-down to underlying claims

For example, a simple SQL query might look like:

SELECT
  underwriting_year,
  development_months,
  line_of_business,
  SUM(incurred_loss) AS total_incurred,
  SUM(paid_loss) AS total_paid,
  COUNT(claim_id) AS claim_count
FROM claims_data
WHERE underwriting_year >= 2019
GROUP BY underwriting_year, development_months, line_of_business
ORDER BY underwriting_year DESC, development_months ASC

Superset wraps this in a dataset, then lets you create a table chart (pivot on underwriting_year, show development_months as columns, incurred_loss as values). Add filters for line_of_business, date range, and minimum claim count, and you’ve got an interactive claims triangle that updates daily.

For insurers using D23.io’s managed Superset stack (which we deploy for Australian general insurers), this process takes 2–3 days, not weeks. The infrastructure is pre-configured, SSO is integrated, and the semantic layer is templated for common insurance metrics.

---

Building Loss Ratio Dashboards in Superset

Loss Ratios: The Core Underwriting Metric

A loss ratio is the percentage of premium that’s paid out in claims:

Loss Ratio = Incurred Losses / Earned Premium

For example, if a line of business earned $10M in premium and incurred $7M in losses, the loss ratio is 70%. This single metric drives underwriting decisions: if loss ratios trend above 75%, you tighten underwriting criteria or raise rates. If they’re below 60%, you’re likely underpriced.

Loss ratios vary by:

• Line of business (workers’ comp, public liability, property, motor)
• Class (e.g., within workers’ comp: construction vs. office workers)
• Territory (state, postcode, or region)
• Underwriting year (newer policies may not be fully developed)
• Development period (loss ratios change as claims develop)

Unlike claims triangles, which focus on historical development, loss ratio dashboards are forward-looking and tactical. Underwriters use them daily to monitor current year performance and spot deterioration early.

Designing a Loss Ratio Dashboard

A production loss ratio dashboard in Superset typically includes:

1. Summary metrics (top-left cards): YTD loss ratio, prior year comparison, trend (up/down/flat)
2. Loss ratio by line of business (bar chart): Horizontal bars showing loss ratio for each line, colour-coded (green <60%, yellow 60–75%, red >75%)
3. Loss ratio by class (drill-down table): Click a line of business to see loss ratios for each class within it
4. Loss ratio trend (line chart): Monthly or quarterly loss ratio for the current year vs. prior year
5. Earned premium and incurred losses (waterfall or area chart): Show the components driving loss ratio changes
6. Territory or underwriter breakdown (heatmap): Loss ratios by state, postcode, or underwriter to spot geographic or human bias

Here’s a sample SQL query for a loss ratio by line of business:

SELECT
  line_of_business,
  YEAR(policy_effective_date) AS underwriting_year,
  SUM(earned_premium) AS earned_premium,
  SUM(incurred_loss) AS incurred_loss,
  ROUND(100.0 * SUM(incurred_loss) / SUM(earned_premium), 1) AS loss_ratio_pct
FROM policies
WHERE policy_effective_date >= DATE_SUB(CURDATE(), INTERVAL 2 YEAR)
GROUP BY line_of_business, underwriting_year
ORDER BY underwriting_year DESC, loss_ratio_pct DESC

In Superset, you’d create a dataset from this query, then build:

• A bar chart (line_of_business on Y-axis, loss_ratio_pct on X-axis, colour by whether it’s >75%)
• A filter for underwriting_year so users can compare years
• A drill-down to a detail table showing loss ratio by class within each line

Real-Time Loss Ratio Monitoring

One of Superset’s strengths is that dashboards refresh on a schedule you define. For loss ratios, we typically recommend:

• Daily refresh for current underwriting year (to catch emerging trends)
• Weekly refresh for prior years (less volatile, less frequent updates needed)
• Monthly refresh for fully developed years (historical reference)

This means your underwriters check the dashboard each morning and see yesterday’s loss ratio data. If a class has spiked above 80%, they investigate claims, review underwriting criteria, or escalate to the underwriting manager. This real-time feedback loop is impossible with quarterly reports.

For Australian general insurers deploying Superset on D23.io, we configure this refresh schedule as part of the initial setup. The D23.io consulting engagement includes pre-built loss ratio templates, so you’re not starting from scratch.

---

Gross Written Premium (GWP) Analytics and Tracking

Why GWP Matters

Gross Written Premium (GWP) is the total premium written by your insurer in a given period, before reinsurance cessions. It’s the top-line metric for business growth and the denominator for loss ratios, combined ratios, and most other underwriting KPIs.

GWP analysis answers questions like:

• How much premium did we write this year vs. last year? (Growth rate)
• Which lines of business are growing fastest? (Portfolio mix)
• Which territories or classes are driving growth? (Geographic or product focus)
• Is premium growth outpacing loss ratio deterioration? (Profitability)
• Are we on track to hit annual GWP targets? (Forecast accuracy)

Unlike claims (which are backward-looking and slow to develop), GWP is real-time and actionable. Every policy issued adds to GWP immediately, so dashboards can show current-year performance with no lag.

Building a GWP Dashboard in Superset

A comprehensive GWP dashboard typically includes:

1. YTD GWP (large metric card): Total GWP written year-to-date, with prior-year comparison and % change
2. GWP trend (line chart): Daily or weekly GWP cumulative (running total), with prior-year overlay
3. GWP by line of business (stacked bar chart): Monthly GWP for each line, showing mix shift
4. GWP by territory (map or heatmap): GWP by state or region, colour-coded by growth rate
5. GWP by underwriter (leaderboard table): GWP written by each underwriter, ranked
6. GWP vs. target (bullet chart or waterfall): Actual vs. budget for each line of business
7. Average premium per policy (line chart): Trend showing whether premium inflation or volume growth is driving GWP

Here’s a sample SQL query for GWP trend:

SELECT
  DATE_TRUNC(policy_effective_date, MONTH) AS policy_month,
  line_of_business,
  SUM(written_premium) AS monthly_gwp,
  SUM(SUM(written_premium)) OVER (
    PARTITION BY line_of_business
    ORDER BY DATE_TRUNC(policy_effective_date, MONTH)
  ) AS cumulative_gwp
FROM policies
WHERE YEAR(policy_effective_date) IN (YEAR(CURDATE()), YEAR(CURDATE()) - 1)
GROUP BY policy_month, line_of_business
ORDER BY policy_month DESC, line_of_business

In Superset, create a dataset from this query, then build a line chart with:

• X-axis: policy_month
• Y-axis: cumulative_gwp
• Colour: line_of_business
• Add a filter to show only current and prior year

The result is an interactive chart where users can hover over any point to see exact GWP, click a line to isolate it, or filter by line of business. Non-technical underwriters and product managers can explore this without SQL.

Forecasting GWP and Tracking to Target

Many insurers set annual GWP targets by line of business. Superset dashboards can show progress toward these targets in real-time.

Add a table to your dashboard with columns:

Line of Business	YTD GWP	Annual Target	% to Target	Days Remaining	Implied Annual GWP	On Track?
Workers’ Comp	$12.5M	$20M	62.5%	180	$18.2M	⚠️ Behind
Public Liability	$8.3M	$15M	55.3%	180	$12.1M	⚠️ Behind
Property	$6.1M	$12M	50.8%	180	$8.9M	⚠️ Behind

This requires a simple SQL calculation:

SELECT
  line_of_business,
  SUM(written_premium) AS ytd_gwp,
  (SELECT annual_target FROM gwp_targets WHERE line_of_business = policies.line_of_business) AS annual_target,
  ROUND(100.0 * SUM(written_premium) / (SELECT annual_target FROM gwp_targets WHERE line_of_business = policies.line_of_business), 1) AS pct_to_target,
  DATEDIFF(DAY, CURDATE(), DATE_ADD(YEAR(CURDATE()), YEAR, 1)) AS days_remaining
FROM policies
WHERE YEAR(policy_effective_date) = YEAR(CURDATE())
GROUP BY line_of_business

Superset renders this as an interactive table. Users can sort by ”% to Target” to see which lines are on track and which need attention. Underwriting managers use this daily to manage portfolio growth and adjust sales targets.

---

Real-World Deployment: D23.io Managed Stack Architecture

Why D23.io?

D23.io is a managed data platform built on Apache Superset, optimised for Australian businesses. It handles infrastructure, upgrades, and security so you focus on analytics. For general insurers, D23.io offers:

• Pre-built insurance templates: Claims triangles, loss ratios, GWP dashboards ready to configure
• Semantic layer: Insurance-specific dimensions (underwriting year, development period, line of business) pre-configured
• Managed Superset: Hosted Superset with automatic updates, backups, and security patches
• SSO integration: SAML or LDAP so users log in with corporate credentials
• Audit logging: Every dashboard view, every query logged for compliance

At PADISO, we’ve deployed D23.io for Australian general insurers covering claims development triangles, loss ratios by class, and GWP analytics. A typical engagement includes:

1. Data warehouse setup: Connect your claims database (Snowflake, BigQuery, or on-premises PostgreSQL)
2. ETL pipeline: Load claims, policy, and premium data daily
3. Semantic layer: Define datasets for claims triangles, loss ratios, GWP
4. Dashboard templates: Build 5–10 production dashboards
5. SSO and RBAC: Configure single sign-on and role-based access (actuaries see all data; underwriters see only their line of business)
6. Training: Teach business users to create and modify dashboards

The D23.io consulting engagement is a fixed-fee $50K engagement delivering all of this in 6 weeks.

Architecture Overview

Here’s how D23.io works for a general insurer:

Claims Database (Snowflake/BigQuery)
         ↓
    ETL Pipeline (dbt or Airflow)
         ↓
Data Warehouse (fact tables: claims, policies, premiums)
         ↓
Apache Superset (D23.io managed)
         ↓
User Dashboards (claims triangles, loss ratios, GWP)
         ↓
Audit Log (every query, every view)

Your claims data flows into a cloud data warehouse (Snowflake is common for Australian insurers). An ETL pipeline (dbt or Airflow) transforms raw claims into analytical tables: claims by underwriting year and development period, premium by line and class, etc. Superset connects to these tables via SQL, builds datasets, and renders dashboards.

Users log in via SSO (SAML or LDAP), see only dashboards they’re authorised to view, and interact with live data. Every action is logged: who viewed which dashboard, what filters they applied, when they exported data. This audit trail is critical for SOC 2 and ISO 27001 compliance.

Data Warehouse Schema for Insurance

For claims triangles and loss ratios, your data warehouse needs these core tables:

claims (fact table)

• claim_id, policy_id, accident_date, report_date, close_date
• underwriting_year, development_month (calculated from accident and report dates)
• incurred_loss, paid_loss, reserve, claim_status
• line_of_business, class, territory, underwriter_id

policies (dimension table)

• policy_id, policy_effective_date, policy_expiry_date
• written_premium, earned_premium (calculated pro-rata)
• line_of_business, class, territory, underwriter_id, customer_id

triangles (aggregate table, optional but recommended)

• underwriting_year, development_month
• line_of_business, class
• cumulative_incurred, cumulative_paid, claim_count
• (Pre-aggregated for faster dashboard queries)

Superset queries these tables to build claims triangles and loss ratios. For large insurers (millions of claims), we recommend pre-aggregating into a triangles table to keep dashboard queries fast.

Performance and Scalability

The Data Engineer’s Guide to Lightning-Fast Apache Superset Dashboards covers optimisation techniques:

• Materialized views: Pre-aggregate claims triangles in your data warehouse
• Caching: Superset caches query results for 1 hour (configurable)
• Indexing: Index claims tables on underwriting_year, development_month, line_of_business
• Partitioning: Partition large tables by year to prune unnecessary data
• Semantic layer: Use Superset’s semantic layer to define reusable dimensions (e.g., “development_month” is always calculated from accident and report dates)

For Australian general insurers, D23.io’s managed stack handles most of this automatically. You provide raw data; the platform optimises queries and caching.

---

Agentic AI Integration for Self-Service Analytics

The Problem with Traditional Dashboards

Even the best dashboards have limits. An actuary wants to know: “What’s the average claim development for workers’ comp in Queensland, by accident year, for claims over $50K?” A dashboard might have filters for line of business, territory, and development period, but not for claim size. The actuary either:

1. Asks a data analyst to run a custom query (slow)
2. Downloads the data and analyses it in Excel (error-prone)
3. Gives up and makes a decision with incomplete information (risky)

Agentic AI solves this by letting users query dashboards in natural language. Instead of clicking filters, they ask: “Show me average claim development for workers’ comp in Queensland, by accident year, for claims over $50K.” An AI agent (like Claude or GPT-4) understands the question, constructs the right SQL query, and returns the answer.

How Agentic AI Works with Superset

Agentic AI + Apache Superset: Letting Claude Query Your Dashboards explains the integration. Here’s the flow:

1. User asks a question (natural language): “What’s the loss ratio for public liability in NSW this year?”
2. AI agent receives the question and context (available tables, columns, filters)
3. Agent constructs SQL: SELECT line_of_business, territory, SUM(incurred_loss) / SUM(earned_premium) AS loss_ratio FROM policies WHERE line_of_business = 'Public Liability' AND territory = 'NSW' AND YEAR(policy_effective_date) = 2024
4. Superset executes the query and returns results
5. Agent formats the answer: “Public Liability in NSW has a loss ratio of 72% this year, up from 68% last year.”
6. User gets instant insight without writing SQL or clicking dashboards

For general insurers, this is transformative. Actuaries, underwriters, and claims managers can explore data at their own pace without bottlenecking through data analysts. Questions that used to take hours (custom SQL query, data export, analysis) now take seconds.

Implementing Agentic AI for Insurance Analytics

To set up agentic AI with Superset, you need:

1. Semantic layer: Document your data model (tables, columns, relationships) so the AI understands what’s available
2. LLM integration: Connect Claude, GPT-4, or another LLM via API
3. Query guardrails: Define which tables/columns the AI can query (e.g., no access to customer PII)
4. Testing: Validate that the AI generates correct SQL for common insurance questions

PADISO’s AI Automation for Insurance: Claims Processing and Risk Assessment explores broader AI applications in insurance. For analytics specifically, agentic AI on Superset is a quick win: low risk, high impact, fast ROI.

---

Performance Optimisation and Scaling

Query Performance Tuning

As your claims data grows (millions of records), dashboard queries slow down. A claims triangle query that took 2 seconds with 100K claims might take 30 seconds with 10M claims. To keep dashboards snappy:

1. Pre-aggregate in the data warehouse

Instead of querying raw claims for every dashboard, pre-aggregate into a triangles table:

CREATE MATERIALIZED VIEW claims_triangle AS
SELECT
  underwriting_year,
  development_month,
  line_of_business,
  class,
  territory,
  SUM(incurred_loss) AS total_incurred,
  SUM(paid_loss) AS total_paid,
  COUNT(*) AS claim_count
FROM claims
GROUP BY underwriting_year, development_month, line_of_business, class, territory;

CREATE INDEX idx_triangle_year_dev ON claims_triangle(underwriting_year, development_month);

Superset queries this pre-aggregated view instead of raw claims. Queries that took 30 seconds now take 1 second.

2. Use Superset’s semantic layer for caching

Define a Superset dataset that points to the pre-aggregated view. Superset caches results for 1 hour (configurable). If 10 users run the same loss ratio query within an hour, Superset serves the cached result, not a fresh database query.

3. Index strategically

Index columns that are frequently filtered (underwriting_year, line_of_business, territory) and columns in JOIN conditions. Avoid indexing low-cardinality columns (claim_status: only 5 values) or columns with many NULL values.

4. Partition large tables

If your claims table has 50M rows, partition by year:

CREATE TABLE claims (
  claim_id INT,
  accident_date DATE,
  ...
) PARTITION BY RANGE (YEAR(accident_date)) (
  PARTITION p2019 VALUES LESS THAN (2020),
  PARTITION p2020 VALUES LESS THAN (2021),
  PARTITION p2021 VALUES LESS THAN (2022),
  ...
);

When a dashboard filters on underwriting_year = 2021, the database scans only the p2021 partition, not all 50M rows.

Scaling Superset Itself

As more users access dashboards, Superset’s application server may become a bottleneck. To scale:

1. Horizontal scaling: Run multiple Superset instances behind a load balancer. D23.io handles this automatically.

2. Caching layer: Add Redis for query caching. Superset stores cached results in Redis instead of memory, so multiple instances share the same cache.

3. Async query execution: Enable async mode so long-running queries don’t block the user interface. Users see a “query in progress” message and results appear when ready.

Monitoring and Alerting

Set up monitoring to catch performance issues early:

• Query execution time: Alert if dashboard queries exceed 5 seconds
• Database CPU: Alert if database CPU exceeds 80%
• Cache hit rate: Monitor Superset’s cache efficiency; if hit rate drops, investigate query patterns
• User load: Track concurrent users; if approaching capacity, plan to scale

D23.io includes monitoring and alerting as part of the managed service.

---

Security, Compliance, and Audit-Readiness

SOC 2 and ISO 27001 Considerations

General insurers handle sensitive data (customer PII, claims details, underwriting criteria). When pursuing SOC 2 or ISO 27001 compliance, dashboards must be secure and auditable.

Apache Superset supports:

1. Single Sign-On (SSO)

Users log in via corporate SAML or LDAP, not separate Superset credentials. This ensures:

• Centralised identity management
• Audit trail tied to corporate identity
• Instant access revocation when users leave

2. Role-Based Access Control (RBAC)

Define roles (Actuary, Underwriter, Claims Manager) and assign dashboards and datasets to roles. Users see only what they’re authorised to see:

• Actuaries: All dashboards (claims triangles, loss ratios, GWP, reserves)
• Underwriters: Loss ratios and GWP for their line of business only
• Claims managers: Claims by status, development, settlement

3. Row-Level Security (RLS)

For datasets with sensitive data, implement RLS so users see only rows they’re authorised for. For example:

SELECT * FROM loss_ratios
WHERE line_of_business = CURRENT_USER_LINE_OF_BUSINESS

An underwriter in Workers’ Comp sees only Workers’ Comp loss ratios, even if they navigate to a loss ratio dashboard.

4. Audit Logging

Every action in Superset is logged:

• User login/logout
• Dashboard view
• Query execution
• Data export
• Configuration change

Audit logs are immutable and can be exported for compliance review. When an auditor asks “Who accessed the loss ratio dashboard on 15 March?”, you have a complete log.

Data Governance

For SOC 2 compliance, implement data governance:

1. Data classification: Tag datasets as public, internal, or confidential. Superset respects these tags and controls access accordingly.

2. Data lineage: Document where data comes from (raw claims database) and how it’s transformed (ETL pipeline, Superset calculations). This proves data integrity to auditors.

3. Change management: Track changes to dashboards and datasets. When a loss ratio dashboard is updated, log who changed it, when, and what changed. This prevents unauthorised modifications.

4. Retention policies: Define how long to retain audit logs and query results. For SOC 2, typically 1–3 years.

Encryption and Network Security

1. Encryption in transit: Superset communicates with the database via TLS (HTTPS). All data in flight is encrypted.

2. Encryption at rest: Database and audit logs are encrypted on disk (managed by your cloud provider or database).

3. Network isolation: Run Superset in a private VPC (Virtual Private Cloud) with no public internet access. Users access via VPN or corporate network.

4. Database credentials: Store database passwords in a secrets manager (AWS Secrets Manager, HashiCorp Vault), not in Superset configuration files.

For Australian insurers, D23.io’s managed Superset stack is hosted on Australian infrastructure (Sydney region) and complies with Australian data residency requirements.

---

Implementation Timeline and Next Steps

Phase 1: Discovery and Planning (Weeks 1–2)

Goal: Understand your current state and define the target state.

Activities:

1. Audit current reporting tools (spreadsheets, legacy BI, custom reports)
2. Identify key stakeholders (actuaries, underwriters, finance, compliance)
3. Document data sources (claims database, policy system, premium system)
4. Define dashboards needed (claims triangles, loss ratios, GWP, reserves)
5. Assess current infrastructure (data warehouse, cloud platform, on-premises)

Deliverable: A requirements document and dashboard roadmap.

Phase 2: Data Warehouse and ETL (Weeks 3–6)

Goal: Prepare data for analytics.

Activities:

1. Design data warehouse schema (claims, policies, triangles tables)
2. Build ETL pipeline (dbt or Airflow) to load and transform data daily
3. Validate data quality (claims match source systems, premiums are accurate)
4. Create pre-aggregated views (claims triangles, loss ratios) for performance
5. Set up incremental loads to handle daily data growth

Deliverable: A working data warehouse with daily data refresh.

Phase 3: Superset Deployment (Weeks 7–10)

Goal: Deploy Superset and build core dashboards.

Activities:

1. Provision Superset infrastructure (D23.io managed or self-hosted)
2. Configure SSO (SAML or LDAP) and RBAC
3. Connect to data warehouse
4. Build semantic layer (datasets for claims, policies, loss ratios)
5. Create 5–10 production dashboards:
   • Claims triangles (by line, by class, by territory)
   • Loss ratios (by line, by class, trend, vs. target)
   • GWP analytics (trend, by line, by territory, vs. target)
   • Reserve adequacy (by line, by year)
   • Claims development (frequency, severity, settlement speed)
6. Configure caching and query optimisation
7. Set up audit logging and monitoring

Deliverable: Live dashboards accessible to business users.

Phase 4: Training and Handover (Weeks 11–12)

Goal: Enable business users to use and modify dashboards.

Activities:

1. Train actuaries and underwriters on dashboard navigation
2. Train data analysts on dashboard creation and modification
3. Document data definitions and calculation logic
4. Set up support and escalation process
5. Plan ongoing maintenance (monthly data quality checks, quarterly dashboard reviews)

Deliverable: Trained users and documentation.

Typical Engagement: $50K Fixed-Fee

At PADISO, we offer a fixed-fee $50K engagement covering all of the above, delivered in 6 weeks. This includes:

• Data warehouse design and ETL pipeline
• Superset deployment on D23.io
• 5–10 production dashboards
• SSO and RBAC configuration
• Training and documentation
• 30 days of post-launch support

For Australian general insurers, this is significantly faster and cheaper than building in-house or hiring traditional consultants. The D23.io Consulting Engagement: What’s Inside breaks down what’s included.

Beyond the Initial Deployment

After launch, consider:

1. Agentic AI for self-service analytics: Once dashboards are stable, add agentic AI so actuaries and underwriters can ask natural-language questions without SQL.

2. Predictive analytics: Use loss triangles to forecast future development and reserve adequacy. Superset can visualise predictions from models trained in Python or R.

3. Real-time claims monitoring: Move from daily refresh to hourly or real-time for high-value claims. Alert underwriters when a claim develops unexpectedly.

4. Portfolio optimisation: Use GWP and loss ratio data to optimise underwriting criteria, pricing, and reinsurance placement.

5. Regulatory reporting: Automate APRA reporting (capital requirements, solvency margins) by feeding Superset dashboards into regulatory submission templates.

PADISO’s broader AI Automation Agency Services cover these advanced use cases. We partner with insurers to move beyond dashboards to AI-driven decision-making.

---

Summary and Key Takeaways

Apache Superset is a game-changer for general insurers. It replaces expensive legacy BI tools with a fast, flexible, open-source platform that puts analytics in the hands of business users.

For claims triangles, Superset makes loss development visible and interactive. Actuaries see how claims are developing in real-time, not quarterly. Underwriters understand loss trends without waiting for reports.

For loss ratios, Superset enables daily monitoring of underwriting performance. Underwriters spot deterioration immediately and adjust criteria or pricing before losses spiral.

For GWP, Superset tracks portfolio growth and progress toward targets. Product managers and underwriting managers make faster decisions about where to grow and where to tighten.

For compliance, Superset’s audit logging, SSO, and RBAC make dashboards compliant with SOC 2 and ISO 27001 requirements. Every query is traceable; every access is authorised.

For cost, Superset costs a fraction of Tableau or Qlik. A complete deployment (data warehouse, Superset, dashboards, training) costs $50K and takes 6 weeks—far cheaper and faster than traditional BI projects.

Next Steps

1. Audit your current reporting: What dashboards do you need? What data do you have? What’s missing?
2. Assess your data infrastructure: Do you have a data warehouse? If not, plan one (Snowflake is ideal for Australian insurers).
3. Define your MVP: Start with claims triangles and loss ratios. Add GWP and reserves later.
4. Engage a partner: PADISO offers a fixed-fee $50K engagement to deploy Superset end-to-end. We handle data warehouse design, ETL, Superset deployment, dashboards, and training.
5. Plan for scale: Once dashboards are live, plan for agentic AI, predictive analytics, and real-time monitoring.

General insurance is data-driven. Your dashboards should be too. Apache Superset on D23.io’s managed stack makes it possible, affordable, and fast.

---

Additional Resources

For deeper learning on specific topics:

• Apache Superset official documentation — The definitive guide to Superset features and configuration.
• Sparkco’s deep dive on claims triangles and link ratios — Detailed actuarial explanation of how triangles work.
• Casualty Actuarial Society claims triangle tutorial — Educational resource on triangle construction and development factors.
• NAIC loss ratio information — Regulatory context on loss ratio calculation and reporting.
• Swiss Re loss ratio development dataset — Real-world loss triangle data for testing and validation.
• Data engineer’s guide to fast Superset dashboards — Performance optimisation techniques.
• GitHub discussion on scenario planning in Superset — Advanced dashboard patterns for what-if analysis.

For Australian insurers specifically, PADISO offers fractional CTO leadership and co-build support. We’ve deployed Superset for insurers covering claims development triangles, loss ratios by class, and GWP analytics on D23.io’s managed stack. Let’s talk about your requirements.

Reach out to PADISO to discuss your analytics roadmap and get a fixed-fee proposal for Superset deployment.