Most insurance decisions are made on data that is 8 to 24 hours old. Real-time data closes that gap. It delivers a 22% higher bind rate on commercial submissions, 34% more fraud identified at FNOL, and earlier cat event management that reduces net losses. This post explains the event streaming architecture, the five highest-impact use cases, and what documented deployments show on decision speed and commercial outcomes.
The submission arrives at 09:15.
It is a commercial property risk. A six-storey office building in central Oslo. The broker wants terms by end of day. Under the old process, the underwriter would open the submission, note the property address, and add it to her review queue. The risk data she needs — the current portfolio exposure in that postcode, the prior claims history on that address, the catastrophe model output for that location, the weather event probability for this month — would come from last night’s batch run. The data would be between 8 and 18 hours old. She would make her decision tomorrow, with yesterday’s picture.
Under the new process, the moment the submission arrives, the real-time data platform queries simultaneously: the Norwegian property register for the building’s characteristics, the claims history database for that address, the catastrophe model API for the current flood and storm risk score, and the live portfolio exposure dashboard for the current accumulation in that postcode and peril. At 09:17, the underwriter has everything she needs. She makes the decision. She sends terms. The broker’s morning coffee is still warm.
The Data Decision Gap in Insurance and How Real-Time Data Closes It
Real-time data insurance is the capability to query, process, and act on current data at the point of decision rather than data from the prior processing cycle. Most insurance decisions today are made on data that is between 8 and 24 hours old. The portfolio exposure that the underwriter sees was calculated last night. The fraud score that the claims handler sees was run on yesterday’s submissions. The accumulation position that the catastrophe manager monitors was refreshed at 23:00. Insurance decision intelligence built on stale data is intelligence about yesterday, not today.
The gap between a batch data decision and a real-time data decision is not measured in seconds. It is measured in outcomes. A 22% higher bind rate. A 34% higher fraud detection rate at FNOL. A reserve estimate that reflects what happened this morning rather than what the system knew last night. Insurance data analytics that operates in real time does not require different analytical techniques. It requires different infrastructure. Real-time data insurance capability is built on event streaming, API-connected data sources, and AI models deployed as real-time APIs.
The Batch Data Problem: What it Costs and Where
Overnight batch processing was designed for a world where data volumes were small and computing was expensive. Both conditions no longer apply. But the batch architecture remains standard in most insurance operations. Batch processing creates decision latency. The data available at decision time is a snapshot of a prior state. The portfolio exposure visible at 09:15 reflects positions as of 23:00 the previous evening. Any submissions bound since then are not yet reflected. Any cat event developing since then is not yet visible in the accumulation data.
| Decision type | Batch data latency | Real-time data capability | Commercial impact |
|---|---|---|---|
| Commercial property underwriting | Portfolio exposure data from overnight batch: 8–16 hours old at point of decision | Current portfolio exposure queried at submission receipt: 0–2 minutes | Bind rate improvement: 22%. Fewer accumulation surprises post-event. |
| FNOL fraud triage | Fraud score from overnight model run: decision made on yesterday’s risk profile | Live fraud score at point of FNOL notification: real-time behavioural and network signals | Fraudulent claims identified at FNOL: 34% higher than batch scoring. |
| Cat event portfolio monitoring | Aggregate exposure calculated post-event from overnight data: damage already bound | Intraday accumulation tracking: exposure visible as events develop | Reinsurance treaty protection activated 4–6 hours earlier than batch equivalent. |
| Motor claims settlement | Reserve estimate based on prior-day data: accuracy limited by data age | Live IoT and telematics data at FNOL: current vehicle location, impact data, third-party data | Reserve accuracy improvement: 18%. Early settlement rate up 28%. |
| Pricing adjustment | Rate changes applied overnight: market movements not reflected intraday | Intraday pricing signals: competitor rate changes, weather events, demand shifts visible immediately | Pricing decisions aligned with current market: loss ratio improvement of 4–7 percentage points. |
The fraud detection case illustrates the problem most clearly. A fraudulent claimant who submits a FNOL at 09:15 receives a fraud score calculated from a model run at 23:00 the previous evening. That model did not have access to the two other suspicious claims submitted this morning by connected parties. A real-time fraud scoring model does. The network signal is visible. The referral is triggered. The batch model misses it.
What Real-Time Data Insurance Enables Across the Business
Underwriting: current portfolio at the point of decision
The underwriter in the opening scene needed three data inputs: current portfolio exposure by geography and peril, external property and risk data for the specific submission, and the catastrophe model output for the location. All three were available in 2 minutes rather than 18 hours. The commercial impact is not just speed. It is accuracy. The underwriter who sees the current accumulation position makes a different decision from the underwriter who sees last night’s position. If three other commercial property submissions in the same postcode were bound this morning, the current exposure is materially different from the overnight snapshot.
Claims: live scoring at FNOL
Claims AI decision insurance models that operate in real time receive the FNOL data, query the live claims network for connected parties, check the current fraud pattern database, and return a triage score within 200 milliseconds. The claims handler sees the score before she opens the case. High-scoring cases go to specialist investigation immediately. Standard cases enter the straight-through processing track. The decision happens before any manual review begins. The fraud signal is current. It reflects what happened this morning, not last night.
Portfolio: intraday accumulation monitoring
Cat event portfolio monitoring in real time tracks aggregate exposure as events develop. A storm system developing off the Norwegian coast at 14:00 is visible in the accumulation dashboard within minutes of updated data arriving from the cat model API. The risk manager can see the developing exposure against reinsurance treaty limits before the event has reached its peak. Under a batch architecture, the same information arrives in the 23:00 run. By then, the event has already been active for hours. The window to activate treaty protection at optimal timing has closed.
The Technology Architecture for Real-Time Data in Insurance
Insurance real-time analytics platform infrastructure has five layers. Each must be in place for the full real-time decision capability to function. Insurers that cannot replace their core system immediately can still deploy real-time capabilities by layering an event streaming architecture above their legacy core.
| Layer | Technology | Function |
|---|---|---|
| Event streaming | Apache Kafka; AWS Kinesis; Azure Event Hubs | Ingests data events from source systems in real time; delivers to consumers within milliseconds (policy changes, claims, IoT) |
| Real-time data lake | Databricks Delta Lake; Snowflake; AWS S3 + Glue | Stores streaming data with immediate query access; no overnight load cycle required for portfolio exposure tracking |
| API-connected data sources | REST APIs to property registries, weather services, cat models | Pulls external enrichment data at the point of query rather than in scheduled batch runs |
| AI decision models | Gradient boosting, neural networks, rule engines via APIs | Consumes streaming data to produce decision outputs: fraud scores within 200ms, reserves within 500ms |
| Decision delivery layer | API gateway; event bus; CRM/workflow integration | Delivers AI decision output immediately to the underwriter workbench or automated system track |
Data Governance for Real-Time Flows
Real-time data creates governance challenges that batch processing does not. Batch data is processed at a defined point, making lineage easy to trace. Real-time data flows continuously. Events arrive from multiple sources simultaneously. The lineage must be tracked at the event level, not the batch level.
Three governance requirements apply to real-time insurance data flows. Data quality monitoring must operate continuously, not just at batch load time. A data quality failure in a real-time stream produces incorrect decision outputs within seconds. Data lineage must be captured at the event level. Each decision output must be traceable to the specific data inputs that produced it, satisfying Solvency II data quality requirements under Article 82 and the EU AI Act audit trail requirement. Finally, access control must reflect the sensitivity of the data in real time, leveraging role-based access at the stream subscription level.
For Norwegian insurers, the real-time data sources available include the Norwegian property register (Kartverket), the Norwegian vehicle register, BankID for identity verification, and weather data from the Norwegian Meteorological Institute. Finanstilsynet’s data governance expectations apply to real-time data flows in the same way they apply to batch data. GDPR data minimisation and purpose limitation apply to each data stream individually.[4]
Frequently Asked Questions
Our core system only supports batch processing — how do we get to real-time without replacing it?+
You do not need to replace the core system to deploy real-time capabilities. A streaming layer deployed alongside the existing batch infrastructure captures events from the core system as they occur — claims events, policy changes, payment events — and makes them available to real-time models without touching the underlying system. This approach runs in parallel until the core system is eventually modernised.[3]
What is the difference between a real-time data lake and a traditional data warehouse?+
A traditional data warehouse is loaded on a schedule — typically overnight. Queries against it return data as of the last load. A real-time data lake ingests data continuously via event streaming. Queries return data as of the last event, which may be milliseconds ago. The real-time capability is the streaming ingestion layer, not the query capability itself.[1]
How do we manage data quality in a real-time stream where errors propagate immediately?+
Real-time data quality management requires automated monitoring at the stream level. The monitoring checks schema validity, value range validation, and completeness continuously. Events that fail validation are routed to a quarantine stream for investigation. Downstream consumers receive only validated events, triggering alerts immediately when the quarantine rate exceeds a defined threshold.[1]
What GDPR obligations apply to real-time data streams that include personal data?+
GDPR applies to personal data in real-time streams in the same way it applies to batch data. Data minimisation requires that only fields necessary for the specific decision are included in the stream subscription. The specific requirement that real-time streams add is the audit trail: each decision output must be traceable to the specific data events that produced it, satisfying GDPR Article 22 and the EU AI Act audit trail obligations.[4]
How long does it take to deploy a real-time data capability for underwriting?+
A real-time underwriting data capability typically takes 12 to 18 weeks to deploy from infrastructure provisioning to production use. A Norwegian insurer connecting to Kartverket for property data and the Norwegian weather service for cat risk enrichment typically completes the external data connections in 4 to 6 weeks, while legacy core systems may take longer to expose internal events.[1]
How do we measure the ROI on a real-time data investment?+
The ROI framework has three components: Revenue (higher bind rates), Loss Ratio (faster fraud detection, more accurate reserves, earlier cat activation), and Operational Efficiency. For a mid-size Norwegian insurer with annual GWP of NOK 2 billion, a 22% bind rate improvement on commercial lines and a 34% fraud detection improvement at FNOL typically generates a combined annual benefit of NOK 28 to 45 million, recovering the investment cost within 12 to 18 months.[1][2]
References
Most insurance decisions are made on data that is 8 to 24 hours old. Real-time data closes that gap. It delivers a 22% higher bind rate on commercial submissions, 34% more fraud identified at FNOL, and earlier cat event management that reduces net losses. This post explains the event streaming architecture, the five highest-impact use cases, and what documented deployments show on decision speed and commercial outcomes.
The submission arrives at 09:15.
It is a commercial property risk. A six-storey office building in central Oslo. The broker wants terms by end of day. Under the old process, the underwriter would open the submission, note the property address, and add it to her review queue. The risk data she needs — the current portfolio exposure in that postcode, the prior claims history on that address, the catastrophe model output for that location, the weather event probability for this month — would come from last night’s batch run. The data would be between 8 and 18 hours old. She would make her decision tomorrow, with yesterday’s picture.
Under the new process, the moment the submission arrives, the real-time data platform queries simultaneously: the Norwegian property register for the building’s characteristics, the claims history database for that address, the catastrophe model API for the current flood and storm risk score, and the live portfolio exposure dashboard for the current accumulation in that postcode and peril. At 09:17, the underwriter has everything she needs. She makes the decision. She sends terms. The broker’s morning coffee is still warm.
The Data Decision Gap in Insurance and How Real-Time Data Closes It
Real-time data insurance is the capability to query, process, and act on current data at the point of decision rather than data from the prior processing cycle. Most insurance decisions today are made on data that is between 8 and 24 hours old. The portfolio exposure that the underwriter sees was calculated last night. The fraud score that the claims handler sees was run on yesterday’s submissions. The accumulation position that the catastrophe manager monitors was refreshed at 23:00. Insurance decision intelligence built on stale data is intelligence about yesterday, not today.
The gap between a batch data decision and a real-time data decision is not measured in seconds. It is measured in outcomes. A 22% higher bind rate. A 34% higher fraud detection rate at FNOL. A reserve estimate that reflects what happened this morning rather than what the system knew last night. Insurance data analytics that operates in real time does not require different analytical techniques. It requires different infrastructure. Real-time data insurance capability is built on event streaming, API-connected data sources, and AI models deployed as real-time APIs.
The Batch Data Problem: What it Costs and Where
Overnight batch processing was designed for a world where data volumes were small and computing was expensive. Both conditions no longer apply. But the batch architecture remains standard in most insurance operations. Batch processing creates decision latency. The data available at decision time is a snapshot of a prior state. The portfolio exposure visible at 09:15 reflects positions as of 23:00 the previous evening. Any submissions bound since then are not yet reflected. Any cat event developing since then is not yet visible in the accumulation data.
| Decision type | Batch data latency | Real-time data capability | Commercial impact |
|---|---|---|---|
| Commercial property underwriting | Portfolio exposure data from overnight batch: 8–16 hours old at point of decision | Current portfolio exposure queried at submission receipt: 0–2 minutes | Bind rate improvement: 22%. Fewer accumulation surprises post-event. |
| FNOL fraud triage | Fraud score from overnight model run: decision made on yesterday’s risk profile | Live fraud score at point of FNOL notification: real-time behavioural and network signals | Fraudulent claims identified at FNOL: 34% higher than batch scoring. |
| Cat event portfolio monitoring | Aggregate exposure calculated post-event from overnight data: damage already bound | Intraday accumulation tracking: exposure visible as events develop | Reinsurance treaty protection activated 4–6 hours earlier than batch equivalent. |
| Motor claims settlement | Reserve estimate based on prior-day data: accuracy limited by data age | Live IoT and telematics data at FNOL: current vehicle location, impact data, third-party data | Reserve accuracy improvement: 18%. Early settlement rate up 28%. |
| Pricing adjustment | Rate changes applied overnight: market movements not reflected intraday | Intraday pricing signals: competitor rate changes, weather events, demand shifts visible immediately | Pricing decisions aligned with current market: loss ratio improvement of 4–7 percentage points. |
The fraud detection case illustrates the problem most clearly. A fraudulent claimant who submits a FNOL at 09:15 receives a fraud score calculated from a model run at 23:00 the previous evening. That model did not have access to the two other suspicious claims submitted this morning by connected parties. A real-time fraud scoring model does. The network signal is visible. The referral is triggered. The batch model misses it.
What Real-Time Data Insurance Enables Across the Business
Underwriting: current portfolio at the point of decision
The underwriter in the opening scene needed three data inputs: current portfolio exposure by geography and peril, external property and risk data for the specific submission, and the catastrophe model output for the location. All three were available in 2 minutes rather than 18 hours. The commercial impact is not just speed. It is accuracy. The underwriter who sees the current accumulation position makes a different decision from the underwriter who sees last night’s position. If three other commercial property submissions in the same postcode were bound this morning, the current exposure is materially different from the overnight snapshot.
Claims: live scoring at FNOL
Claims AI decision insurance models that operate in real time receive the FNOL data, query the live claims network for connected parties, check the current fraud pattern database, and return a triage score within 200 milliseconds. The claims handler sees the score before she opens the case. High-scoring cases go to specialist investigation immediately. Standard cases enter the straight-through processing track. The decision happens before any manual review begins. The fraud signal is current. It reflects what happened this morning, not last night.
Portfolio: intraday accumulation monitoring
Cat event portfolio monitoring in real time tracks aggregate exposure as events develop. A storm system developing off the Norwegian coast at 14:00 is visible in the accumulation dashboard within minutes of updated data arriving from the cat model API. The risk manager can see the developing exposure against reinsurance treaty limits before the event has reached its peak. Under a batch architecture, the same information arrives in the 23:00 run. By then, the event has already been active for hours. The window to activate treaty protection at optimal timing has closed.
The Technology Architecture for Real-Time Data in Insurance
Insurance real-time analytics platform infrastructure has five layers. Each must be in place for the full real-time decision capability to function. Insurers that cannot replace their core system immediately can still deploy real-time capabilities by layering an event streaming architecture above their legacy core.
| Layer | Technology | Function |
|---|---|---|
| Event streaming | Apache Kafka; AWS Kinesis; Azure Event Hubs | Ingests data events from source systems in real time; delivers to consumers within milliseconds (policy changes, claims, IoT) |
| Real-time data lake | Databricks Delta Lake; Snowflake; AWS S3 + Glue | Stores streaming data with immediate query access; no overnight load cycle required for portfolio exposure tracking |
| API-connected data sources | REST APIs to property registries, weather services, cat models | Pulls external enrichment data at the point of query rather than in scheduled batch runs |
| AI decision models | Gradient boosting, neural networks, rule engines via APIs | Consumes streaming data to produce decision outputs: fraud scores within 200ms, reserves within 500ms |
| Decision delivery layer | API gateway; event bus; CRM/workflow integration | Delivers AI decision output immediately to the underwriter workbench or automated system track |
Data Governance for Real-Time Flows
Real-time data creates governance challenges that batch processing does not. Batch data is processed at a defined point, making lineage easy to trace. Real-time data flows continuously. Events arrive from multiple sources simultaneously. The lineage must be tracked at the event level, not the batch level.
Three governance requirements apply to real-time insurance data flows. Data quality monitoring must operate continuously, not just at batch load time. A data quality failure in a real-time stream produces incorrect decision outputs within seconds. Data lineage must be captured at the event level. Each decision output must be traceable to the specific data inputs that produced it, satisfying Solvency II data quality requirements under Article 82 and the EU AI Act audit trail requirement. Finally, access control must reflect the sensitivity of the data in real time, leveraging role-based access at the stream subscription level.
For Norwegian insurers, the real-time data sources available include the Norwegian property register (Kartverket), the Norwegian vehicle register, BankID for identity verification, and weather data from the Norwegian Meteorological Institute. Finanstilsynet’s data governance expectations apply to real-time data flows in the same way they apply to batch data. GDPR data minimisation and purpose limitation apply to each data stream individually.[4]
Frequently Asked Questions
Our core system only supports batch processing — how do we get to real-time without replacing it?+
You do not need to replace the core system to deploy real-time capabilities. A streaming layer deployed alongside the existing batch infrastructure captures events from the core system as they occur — claims events, policy changes, payment events — and makes them available to real-time models without touching the underlying system. This approach runs in parallel until the core system is eventually modernised.[3]
What is the difference between a real-time data lake and a traditional data warehouse?+
A traditional data warehouse is loaded on a schedule — typically overnight. Queries against it return data as of the last load. A real-time data lake ingests data continuously via event streaming. Queries return data as of the last event, which may be milliseconds ago. The real-time capability is the streaming ingestion layer, not the query capability itself.[1]
How do we manage data quality in a real-time stream where errors propagate immediately?+
Real-time data quality management requires automated monitoring at the stream level. The monitoring checks schema validity, value range validation, and completeness continuously. Events that fail validation are routed to a quarantine stream for investigation. Downstream consumers receive only validated events, triggering alerts immediately when the quarantine rate exceeds a defined threshold.[1]
What GDPR obligations apply to real-time data streams that include personal data?+
GDPR applies to personal data in real-time streams in the same way it applies to batch data. Data minimisation requires that only fields necessary for the specific decision are included in the stream subscription. The specific requirement that real-time streams add is the audit trail: each decision output must be traceable to the specific data events that produced it, satisfying GDPR Article 22 and the EU AI Act audit trail obligations.[4]
How long does it take to deploy a real-time data capability for underwriting?+
A real-time underwriting data capability typically takes 12 to 18 weeks to deploy from infrastructure provisioning to production use. A Norwegian insurer connecting to Kartverket for property data and the Norwegian weather service for cat risk enrichment typically completes the external data connections in 4 to 6 weeks, while legacy core systems may take longer to expose internal events.[1]
How do we measure the ROI on a real-time data investment?+
The ROI framework has three components: Revenue (higher bind rates), Loss Ratio (faster fraud detection, more accurate reserves, earlier cat activation), and Operational Efficiency. For a mid-size Norwegian insurer with annual GWP of NOK 2 billion, a 22% bind rate improvement on commercial lines and a 34% fraud detection improvement at FNOL typically generates a combined annual benefit of NOK 28 to 45 million, recovering the investment cost within 12 to 18 months.[1][2]
How insurers are using real-time data to make faster and smarter business decisions.