5. Insurance Data Architecture and Data Quality

Introduction and Context

Insurance fraud detection is often described as a modelling problem: collect historical claims, identify suspicious patterns, and deploy a predictive score. In practice, the quality of fraud analytics depends less on the sophistication of an algorithm than on the architecture and reliability of the data supplied to it. A model cannot distinguish fraud from poor administration when policy dates are inconsistent, customer identities are fragmented, claim payments are duplicated, or information unavailable at the time of a decision is inadvertently used as a predictor.

Insurance data is generated across a complex operating environment. A policy may be quoted through a digital channel, issued by an insurer, serviced by an intermediary, financed through a bank, amended by a call centre, and subsequently linked to a claim involving a repairer, hospital, assessor, or legal representative. Each participant creates records for a different purpose and according to different definitions. Fraud analytics must therefore integrate operational data without destroying its context.

This chapter examines the architecture required to make insurance data usable, traceable, and analytically trustworthy. It focuses on the integration of policy, claims, billing, customer, intermediary, telematics, medical, public, and third-party data. Particular attention is given to identity resolution, data lineage, missingness, bias, target leakage, governed analytical datasets, and fraud feature stores. These issues connect directly with the design of fraud detection models discussed in later chapters: a score is only as defensible as the evidence and processes behind it.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the role of data architecture in insurance fraud detection.

2. Distinguish major insurance data domains and understand their relationships.

3. Design a logical model for integrating structured, semi-structured, and external data.

4. Evaluate data quality using dimensions such as accuracy, completeness, consistency, timeliness, validity, uniqueness, and integrity.

5. Apply identity resolution, lineage, missing-data analysis, and leakage controls.

6. Explain the governance requirements for analytical datasets and fraud feature stores.

7. Assess ethical, regulatory, privacy, security, and operational risks.

8. Translate data architecture principles into practical fraud analytics decisions.

Why Fraud Analytics Begins with Architecture

Data architecture is the organised design of data sources, storage, integration, transformation, access, security, and governance. It determines how an organisation moves from operational events to reliable analytical evidence. In insurance, this movement is difficult because operational systems are usually optimised for transactions rather than longitudinal analysis. A policy administration system records coverage and endorsements; a claims system records notification, assessment, reserve, and settlement; a billing system records invoices and receipts. None is necessarily designed to provide a complete view of a customer or a suspected fraud network.

A useful distinction is between a system of record and a system of analysis. The system of record preserves the official transaction or business event. An analytical platform reorganises those events for comparison, modelling, monitoring, and decision support. The analytical platform must not silently overwrite the original record. It should retain source values, transformation rules, timestamps, and data-quality indicators so that an investigator or auditor can reconstruct how a feature or decision was produced.

A sound architecture usually separates four layers:

• Source layer: policy, claims, billing, customer, intermediary, telematics, medical, external, and document systems.
• Integration and storage layer: ingestion pipelines, staging areas, data warehouses, data lakes, or lakehouses.
• Curated analytical layer: conformed entities, standardised events, analytical marts, labels, and feature stores.
• Consumption layer: dashboards, investigation applications, rules engines, machine-learning services, and regulatory reporting.

The layers need not be implemented with identical technologies. The important principle is controlled movement of information, with clear ownership and traceability at each stage.

The Insurance Data Landscape

Policy and Coverage Data

Policy data describes the contract between insurer and policyholder. Important elements include policy identifier, product, coverage, insured object, inception and expiry dates, premium, deductible, limits, exclusions, endorsements, distribution channel, and policy status. Versioning is essential. A claim must be assessed against the coverage that applied on the date of loss, not simply against the latest policy version.

Policy data also provides temporal context. A claim reported shortly after inception, a sudden increase in coverage before a loss, or repeated cancellations and reinstatements may be relevant indicators. None is proof of fraud; each requires appropriate comparison with legitimate customer behaviour and underwriting conditions.

Claims Data

Claims data contains first-notification-of-loss information, event date, report date, claim type, cause, reserve, payments, assessment results, documents, parties involved, recovery, litigation, and closure status. Claims are event histories rather than single rows. A data model should preserve claim status changes, reserve movements, payment transactions, reopened claims, and links to related claims.

The distinction between date of loss, date reported, date assessed, and date paid is particularly important. Collapsing these dates into one field can create false patterns and leakage. For example, a final settlement amount may be highly predictive of a fraud label in historical data but is unavailable when a claim is initially triaged.

Billing and Payment Data

Billing data includes invoices, instalments, receipts, refunds, failed payments, payment instruments, commissions, recoveries, and bank or wallet references where legally permitted. It can reveal relationships between apparently unrelated policies or claims, such as repeated use of the same payment account or unusual refund destinations. Payment data is sensitive and should be tokenised or access-controlled. It should also be reconciled with accounting records; a billing transaction that has not settled is not equivalent to a completed payment.

Customer and Household Data

Customer records may contain names, addresses, contact details, identity documents, occupation, age, business relationships, consent status, and communication preferences. A customer is not always an individual. The data model may need to represent persons, businesses, households, beneficial owners, vehicles, properties, and authorised representatives as distinct entities.

Customer information is frequently duplicated because of spelling differences, address changes, transliteration, shared contact details, or multiple distribution channels. Treating each record as a separate person obscures networks; treating every similar record as the same person creates false associations.

Intermediary and Provider Data

Agents, brokers, banks, garages, hospitals, loss adjusters, lawyers, surveyors, and other providers influence the insurance process. Their identifiers, contracts, locations, commissions, referral patterns, service times, and claims associations may be useful for network and conduct analytics. Provider-level analysis must be carefully interpreted. A high claim frequency may reflect a high-volume portfolio, a specialist market, or geographical concentration rather than misconduct.

Telematics and Digital Interaction Data

Telematics may provide location, speed, acceleration, braking, mileage, journey time, or device-status information. Digital channels generate login, quotation, device, session, and document-upload events. These data can improve event verification and risk segmentation, but they introduce questions about consent, data minimisation, sensor reliability, shared devices, and the difference between technical anomalies and intentional manipulation.

Medical, Public, and Third-Party Data

Medical data can be relevant to health, travel, disability, and bodily injury claims, but it is highly sensitive and subject to strict legal and professional controls. Public records and third-party data may include weather, geospatial, vehicle, business, sanctions, court, repair-cost, or mortality information, depending on jurisdiction and lawful access. External data must be assessed for provenance, update frequency, coverage bias, licensing restrictions, and compatibility with the insurer's purpose.

From Source Records to a Governed Analytical Model

A practical insurance analytical model is generally entity-event based. Core entities may include Customer, Policy, Vehicle, Property, Claim, Payment, Provider, Intermediary, Document, and Location. Events include quotation, policy issuance, amendment, cancellation, premium payment, loss notification, assessment, reserve change, repair, legal action, and settlement.

Relationships should be explicit. A customer may own several policies; a policy may cover several objects; a claim may involve multiple customers, providers, and payments. A graph representation can complement relational tables where relationships and networks are central to the analysis. For example, a shared address or bank account may link claims, but the relationship should include its type, validity period, source, and confidence.

A typical ingestion process involves:

1. Source assessment: identify owners, structures, business definitions, frequency, lawful purpose, and known limitations.

2. Controlled ingestion: capture data with source timestamps, batch identifiers, schema versions, and error logs.

3. Standardisation: harmonise formats for dates, currencies, locations, codes, names, and identifiers.

4. Entity resolution: connect records that refer to the same person, object, or organisation.

5. Conformance: establish shared dimensions and definitions across systems.

6. Validation: test business rules, referential integrity, ranges, duplicates, and reconciliation totals.

7. Curation: publish approved analytical tables, labels, and features with documentation.

8. Monitoring: track quality, drift, access, model performance, and downstream use.

This is not a one-time data-cleaning project. New products, vendors, regulations, fraud tactics, and system changes continuously alter the data environment.

Data Quality as an Analytical Control

Data quality is fitness for a defined purpose, not an abstract claim that data is simply “good” or “bad.” The same field may be adequate for billing but inadequate for fraud detection. Quality should therefore be measured against a use case and a decision point.

The principal dimensions are:

• Accuracy: whether a value correctly represents the real-world condition.
• Completeness: whether required values are present.
• Validity: whether values conform to permitted formats, ranges, and codes.
• Consistency: whether related systems and records agree.
• Uniqueness: whether an entity or event has been duplicated improperly.
• Timeliness: whether information is available and current when needed.
• Integrity: whether relationships between records are preserved.
• Traceability: whether the origin and transformations of a value are known.

Quality rules should be specific. For example, a claim payment should not precede the claim's notification without an explainable exception; an expiry date should not precede inception; a vehicle identification number should meet the accepted format; and total payment transactions should reconcile to the general ledger within an approved tolerance.

A data-quality score can support monitoring, but a single score can conceal serious defects. A dataset with 98 percent completeness may still be unusable if the missing two percent consists disproportionately of high-value claims. Quality dashboards should therefore show distribution, population segments, time trends, and critical-field exceptions.

Identity Resolution and the Risk of False Association

Identity resolution, or entity resolution, determines whether records refer to the same real-world entity. Deterministic matching uses reliable identifiers such as a verified policy number or a securely tokenised identity number. Probabilistic matching compares fields such as name, address, telephone, email, date of birth, device, and payment reference, assigning a confidence score.

A robust process commonly includes standardisation, blocking, candidate generation, scoring, review thresholds, and feedback. Blocking limits comparisons to plausible candidates, such as records sharing a postal region or phonetic surname. A matching model may assign greater weight to a verified identity number than to a shared address. Human review is appropriate for high-impact or uncertain matches.

Errors have asymmetric consequences. A false negative fragments a fraud network and reduces detection power. A false positive links innocent people and may lead to unjustified investigation, reputational damage, or adverse treatment. Match confidence and evidence should therefore be stored rather than replaced by a simple yes/no decision.

Identity resolution must also account for legitimate shared attributes. Families may share addresses and telephone numbers; businesses may use common directors; repair networks may share payment services; and agents may submit claims on behalf of many customers. A shared attribute is a relationship to investigate, not a conclusion of fraud.

Missingness, Bias, and Target Leakage

Missing data is often treated as a technical inconvenience, but missingness can carry operational meaning. A field may be missing because it was not relevant, because a process failed, because a customer declined to provide it, or because a case has not reached the stage at which the field is created. These mechanisms are often described as missing completely at random, missing at random, and missing not at random. In insurance, the third category is common: missingness may reflect claim complexity, customer vulnerability, channel, or suspected risk.

Appropriate treatment depends on meaning. Options include explicit missing categories, statistical imputation, model-based approaches, exclusion, or process correction. Imputation must be performed within the training process to avoid using information from validation or future periods. Missingness indicators can be useful, but they should not become covert proxies for protected characteristics or administrative disadvantage.

Bias can enter through historical decisions, unequal data coverage, selective investigation, under-reporting, proxy variables, or labels based on investigator outcomes rather than confirmed fraud. If only investigated claims receive a fraud label, a model may learn investigator selection rather than fraud behaviour. If telematics is available mainly to digitally engaged customers, its use may disadvantage customers without access or consent.

Target leakage occurs when a predictor contains information that would not have been available at the decision time or is directly caused by the outcome. Examples include final settlement, investigation referral status, post-claim legal expenses, a fraud-confirmation code entered after review, or a document uploaded after an investigator requests it. Leakage produces impressive historical performance and poor real-world performance. Every feature should have an “as-of” timestamp and a clearly defined availability rule.

A useful control is point-in-time reconstruction: for each historical claim, recreate the information set that existed at the moment the score would have been generated. Time-based validation is generally more realistic than random splitting when processes, products, and fraud patterns change over time.

Data Lineage and Governance

Data lineage records where data originated, how it changed, who approved the transformation, when it was updated, and where it is used. At field level, lineage may connect a fraud feature such as “number of prior claims in 180 days” to claim transactions, their status definitions, the time window, exclusions, and code version.

Governance assigns accountability. A data owner is responsible for the business meaning and acceptable use of a domain. A data steward manages definitions, quality rules, metadata, and issue resolution. Technology teams operate pipelines and controls. Model risk, compliance, privacy, security, and fraud functions provide challenge and oversight.

A data catalogue should document business definitions, technical names, permissible values, sensitivity classification, retention period, owner, quality status, and lineage. A change-control process is necessary because a renamed code or altered claims status can change model behaviour without changing the model code.

Governance also requires access controls, encryption, tokenisation, segregation of duties, retention and deletion rules, incident management, and audit logs. Data should be collected and used for specified lawful purposes, with access limited to what is necessary. Sensitive medical and identity information generally requires stronger controls than aggregated operational measures.

Governed Analytical Datasets and Fraud Feature Stores

A governed analytical dataset is a documented, versioned, quality-tested collection prepared for a defined analytical purpose. It should specify the population, observation period, outcome label, inclusion and exclusion rules, point-in-time logic, feature definitions, treatment of missing values, and approval status. Reproducibility matters: a later analyst should be able to recreate the dataset or explain why it changed.

A fraud feature store manages reusable features for model training, batch scoring, and real-time decisions. Examples include claim frequency over a defined period, time since policy inception, ratio of reported to paid claims, number of linked entities, distance between declared loss and repair location, and payment-account reuse. Each feature requires an owner, definition, source, transformation code, freshness expectation, quality tests, access policy, and historical version.

Feature stores reduce duplicated logic and training-serving skew, in which a feature is calculated differently during development and production. They do not eliminate risk. A feature may still be biased, unstable, leaked, or unfairly proxying a protected attribute. Feature approval should therefore include business, technical, fraud, compliance, and ethics review where appropriate.

Labels deserve particular attention. “Fraud” may mean confirmed criminal fraud, successful recovery, internal referral, repudiation, or an investigator's suspicion. These are different outcomes. A modelling project must define the label, its observation window, unresolved cases, class imbalance, and possible label delay. Weak labels may still be useful for prioritisation, but their limitations must be communicated.

Applied Case: Integrating Motor Claims Data

Background

The following is an illustrative case. Meridian Motor Insurance operates policy, billing, claims, telematics, and repair-provider systems acquired at different times. Fraud analysts report that existing rules generate many referrals but few confirmed cases.

Situation and Problem

The organisation discovers that a customer may appear under several spellings, vehicle identifiers are missing in 12 percent of claims, repair payments are recorded separately from claim payments, and the investigation outcome field is sometimes populated after referral. The existing model includes total paid amount and investigation status, although both are unavailable at first notification.

Analysis

A data assessment shows that the high referral rate is partly caused by duplicate claims created during system migration. Provider names are inconsistent, making concentration analysis unreliable. Telematics coverage is concentrated among customers who selected an optional device, so its absence cannot be interpreted as risky driving. Historical confirmed-fraud labels are also more common among claims selected by experienced investigators, creating selection bias.

Approach and Solution

Meridian creates a canonical claim event model retaining notification, assessment, reserve, payment, and closure events separately. It introduces stable internal entity keys and a probabilistic customer-resolution process with manual review for high-impact matches. Provider identifiers are standardised using registration and contract data. The modelling team removes post-referral fields, creates point-in-time snapshots, and validates performance using later months rather than random splits.

A feature store publishes versioned features such as prior claims count, linked payment accounts, policy-age bands, and provider concentration. Each feature includes an as-of timestamp and quality flag. Telematics features are used only for customers with valid consent and sufficient device coverage; the model does not treat non-participation as a negative behavioural signal. Governance approves a limited-access dataset, and investigators receive explanations and source links rather than an unexplained score.

Outcome

The revised process produces fewer but better-supported referrals. Analysts can trace each alert to claim events and source records, while model monitoring identifies deterioration when a new claims platform changes coding practices. The organisation also establishes a feedback process in which confirmed outcomes and overturned referrals are reviewed separately.

Learning Points

The case demonstrates that fraud analytics improves when data architecture preserves event time, identity confidence, source lineage, and label meaning. Removing leakage may reduce apparent model performance while increasing operational validity. Better data quality does not mean collecting every available field; it means creating reliable, lawful, decision-relevant evidence.

Challenges, Risks, and Common Mistakes

Several failures recur in insurance data programmes. A “single customer view” may be pursued without clear identity confidence, creating dangerous false links. Data lakes may accumulate ungoverned copies that cannot be interpreted. Teams may optimise for ingestion volume rather than usability. Random train-test splits may conceal time leakage. Analysts may delete missing records without investigating why they are missing. External data may be purchased without validating licensing, population coverage, or update frequency.

Other risks include excessive dependence on vendor scores, undocumented manual adjustments, weak reconciliation with finance, ambiguous labels, unstable codes, and model features that encode protected or vulnerable characteristics. Operational teams may also resist governance if controls are perceived as slowing investigations. Governance is more effective when it provides reusable standards, automated tests, clear service levels, and rapid escalation rather than only prohibitions.

Ethical, Regulatory, and Professional Considerations

Fraud prevention must be proportionate. Suspicion should trigger appropriate review, not automatic accusation or denial. Customers should not be treated adversely because of a weak association, a missing field, a shared address, or membership in a group that historically received more scrutiny. Where law requires notice, explanation, access, correction, or appeal, data and model processes must support those rights.

Privacy principles include purpose limitation, data minimisation, accuracy, security, retention control, and accountability. Medical, biometric, identity, location, and financial data require heightened care. Data sharing with intermediaries and vendors should specify purpose, security, retention, breach duties, audit rights, and deletion or return arrangements.

Professional practice requires analysts to document assumptions, disclose limitations, test disparate impacts where relevant, preserve audit evidence, and distinguish a predictive association from proof of wrongdoing. Human investigators remain accountable for consequential decisions, even when automated tools assist prioritisation.

Technology and Emerging Developments

Cloud lakehouses, streaming platforms, graph databases, privacy-enhancing technologies, and feature-management platforms are increasingly used in insurance analytics. Streaming architecture can support near-real-time payment or device monitoring, while graph analytics can expose relationships among persons, vehicles, addresses, providers, and accounts. Natural-language processing and computer vision may extract information from statements, invoices, photographs, and medical or repair documents.

These technologies increase capability but also expand attack surfaces and governance demands. Generative AI may assist document summarisation or query generation, but outputs require validation, access controls, protection against confidential-data exposure, and clear accountability. Synthetic data can support development where direct access is restricted, although it may fail to reproduce rare fraud patterns or preserve privacy under all conditions.

Emerging practice is moving toward data contracts, in which producers specify schemas, meanings, quality expectations, and change notifications; data observability, which monitors freshness, volume, distribution, and schema drift; and privacy-preserving linkage, which enables controlled comparison without exposing raw identifiers. These developments are valuable only when connected to business ownership and decision controls.

Best-Practice Principles

A mature insurance fraud data capability should:

• begin with a defined decision, population, and point in time;
• preserve source records and event history rather than overwriting them;
• use stable identifiers, confidence-based identity resolution, and human review for uncertain links;
• define data quality rules for critical fields and monitor them by segment and time;
• separate information available at scoring from information created after investigation;
• document labels, transformations, lineage, ownership, access, and retention;
• validate models with time-aware, point-in-time datasets;
• treat missingness and external-data coverage as potential sources of bias;
• version analytical datasets and features;
• reconcile operational, financial, and analytical records;
• provide investigators with evidence and explanations;
• test privacy, security, fairness, and resilience as part of the lifecycle; and
• review architecture whenever products, systems, vendors, regulations, or fraud patterns change.

Chapter Summary

Insurance fraud analytics depends on an integrated and governed data architecture. Policy, claims, billing, customer, intermediary, provider, telematics, medical, public, and third-party data describe different aspects of the insurance relationship and must be connected without losing source context or event time. Entity resolution creates a usable view of people, objects, and organisations, but uncertain matches must be represented and reviewed.

Data quality is multidimensional and purpose-dependent. Completeness, accuracy, validity, consistency, uniqueness, timeliness, integrity, and traceability should be measured through business rules and monitored by population and time. Missingness may contain operational or social signals, bias may enter through historical investigation and unequal coverage, and leakage can make models appear successful while failing in practice. Point-in-time datasets and time-aware validation are essential controls.

Data lineage, ownership, access control, privacy, and change management make analytical work defensible. Governed datasets and feature stores improve reproducibility and reduce training-serving differences, but they do not replace ethical and professional judgement. The central principle is that reliable fraud decisions arise from reliable, explainable, lawfully used evidence—not merely from advanced algorithms.

Key Terms

Analytical dataset: A documented and prepared collection of data for a defined analytical purpose.

Data architecture: The design of data sources, storage, integration, governance, access, and use.

Data lineage: The record of a data element’s origin, transformations, movement, and downstream use.

Data quality: The fitness of data for a specified purpose and decision.

Entity resolution: The process of determining which records refer to the same real-world entity.

Feature store: A governed repository for reusable analytical features used in training and scoring.

Identity confidence: An assessment of how strongly records are believed to represent the same entity.

Point-in-time dataset: A dataset containing only information available at a specified decision time.

Target leakage: Use of information unavailable at decision time or caused by the outcome being predicted.

Missingness: The absence of an expected data value, often with a potentially meaningful cause.

Data bias: Systematic distortion arising from collection, coverage, labels, processes, or historical decisions.

Conformed data: Data standardised so that shared entities and definitions are consistent across systems.

Data steward: A person responsible for definitions, quality rules, metadata, and issue coordination.

Data owner: The accountable business authority for a data domain and its acceptable use.

Canonical model: A common representation of entities, events, and relationships across source systems.

Training-serving skew: Difference between how a feature is calculated in development and production.

Label: The outcome or target assigned to an observation for analytical or modelling purposes.

Data contract: An agreed specification of a dataset’s schema, meaning, quality, and change obligations.

Review Questions

Short Answer Questions

1. Why is a system of analysis different from a system of record?

2. List four dimensions of insurance data quality and explain one.

3. What is identity resolution, and why can it create both false negatives and false positives?

4. Define target leakage with one insurance example.

5. What information should accompany a feature in a governed feature store?

Long Answer Questions

1. Explain how policy, claims, billing, customer, intermediary, and provider data can be integrated for fraud analytics.

2. Discuss the importance of event time, point-in-time reconstruction, and time-based validation.

3. Analyse how missingness and historical investigation practices can introduce bias into fraud models.

4. Describe the governance framework required for a reliable analytical dataset.

5. Explain the role, benefits, and limitations of a fraud feature store.

Analytical / Application Questions

1. An insurer’s model uses final settlement amount, investigation status, and claim closure reason to triage claims at first notification. Identify the leakage risks and redesign the feature set.

2. Two claimants share an address, telephone number, repairer, and payment account, but have different names and vehicles. Design an identity-resolution and investigation approach that avoids automatically treating them as a fraud network.

3. A telematics feature improves model accuracy, but only 20 percent of customers have opted into the programme. Evaluate the fairness and governance risks and recommend how the feature should be used.

22. Multiple Choice Questions with Answers

Question 1

Which architectural principle most directly prevents a fraud model from using information created after a claim was referred?

A. Storing all data in a single table

B. Point-in-time feature construction

C. Removing all missing values

D. Using only external data

Correct Answer: B. Point-in-time feature construction

Question 2

A shared address appears in claims involving several unrelated policyholders. What is the most appropriate interpretation?

A. It proves the policyholders are committing fraud

B. It should be ignored because addresses are unreliable

C. It is a relationship requiring contextual investigation

D. It should automatically merge all customer records

Correct Answer: C. It is a relationship requiring contextual investigation

Question 3

Which data-quality dimension asks whether a value conforms to an approved format or range?

A. Validity

B. Timeliness

C. Uniqueness

D. Completeness

Correct Answer: A. Validity

Question 4

Why can a final settlement amount be an inappropriate feature for first-notification triage?

A. It is always missing from claims data

B. It is usually available only after later claim events

C. It cannot be stored in a feature store

D. It is unrelated to insurance claims

Correct Answer: B. It is usually available only after later claim events

Question 5

What is the principal purpose of data lineage?

A. To eliminate the need for data ownership

B. To show where data came from and how it was transformed

C. To replace access controls

D. To guarantee that a model is unbiased

Correct Answer: B. To show where data came from and how it was transformed

Question 6

Which situation is most likely to produce target leakage?

A. Using policy age at the time of claim notification

B. Using the number of prior claims known before notification

C. Using a fraud-confirmation code entered after investigation

D. Using the declared cause of loss

Correct Answer: C. Using a fraud-confirmation code entered after investigation

Question 7

What is a major risk of treating every record with a similar name as the same person?

A. False positive identity links

B. Improved data completeness

C. Reduced data latency

D. Automatic regulatory compliance

Correct Answer: A. False positive identity links

Question 8

A feature store primarily helps an insurer to:

A. Replace all source systems

B. Manage reusable, versioned features consistently across training and scoring

C. Decide guilt without human review

D. Remove the need for model monitoring

Correct Answer: B. Manage reusable, versioned features consistently across training and scoring

Question 9

Why might missing telematics data not be treated as evidence of risky driving?

A. Telematics data is never useful

B. Absence may reflect lack of consent or coverage rather than behaviour

C. Missing data always means the customer is low risk

D. Telematics cannot be legally stored

Correct Answer: B. Absence may reflect lack of consent or coverage rather than behaviour

Question 10

Which validation approach is generally most realistic when fraud patterns and processes change over time?

A. Randomly mixing all historical records

B. Testing only on the training sample

C. Time-based validation using later observations

D. Removing all older claims

Correct Answer: C. Time-based validation using later observations