Building an API that returns a vehicle risk score in real time sounds straightforward until you look at what "real time" actually requires in a motor insurance quoting context. The consumer is typically a rating engine making a synchronous call mid-quote flow, waiting for the verification result before presenting a premium to the applicant. If the response takes too long, the quote either stalls or the insurer's system decides the check has failed and falls back to a default risk assumption.
Getting this right requires making explicit tradeoffs between three properties that pull against each other: how fresh the source data is, how deeply the pipeline reconciles across sources, and how fast the response returns. There is no configuration where all three properties are simultaneously maximized.
The Latency Constraint Is Tighter Than It Looks
An insurer's quoting system typically has a total timeout budget for third-party enrichment calls. Within that budget, the vehicle verification call competes with other enrichment queries. It is not the only external call in the quoting flow.
This means the risk API needs to return a usable response within a time window that is set by the consumer's overall flow, not negotiated independently. The API cannot simply say "we take as long as we need to get good data." The consumer will time out and move on.
Designing for a quoting-context API therefore starts with a practical latency target, not a quality-of-data target. The quality of data is then maximized within that constraint. This is a different design philosophy than building for batch processing, where the timeout window is much longer and the reconciliation depth can be greater.
Source Query Strategy: Parallel Dispatch with Bounded Timeouts
The central architecture decision for a real-time vehicle risk API is how to handle the multi-source query without accumulating source latencies serially.
We dispatch queries to source registries in parallel where the source API supports concurrent requests. Each source query runs with an individual timeout bound. Sources that respond within the budget contribute their data to the reconciliation stage. Sources that exceed the timeout are dropped from the current response, and the affected signals carry a reduced confidence marker to reflect the incomplete source coverage.
This design means a response that arrives within the latency budget will always be returned, but the confidence distribution of signals within that response may vary depending on which sources responded in time. A fast-responding primary registry might contribute registration status and ownership chain with high confidence. A slower secondary source that tracks incident records might time out and contribute only a "no data within timeout" marker rather than a confirmed or unconfirmed incident record.
The alternative, waiting for all sources to respond before returning, would eliminate the confidence variability problem but would regularly exceed the latency budget when any single source is slow. In a synchronous quoting flow, a consistent budget-compliance answer with variable confidence is more useful than an occasionally perfect answer that occasionally stalls the quote.
Caching: Where Source Freshness Meets Response Speed
The tension between source freshness and latency is most visibly managed through caching strategy. Registry data for a given VIN does not change minute to minute. A vehicle's registration status, ownership count, and total-loss record are stable for extended periods. An odometer value updates at technical inspection events, which typically occur at one or two-year intervals depending on vehicle age and jurisdiction.
A cached response that is 48 hours old for a registration status check is almost certainly still accurate. A cached odometer reading from 14 months ago might be missing an inspection event that occurred in the interim. The staleness risk is not uniform across signal types.
Our caching logic differentiates by signal stability. Registration status and ownership chain have longer cache windows because they change infrequently and the cost of serving a stale response is low. Odometer integrity signals have shorter cache windows because the data updates at defined inspection intervals and the cost of a stale reading is higher relative to the pricing decision.
For vehicles that are actively on the market or recently transferred, we apply a cache bypass for signals most likely to have changed at transfer time. Ownership chain transitions are the trigger. When a VIN arrives that we know recently changed registration ownership (visible in the registry update timestamps), the cache for that VIN's signals is treated as stale regardless of age.
Reconciliation Depth vs. Response Time
Full reconciliation across all source responses for a given VIN takes measurably more time than returning the first available response from the fastest source. The reconciliation stage checks for internal consistency across sources, normalizes units, and applies confidence weighting. This work adds time to the response path.
We made a deliberate choice to always perform full reconciliation rather than early-returning the first source response. The reason is that the first-source-response model creates unpredictable signal quality depending on which source happens to respond fastest. A fast response that contains an undetected inconsistency because the slower corroborating source had not yet been checked is worse, from an underwriting perspective, than a slightly slower response where the inconsistency would have been surfaced.
The bound we have placed on reconciliation time is that it must complete within a fixed portion of the total latency budget, using whatever source responses have arrived by that point. If additional source responses arrive after the reconciliation window closes, they are stored in the VIN cache to improve confidence on subsequent queries for the same vehicle, but they do not hold up the current response.
Reliability Patterns: Degraded-Mode Operation
Source registry APIs are not uniformly reliable. National registry infrastructure across EU member states includes legacy systems with documented maintenance windows, rate-limiting behaviours under load, and occasional unscheduled outages. An API that depends entirely on upstream registry availability would inherit the reliability characteristics of the least reliable source in its dependency chain.
The design approach is to build for degraded-mode operation as a first-class state rather than an exceptional state. The API distinguishes between three response postures: full coverage (all expected source queries returned within timeout), partial coverage (some source queries timed out or returned errors, confidence markers reduced for affected signals), and minimum viable response (primary registry returned but secondary sources unavailable, only primary-registry signals returned with explicit coverage notes).
In minimum viable mode, the consumer receives a partial risk signal rather than an error. The partial signal includes explicit markers identifying which signal categories lacked source data. A rating engine consuming this response can decide whether to proceed with the available signals, escalate to a manual review queue, or fall back to its own default risk assumption. The API informs that decision; it does not make it.
An API that returns an error response when a secondary source is unavailable forces the consumer to treat the entire check as failed. An API that returns a partial response with clear signal coverage markers preserves the value of the data that was available. This distinction matters during real-world source outages, which are periodic rather than rare.
What We Deliberately Did Not Build Into the Real-Time Path
Two capabilities that some vehicle data products include in their primary response are outside our synchronous query path by design.
First, market valuation estimates. Real-time market valuation requires aggregating and weighting marketplace listing data, which is higher latency and more processing-intensive than registry queries. We return a residual value band based on registry-sourced vehicle specification and age data, not a live market price estimate. The distinction matters: the residual value band is a structural characteristic of the vehicle class. A live market price estimate is a snapshot of current listing activity. Both are useful, but they come from different data processes and belong in different product tiers.
Second, recall status from manufacturer databases. Recall data is not consistently accessible through registry APIs across EU jurisdictions. Some markets expose recall records through the primary vehicle registry. Others require separate queries to national road authority databases that have variable API maturity. Including recall status in the synchronous path would make the response time dependent on the slowest and least reliable source in the chain. We include recall status where it is accessible without exceeding budget, and mark it absent where coverage does not reach it. Absent is an honest answer. A synthetic value derived from incomplete coverage is not.
These are not gaps we expect to leave permanent. As registry API coverage matures across EU markets, the practical constraints around recall coverage will change. The architecture is built to absorb new source integrations without restructuring the reconciliation logic, which is why the confidence-and-coverage model was designed this way from the start.
