Why insurance risk assessment breaks down in a stream of applications
Manual underwriting rests on two assumptions: there are few applications, and a decision on each can be made in minutes.
In a high-volume stream, both break down — the queue grows faster than underwriters can clear it, and insurance risk assessment turns into a race of “who got there first.” Some applications go to the customer without a clear answer, some receive a boilerplate verdict based on one or two attributes, and the portfolio fills with risks no one has measured.
The rules are outdated. Coefficient tables and questionnaires were built for different loss statistics and do not account for how customer behavior has changed.
A fixed threshold sees neither seasonality nor feature combinations: an application passes as standard even though the combination of route, experience, and nature of damage has already appeared in groups with high claim frequency.
A separate problem is telematics data. It is collected and stored in the data warehouse, but it barely participates in the decision: aggregates are recalculated in batches, once a day, and end up in a report rather than at the moment of assessment. Fresh events — harsh braking, night trips, a change of primary driver — do not affect the verdict.
The result is the same in both cases: the decision is late, and its rationale is not reproducible. Let us break down how this is closed — from rebuilding rules on telematics to automatic application checks in the stream.
What predictive analytics of portfolio loss ratio provides
A predictive model moves loss ratio work from annual reporting into continuous control.
Inputs include anonymized policy data, claims history, telematics, and inspection results; outputs include expected loss ratio for each segment and a signal where actuals diverge from forecast.
We calibrate against public actuarial statistics from Bank of Russia so the forecast relies on the market, not only on the company’s internal data.
The share of automated decisions grows through separating flows.
Applications without fraud indicators, within the limit, and with a complete document set are closed by the system — a typical benchmark is 60–70% of the flow; the rest goes to manual review, but already with a assembled dossier and risk assessment. Application review time drops from several days to hours.
Detection of fraudulent schemes relies on a relationship graph: the system highlights repeat claims for the same event, inflated damage, serial participants, and signs of collusion with intermediaries.
Each class of scheme is described by a rule and confirmed by the model, so disputed cases go to review with justification, not on suspicion.
Policy segmentation — by vehicle type, sales channel, region, and driver experience — shows where loss ratio is rising.
Within a segment, the spread stays within a given corridor: the tariff stops equalizing unprofitable and profitable customers, and deviation is visible before it accumulates in reporting.
Comparison of approaches: rules, statistics, machine learning
Rules and statistics do not compete with machine learning — they cover different parts of the funnel. At the entry point, where there is almost no customer data, a set of expert rules works: it catches obvious anomalies and does not require a training sample.
Then a scorecard model and a model based on historical data are connected — the choice between them is determined not by “modernity,” but by portfolio maturity, feature stability, and labeling quality.
| Approach | When suitable | Limitations |
|---|---|---|
| Expert rules | Portfolio is small, history is short, explainability of each denial is needed | Does not scale: conditions conflict, false positives grow with the number of rules |
| Scorecard model | Few features and they are stable, a transparent scale is needed for the underwriter | Weights are set manually, nonlinear dependencies and feature interactions are lost |
| Model based on historical data | Tens of thousands of policies with confirmed losses and claims have been accumulated | Requires labeling and drift control; overfits and “invents” on rare classes |
| Hybrid scheme | Coverage for new customers and accuracy on a mature segment are needed at once | More expensive to operate: two loops, feature versioning, reconciliation of the final score |
The limitations of approaches matter more than their accuracy in a demo. Therefore, on a mature portfolio we assemble a hybrid scheme: rules filter the entry, the model ranks applications, and the final score is calibrated to actual cohort loss ratio.
Stages of implementing an underwriting system
Implementing underwriting is not installing a model, but a sequence where each step relies on the result of the previous one.
If you skip the audit of sources or validation on a period the model has not seen, it will show beautiful numbers in training and diverge from the real application flow. Work proceeds from data reconnaissance to regulations for the team.
- Data audit. We break down the sources: applications, policy telematics, claims history, external checks. We calculate the missing rate, delivery lag, and stability of extracts over past periods — this determines which features may be used.
- Decision scheme. We define the composition of blocks: risk assessment, fraud detection rules, manual review queue. We fix the embedding point in the policy issuance process.
- Feature and threshold tuning. We set zone boundaries: automatic approval, manual review, denial. The threshold is calculated from the cost of errors — a missed loss versus a lost customer.
- Validation on a holdout sample. We run the decision on a period the model has not seen, verify calibration and stability across seasons, and review the share of applications sent to manual review.
- Shadow mode. The decision runs in parallel with the current one, and we compare discrepancies by portfolio segments — this shows where the new approach conflicts with underwriter experience.
- Monitoring and handover. We set up control of input data drift and quality degradation, and describe regulations for reviewing thresholds. We train the team to handle disputed cases and work with feedback.
Regulations, schemes, and access policies in the delivery
A solution without documentation lasts exactly until the first departure of the engineer who assembled it.
Therefore, the delivery includes not only a working insurance risk assessment system, but also a kit by which your team can independently add features, handle disputed applications, and notice quality degradation before the underwriter sees it.
- Feature description — for each source: formula, aggregation window, allowable gaps, and contribution to the final score. A new feature is introduced by editing configuration, without rebuilding the model.
- Data flow diagram — from the telematics device and application to the feature store and review queue. It notes where personal data is anonymized and which fields remain raw.
- Access policies — role matrix: the underwriter sees the score and its explanation, the analyst sees features and extracts, the security service sees application history by customer and related parties. Every action is written to an immutable log.
- Review regulations — the procedure for an application with a borderline score: who reviews, within what timeframe, how the decision is recorded, and how it is returned to the training sample.
- Quality monitoring — metrics (share of missed fraudulent applications, false positive rate, feature distribution drift), alert thresholds, and duty officer actions when they are exceeded.
- Versioning and retraining — which version processed a specific application, how to reproduce its decision, how to roll back, and at what frequency the release of a new version is agreed.
We deliver the kit in your environment and review it on your applications — the team reaches the point of independent edits without us.
Case study: reducing payouts for fraudulent schemes
Auto CASCO portfolio: where payouts leaked
Before the project, the decision on a claim was sequential: document check, examination, and only at the payout stage did relationships between participants surface.
Staged accidents, duplicated damage for one vehicle, and “friendly” repair services were identified after approval — it was rarely possible to recover the payout. Repeat claims from the same groups were not matched: data was in different systems and did not reconcile by keys.
What changed
Events for each policy were collected into a single layer: application, telematics, repair history, expert opinions, past payouts.
On top, we built a relationship graph between driver, vehicle, policy, repair service, and expert, as well as a model that calculates risk at the time of application, not after.
Applications with signs of a scheme go to a specialist with decoding — the list of triggered features and the weight of each, so the decision withstands scrutiny from the customer and the regulator. Personal data processing is built according to ISO/IEC 27001.
Metrics before and after
The share of schemes detected at the application stage grew from 14% to 63% — a significant part of payouts simply does not go out. Repeat applications decreased by 38%: the system remembers the participant and pulls their history before making a decision.
Time to decision on clean applications — from several days to minutes, while suspicious ones are reviewed with priority and a ready set of features. Rolling back rules and the model to the previous version takes one work cycle and does not stop application intake.
How does risk scoring differ from underwriting rules?
Score-based assessment turns a set of features into a continuous value: driving experience, claims history, telematics behavior, frequency of applications.
Each feature enters with its own weight, weights are calibrated on past policies, and the result is compared to thresholds — the outcome is not “yes/no,” but the customer’s place on the risk scale.
Hard rules are binary conditions on a specific fact. If the declared vehicle does not match inspection data or a fraud investigation is already underway for the customer, the decision is made regardless of score. There are few rules, they are written manually, versioned, and legally reviewed.
The order of execution is strict. First, prohibition rules run: if triggered — denial, and the system does not proceed. Then trigger rules that route the application to manual review or request additional documents. Only after that is the score calculated.
Decision conflict is resolved in favor of rules. A rule is a fixed requirement that cannot be outweighed by a total score, otherwise the model will start approving what the business prohibited.
The reverse case — a high score with a soft warning — does not block, but flags the application for selective review, so discrepancies are addressed rather than accumulated.
The approaches complement each other: rules provide explainability and an audit trail, scoring provides sensitivity to complex feature combinations. Some rules over time become model features, and discrepancies between layers become material for recalibration.
Technical doubts: data, explainability, integration
The customer’s technical team asks the same set of questions before the start: whether data is sufficient, whether a denial for a specific policy can be explained, how the decision will fit into the current environment, and what will happen to it in a year. We answer substantively.
Arguing about the choice of approach before a data audit is pointless: in insurance risk assessment, a rare event is the norm, not an anomaly. Therefore, we first check the completeness of history for each policy and how customer denials are reflected in it.
Is our data sufficient?
We look not at volume but at coverage: how long records have been kept, how many policies have full history, and where gaps in behavioral features are.
With strong class imbalance, we tune weights and the trigger threshold to the cost of a missed error — for an insurer it is higher than the cost of an extra manual review.
Can we explain why an application went to manual review?
Yes. For each decision we save feature values and their contribution at the time of calculation, so the employee sees not “high score” but the grounds: data discrepancy, atypical history, signs of a fraudulent scheme. Records are immutable — they can be presented when reviewing a disputed case.
How will the system integrate into our environment?
Through existing channels: application flow, reference data, manual review queue. Externally we provide the score and a set of grounds; the underwriter card does not break. If the scoring service is unavailable, issuance continues under the previous rules.
What will happen to the model after launch?
Data drifts: the portfolio, customer behavior, and fraud schemes change. Together with the solution, we hand over maintenance regulations — control of the trigger share on a fresh slice, periodic retraining, and the procedure for rolling back to the previous version.
What to clarify before starting work on the system
The timeline for developing an insurance risk assessment system is determined not by the amount of code but by the quality and availability of data: telematics from different devices, loss history, agent questionnaires, and external registries are almost always heterogeneous.
Therefore, before the start we need a short set of inputs — based on them we will return with a stage-by-stage work plan, timeline estimate, and acceptance points. They can be gathered in one meeting with the project engineers, without intermediaries or retellings.
- Data sources: which telematics channels are already connected, in what form loss history arrives, over what period it has accumulated, and where the gaps are.
- Target scenario: the system scores at policy issuance, at claim, or at tariff review, and what it decides on its own versus hands to the underwriter.
- Current process: how long manual review of one application takes, what share of applications goes to additional review, and where money is lost.
- Integrations: we embed into the claims settlement system, the agent portal, or reinsurer reporting.
- Data and access: how customer information is anonymized, where it is stored, and who gets access and on what basis.
- Acceptance: on which sample we check assessment quality and which metrics we consider sufficient for launch.
Describe the task in general terms — we will return with a timeline estimate and a stage-by-stage work plan. At a meeting with the engineers we will clarify the details: you will receive the team composition, the sequence of steps, and acceptance points.
