Pricing for price comparison websites: latency, volume and fair pricing rules

For many personal lines products in the UK, price comparison websites are where most customers start. Quoting on them brings access to large numbers of customers, but it also puts demands on pricing that other channels do not. Every request needs a fast, correct answer, the volume can be very high, and customers compare your price with everyone else's in the same view.

This article covers what your pricing needs to handle aggregator traffic well.

Response time

Price comparison websites wait a limited time for each insurer's response. A price that arrives too late may not be shown at all. That puts response time on the same level of importance as the price itself.

The time a quote takes depends on several things:

• The rating engine itself, and how quickly it evaluates the model.
• External data calls, such as address, vehicle or claims lookups, which are often the slowest part.
• Network distance between the aggregator, your systems and the rating engine.
• Your own processing before and after the pricing step.

Measure each part separately so you know where the time goes. The debug trace for a Ptally quote includes the time taken by every step, which makes slow steps easy to find.

Peak volume

Aggregator traffic is uneven. Volumes rise sharply at certain times of day, at the end of the month and around renewal peaks, and a marketing campaign can add more. Your pricing has to keep the same response time at the busiest point, not only on an average day.

Plan for capacity well above your normal peak, and test it. Load tests that replay realistic traffic patterns show how the system behaves before customers see it. Ptally serves millions of quotes a month and is live on price comparison websites, returning real-time prices at peak aggregator traffic.

Consistent prices across channels

A customer who sees one price on an aggregator and a different price when they click through to your website is likely to lose trust or abandon the purchase. Prices should differ between channels only where you have decided they should, for example where a commission differs, and that difference should be part of the model rather than a side effect of separate systems.

The simplest way to achieve this is to price every channel from one model. With a single rating engine serving the aggregator integration, your website forms and your API, a rate change reaches every channel at the same time.

Testing

On an aggregator, a pricing error can affect a large number of quotes very quickly. A price that is too low wins business you did not intend to write. A price that is too high stops you appearing near the top of the results.

Every model should have a test suite that runs on every change, covering:

• the worked examples from the rating guide;
• values on either side of each band boundary;
• every decline and referral rule;
• a sample of real aggregator quotes saved with their results.

Our article on regression testing for insurance pricing covers how to build and maintain this suite.

Fair pricing rules

In the UK, the FCA's general insurance pricing rules, in force since January 2022, stopped firms charging renewing home and motor customers more than they would charge an equivalent new customer through the same channel. This practice was often called price walking.

For pricing teams, this means the relationship between new business and renewal prices has to be controlled and evidenced. It helps to:

• keep renewal and new business logic in the same model, so the comparison is built in rather than checked afterwards;
• record which version priced every quote, so you can show how a given renewal price was set;
• test renewal cases against equivalent new business cases, so a rate change cannot break the rule without a test failing.

The FCA's Consumer Duty also expects firms to show that products offer fair value. A pricing model that is readable, versioned and tested makes that evidence much easier to produce. Our article on AI in regulated industries covers these expectations in more detail.

Monitoring after launch

Once a product is live on aggregators, monitor it closely. Useful measures include:

• response times at different points in the day, especially the slowest responses;
• error rates and timeouts;
• quote volumes and the share of quotes declined or referred;
• average premium compared with expectations;
• your position in the results for common risk profiles.

Sudden changes in any of these are often the first sign that something has changed, whether in your pricing, in a data source or in the market.

Getting started

Ptally runs pricing models that are built for aggregator traffic, tested on every change and served to every channel from one model. Our consultants build and manage the model for you. There is no implementation fee and nothing to pay upfront. Talk to our team about getting your product live on price comparison websites.