Motor third-party liability insurance is compulsory across EU member states under the Motor Insurance Directive. Every vehicle on a public road must have it. This near-universal mandatory purchase makes MTPL the largest single line of motor insurance by policy count across most European markets.
Yet MTPL is systematically underwritten with less vehicle-specific data than many optional motor products. This is not accidental. It reflects how the product was designed and where the regulatory minimum sits. The consequences for pricing accuracy deserve more attention than they receive.
What MTPL Pricing Typically Uses
In practice, MTPL pricing across EU markets is primarily driven by policyholder attributes: driving history, no-claims bonus record, geographic zone, age, and annual declared mileage. Vehicle attributes contribute, but often in broad categories: vehicle make and model group, engine capacity, vehicle age in years, and purchase price band.
What is largely absent from the standard MTPL underwriting data set is verified vehicle history. The declared mileage is self-reported. The vehicle condition is assumed from its stated age and model. Whether the vehicle has a prior total loss, carries structural damage from a past incident, or has an ownership chain that passed through multiple jurisdictions in short succession: none of these are routinely queried at point of MTPL quote in most EU markets.
This is partly a data access problem and partly a cost-versus-benefit problem. MTPL premiums are price-sensitive. Adding a verification check to the underwriting process adds cost and potentially friction. Insurers have historically concluded that the marginal pricing benefit does not justify the process change at the high-volume, low-premium end of the book.
Why This Position Is Worth Revisiting
The cost argument against vehicle verification in MTPL made more sense when verification required manual checks. With an API-based verification pipeline that returns a structured risk signal within seconds, the cost per check has changed substantially. The friction argument is also weakening: VIN is already a required field in most MTPL applications. Running a verification query against a VIN that is already being captured does not introduce meaningful new friction into the application process.
The pricing benefit, meanwhile, is not trivial even at the MTPL level. MTPL covers third-party bodily injury and property damage. A vehicle with compromised structural integrity after an undisclosed total-loss event poses a meaningfully different risk profile for third-party injury severity than a clean vehicle of equivalent age. If the structural damage affects crash safety systems, the probability distribution of injury severity in an at-fault collision shifts. This is a vehicle risk characteristic, not a driver risk characteristic, and it is not captured by age and model-group pricing alone.
The Structural Integrity Gap
The total-loss scenario illustrates this most clearly. Under EU member state regulations, a vehicle assessed as a total loss following an accident is recorded with the competent authority. When the vehicle is subsequently repaired and returned to the road, the total-loss status remains on the registry record. The vehicle's structural systems, depending on the nature of the original damage, may be repaired to roadworthy standard without being restored to the original structural performance characteristics.
MTPL pricing by age and model group does not distinguish between a vehicle with a clean history and a vehicle with a prior total-loss record. Both receive the same vehicle-attribute pricing tier. The insurer writing the MTPL policy has no knowledge of which vehicle is which, because the check was not run.
A verification check at point of MTPL quote would not be expected to result in declining the application. MTPL is compulsory and must be available to all vehicles eligible for registration. But it could appropriately adjust the pricing tier for vehicles with verified structural history flags, reflecting the actual risk distribution rather than the model-group average. This is not discriminatory pricing; it is accurate pricing within the compulsory obligation framework.
The Declared Mileage Problem
Mileage is a primary MTPL rating factor in most markets. Annual declared mileage bands affect the premium materially. Self-declared mileage at application carries no registry-level verification in most EU MTPL workflows.
The consequence is straightforward: under-declared annual mileage reduces the premium, and there is limited systematic detection. Registry-sourced mileage data, where available from technical inspection records, provides a cross-check against the declared figure. A vehicle whose technical inspection odometer readings imply an annual average of 28,000 km cannot credibly support a declared annual mileage band of 10,000 km at the subsequent policy renewal.
We are aware this verification capability is not currently available at equal quality across all EU markets. Technical inspection odometer recording varies in its consistency, completeness, and API accessibility by country. This is an honest constraint on what registry reconciliation can do today, not an argument against running the check where coverage does exist. A partial mileage signal that catches material discrepancies in accessible markets is better than no check at all.
Where Registry Reconciliation Fits in the MTPL Workflow
The case for registry reconciliation in MTPL is not that it should replace existing policyholder-attribute pricing. Driver behavior and no-claims history remain the primary predictors of at-fault loss frequency, and that will not change. The case is that vehicle-specific verification fills a specific gap in the current data model that is currently priced by approximation rather than by observation.
A practical integration point is renewal rather than new business application. At renewal, the vehicle identifier is already confirmed and stable. Running a verification check at the annual renewal cycle allows the insurer to identify vehicles whose registry status has changed over the policy year, including new total-loss records, change of ownership structure, or technical inspection flags. The frequency and premium implications of this use case can be assessed empirically once the check is running.
For new business applications, the highest-value check is registration status confirmation plus total-loss and odometer signals, which together address the three most material vehicle risk gaps in current MTPL underwriting. Outstanding finance is less relevant to MTPL risk assessment (it affects title, not vehicle condition), though it remains important for finance-linked comprehensive products.
The Regulatory Direction
EU motor insurance regulation has historically focused on ensuring MTPL coverage availability and cross-border recognition, not on standardizing underwriting data inputs. The revised Motor Insurance Directive, which EU member states were in the process of implementing through 2024 and 2025, primarily addresses coverage scope, claims handling, and insolvency protection. It does not mandate vehicle verification at underwriting.
Regulatory pressure to improve data quality in MTPL is more likely to come through adjacent channels: anti-fraud frameworks, data portability obligations under the European Health Data Space and adjacent data act initiatives, and national regulatory guidance on actuarially fair pricing in mandatory products. These create an environment where the question of whether MTPL is priced on accurate vehicle data will receive more scrutiny than it has historically.
Insurers who build registry verification into MTPL workflows ahead of that scrutiny will be in a better position to demonstrate that their pricing reflects actual vehicle risk rather than category approximation. That is not primarily a regulatory argument. It is a pricing accuracy argument that happens to align with where the regulatory environment is heading.
GoodToKnow was built to make this check practical. A VIN-in, risk-signals-out API that fits inside an existing quoting workflow is the enabling layer. Whether to use it for MTPL, comprehensive, or both is an underwriting decision, and that is where it belongs.
