What arrives from an aggregator is not a customer
On your own site the customer describes the risk once, to you, and every field they enter costs them effort. On an aggregator they describe it once to the aggregator, which fans that single description out to a panel of insurers and ranks the answers by price. You are one of the answers. The customer never sees your brand until they have already decided on a number, and they can re-run the whole exercise as often as they like at almost no cost to themselves.
That asymmetry sets everything else. You are being asked to price a risk you did not gather the data for, in a fixed and short time window, against competitors who receive exactly the same data, in a context where the customer's only visible decision variable is your premium. Repeated presentation of the same risk is therefore not an anomaly to be filtered out. It is the normal behaviour of the channel, and the design has to hold an opinion about it.
Five requests are one risk, and you have to be able to say so
The first thing to build is identity. Without it you have five unrelated quotes, five sets of enrichment calls, five audit trails and no way to see the shape of what happened. With it you have one risk with a version history, which is a far more useful object: you can see what changed between attempts, in which direction the premium moved, and which version was finally taken up.
Resolution here is probabilistic rather than exact, because the whole point of the exercise is that something differs each time. The stable signals are the ones the customer is not editing: the address, the date of birth, the vehicle or property identifier. The ones being edited are precisely the ones you want to record as having been edited. What you are constructing is closer to entity resolution over quote attempts than to a deduplication key, and the honest design keeps every attempt and links them, rather than trying to decide which one is canonical.
An aggregator gives every insurer on the panel the same short window to answer. Miss it and you are simply not on the list; there is no degraded appearance, no partial credit and no retry. That converts what looks like a latency requirement into a revenue question, and it is the reason quote paths in this channel are architected differently from anything else in a policy administration estate.
The pressure falls on external data. A competitive price usually depends on enrichment the customer did not supply: vehicle characteristics, property attributes, claims and conviction history from shared industry databases, credit-derived signals where the jurisdiction permits them. Each of those is a call to somebody else's system, each has its own latency distribution and its own availability, and each has a price per call. So the design questions are which enrichments are needed to price at all, which merely refine the price, and what the fallback price is when a provider is slow.
The usual resolution is staged. Enrich in parallel rather than in sequence, with a hard deadline; price on whatever has returned by the deadline, using a deliberately cautious assumption in place of anything missing; and record which enrichments contributed, so that the quote remains reproducible. A quote priced without claims history is a different quote from one priced with it, and if that distinction is not stored, nobody can later explain why two apparently identical risks were charged differently.
Volume you pay for and do not convert
Because a single customer's shopping session generates many quotes across the panel, the ratio of quotes to policies in this channel is far worse than on your own site, and every quote consumes real money in enrichment calls and compute. Work the arithmetic explicitly rather than asserting it: if enrichment costs a penny per quote and you bind one policy in every two hundred quotes you serve, you have spent two pounds of acquisition cost before commission, and that has to sit inside the expense loading in the rate. Caching an enrichment result against a resolved risk for a short, defensible window is the single largest lever on that cost, and the version history you built for identity is what makes the cache safe.
Small edits are price probing, and they select against you
Now the part that reaches the loss ratio. When a customer changes an annual mileage estimate, adjusts an occupation description, removes an optional cover, or adds a parent as a named driver on a young driver's policy, they are not correcting a record. They are searching the price surface for the cheapest description of themselves that they believe the insurer will accept. Across a panel this is efficient: whichever insurer's rating structure is most sensitive to the edited factor becomes the cheapest quote and wins the risk.
The consequence is structural rather than incidental. Your aggregator book is systematically composed of the risks where your rate is softest relative to the market, which is a very different population from the risks where your rate is most accurate. And the description you have bound is the most flattering version the customer could construct, so the difference between the declared risk and the real one is larger in this channel than in any other. That is where the losses appear, and it is why aggregator experience has to be modelled as its own segment rather than blended into the direct book.
The controls are mostly about seeing it. Store the edit sequence, so a risk that reached its final price through several attempts is flagged as such. Validate the volatile factors against external data where you can, at quote rather than at claim, since discovering a misdescription at claim leaves you handling a complaint about a decision the customer will say they made in good faith. And treat monotonic edit patterns, where every change moves the premium in the same direction, as the signal they are, routing the extreme cases to a check rather than declining silently.
The number on the screen has to be the number you honour
The customer clicks through carrying a reference to a quote they were shown. Whether you re-rate on arrival or honour the stored premium is a decision, not a default, and re-rating quietly is how an insurer generates complaints at scale: the price on the comparison screen was a promise as far as the customer is concerned.
The workable position is that a quote is pinned to its inputs, its rate version and its enrichment set for a stated validity period, and any change in premium after that is traceable to a change the customer made rather than to a change you made. Where regulators have intervened in this channel, it has generally been on exactly this ground, the gap between the price a customer is quoted and what they eventually pay, so the audit trail here is as much a compliance artefact as a service one.
Everything about the aggregator channel is calibrated on price alone, which means your book fills with the risks your own rating structure most underprices, described in the most favourable terms the customer could find. If you cannot see the edit history behind a bound quote, you cannot see that happening.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).