Gains:
- Ability to detect missing values, outliers, exposure and data quality problems in policy and damage data with artificial intelligence support and produce a correction draft
- Feature engineering (new variable derivation, grouping, coding) and exposure normalization to artificial intelligence with the right context
- Understand that data transformations suggested by artificial intelligence should be audited by an actuary against the risk of data leakage and hidden bias.
The least talked about but most time consuming part of actuarial work is data preparation. Experienced actuaries know that most of the time of a modeling project is spent cleaning, combining, and correcting the data. No matter how elegant the model, if the input data is corrupt, the output is corrupt—in short, “garbage in, garbage out.” In this unit, we will see typical problems of policy and claims data, how to detect and fix them with AI, and the feature engineering (derived new variables that are more informative from existing data) approach.
A warning from the beginning: data preparation is a seemingly technical and innocent step, but this is where the most dangerous errors hide. An incorrect exposure normalization, a hidden data leak, or an unwittingly introduced bias silently corrupts all subsequent models. AI greatly accelerates this step, but if left uncontrolled, it also magnifies the risk.
Typical problems of actuarial data
Policy and claims data almost never arrive clean. The most common problems are: Missing values: some policies have blank vehicle age, occupation or region. Blindly filling these with the average can create bias; the deficiency itself sometimes carries information (the missing are a different group). Outliers: illogical records such as negative premium, 200-year-old insured, zero-exposure policy. It must be distinguished whether these are data errors or real edge cases. Inconsistency: different spellings of the same region ("Istanbul", "Istanbul", "34"), date format confusion. Duplicate entries: entry of the same damage twice.
But the most critical issue specific to actuarial is exposure. If a policy begins mid-year, it provides a fractional exposure (e.g. 0.5 years) for that year, not a full “policy-year.” Frequency and damage rates should always be normalized to exposure; otherwise short term policies appear high risk. The AI can code the exposure calculation, but you must provide the definition and business rule.
The following table summarizes typical problems and the correct approach:
problem
wrong approach
right approach
missing value
Fill all with average
Analyze the deficiency; sometimes open a separate category
outlier
Auto delete
Distinguish between data error and real lead
exposure
Count all policies for 1 year
Calculate fractional exposure
Category inconsistency
ignore
Match with standard dictionary
recurring damage
don't notice
Deduplicate with key fields
Feature engineering: deriving knowledge from data
Feature engineering is the art of deriving new variables that are more useful to the model from existing raw variables. Examples: "age" from date of birth, "age group" (binning) from age, "risk segment" from vehicle make-model, "annual mileage estimate" from address-policy combination. A good feature carries a stronger signal than the raw data and increases both the accuracy and interpretability of the model.
Three techniques are frequently used in actuarial work. Binding: separating a continuous variable (age) into meaningful groups; this captures non-linear relationships and makes the tariff readable. Encoding: converting categorical variables (region) into a numerical format suitable for the model; Risk-based coding (representing each category with its own damage rate) is common but should be done with caution. Normalization: making everything comparable by dividing it by its exposure. AI quickly generates the code for these transformations; But you must approve the logic of each transformation.
Tip: Target encoding is powerful but prone to data leakage: the model "cheats" if you include a row's own damage when calculating the average damage of a category. Always do this within the training data, in a cross-validation pattern.
The most insidious danger: data leaks and implicit bias
Data leakage is the introduction of information into the model that does not actually exist at the time of prediction. Classic example: introducing a variable containing the outcome, such as “claims paid,” into a model that predicts the claim amount. The model looks perfect in test data but is useless in the real world because that information is not available at the time of prediction. Leakage is often hidden and only caught by careful actuarial reasoning — the AI usually doesn't notice, sometimes even praising the leaky variable as "very powerful predictor."
The second insidious danger is implicit bias. If historical data unfairly represents a particular group (for example, an area has been historically denied too many policies), features derived from that data carry that bias and the model replicates it into the future. The feature engineering phase is the most critical moment when this bias can be recognized and corrected.
Caution: Before you rejoice when a variable “improves predictive power tremendously,” ask: is this variable actually present at the time of the prediction, or does it involve the future? A result that looks too good is often a sign of a leak.
How to use AI in data preparation
1) Data quality screening:
Your role: data quality assistant. You have actuarial policy yield. Columns: policy_id, start_date, end_date,age, region, vehicle_age, premium, claim_count, claim_amount.Give me a checklist and Python (pandas) code sketch:- Count missing values by column.- Flag unreasonable values (negative premium, age<16 or >100, end<start).- Calculate fractional exposure (in years) from start/end.DO NOT delete; Just report it so I can decide.
2) Feature derivation:
I want to derive new features from my traffic data. Available: age, vehicle_age, region, annual_km, usage_type.- Which age and km groups (binning) do you recommend, why?- How can I do risk-based coding for 'region' without data leakage?- Suggest 3 new features worth trying and write the actuarial justification for each. I will decide.
3) Leak inspection:
My model predicts the POSSIBILITY of damage with the following variables: age, region, vehicle_age, PAID_CLAIM_FLAG, SETTLEMENT_DAYS. Which of these variables pose a risk of data leakage? For each, evaluate whether it will be available at the time of the prediction. List the suspicious ones and why.
4) Exposure normalization:
Some of my policies start mid-year. Explain and code the exposure normalization to calculate the frequency correctly: frequency = total claim_count / total exposure (policy-year). Show with an example how to calculate the exposure of the policy that starts in the middle of the year.
Weak prompt / Strong prompt
Weak prompt:
Clean the data and make it ready for the model.
AI doesn't know which column is which, business rules, exposure definition; It can blindly delete and fill and corrupt the data.
Powerful prompt:
Your role: actuarial data preparation assistant.Data dictionary: policy_id (identity), start/end_date (policy period),age (expected 16-90), premium (must be >0), claim_count (>=0), claim_amount (>=0).Task:1) Write reasonableness rule for each column and REPORT violations (deletion).2) Give code to calculate fractional exposure.3) 3 different strategies for missing 'age' (delete). / average / separate category) present with plus-minus; Leave the decision to me.4) Warn if there is a column that may pose a risk of leakage.Automatic deletion of any record; I will approve every decision.
three mini cases
Case 1 — Exposure error. In one portfolio, short-term (3-month) travel policies were counted as full years, so the frequency appeared four times lower than it actually was; The price fell incorrectly. When the actuary calculated the exposure as a fraction (0.25 policy-year), the real frequency was revealed and the tariff was corrected. AI generated fractional exposure code; The actuary gave the definition.
Case 2 — Latent leak. When a helper added the “file closure time” variable to the damage probability model, accuracy increased dramatically. The joy was short-lived: this variable could only be known after the damage had occurred, meaning it was not available at the time of prediction. When the leaky variable was removed, the model decreased to a realistic level. He praised the AI variable as a “powerful predictor”; The actuary's judgment caught the trap.
Case 3 — Replication of bias. One company derived an “application rejection” pattern from historical data and put it into the new model. The analysis showed that past rejections were disproportionately concentrated in a particular neighborhood, meaning there was a historical bias. This feature was removed from the model and replaced with more neutral risk indicators. AI produced the analysis measuring the pattern's overlap with the neighborhood; The ethical decision was made by the actuary and the compliance unit.
Common mistakes
- Filling in missing values with the mean without thinking. The lack itself may be knowledge; Filling it out blindly creates prejudice.
- Automatically delete outliers. Some are true edge cases; Deleting data without separating it from errors destroys information.
- Not normalizing exposure. Counting short policies as full years distorts the frequency and distorts the price.
- Not noticing data leakage. Too good a result is often a sign of a variable involving the future; Query whether each variable is present at the time of prediction.
- Bringing implicit bias into the future. Injustice in historical data can leak into derived features; Check it at the feature stage.
In summary
Actuarial modeling is largely about preparing data; If the input is corrupt, the output is also corrupt. Typical problems are missing values, outliers, inconsistencies, and duplication; The critical actuarial issue is exposure normalization. Feature engineering — grouping, coding, normalization — derives stronger signals from data. The most insidious dangers are data leakage and implicit bias; both are captured only by actuarial reasoning. AI greatly speeds up this step: scanning generates code and recommendations. But do not automatically delete any records, let humans check for leaks and bias, and approve each conversion.
Application task
Prepare a small anonymous policy data dictionary (5-7 columns, reasonable range of each). Ask the AI for (a) the reasonableness rule and violation report code for each column, (b) fractional exposure calculation, (c) suggestions for 3 new features to try. Then add an intentional “leak trap” variable to the list (e.g. “compensation paid”) and test whether the AI catches it as a leak.
checklist
- [ ] Have I analyzed why before deleting missing and outliers?
- [ ] Have I fractionated and normalized the exposure correctly?
- [ ] Have I written the actuarial justification for each newly derived feature?
- [ ] Have I questioned whether each variable is actually present (leakage) at the time of prediction?
- [ ] Have I scanned for implicit bias in derived features?
- [ ] Did I not have AI automatically delete any records and approved every decision myself?