The one-screen insurance quote works because the platform already holds the data. Moving that data lawfully — consent, minimisation, purpose and record-keeping — is the part that decides whether the shortcut survives scrutiny.
The signature move of embedded insurance is the quote that needs no form: the platform already knows the vehicle, the traveller or the employee, passes that data across, and the customer sees a priced offer in one screen. Every part of that sentence is a data-protection event. This guide walks through the lawful mechanics — what data moves, on what basis, with what consent design, and with what records — so that the one-screen quote is a compliance asset rather than a liability with good conversion.
Two framing points first. This is a practitioner's guide, not legal advice; your counsel signs off your flow, not a blog. And while the principles below are broadly portable across modern data-protection regimes, we use Saudi Arabia's Personal Data Protection Law (PDPL) as the working example: it took effect on 14 September 2023, became fully enforceable after its grace period on 14 September 2024, and is supervised by the Saudi Data and Artificial Intelligence Authority (SDAIA). Any platform pre-filling quotes with Saudi customers' data is operating inside it.
What actually moves in a pre-filled quote
Before designing consent, inventory the flow. A typical embedded quote involves three data movements, and each needs its own justification.
- Platform to distribution layer: the customer's identifying details and the facts of the transaction — vehicle identifiers, trip details, employee census fields — sent to generate a quote.
- Distribution layer to insurer: the same data, or a subset, passed to the underwriting carrier (sometimes several, in comparison models) to price and later bind the risk.
- Back down the chain: the quote, the policy, the documents — plus, over time, servicing data such as endorsements and claims status.
The common design error is treating this as one disclosure. It is a chain of processing by different parties for different purposes, and the customer-facing consent has to honestly describe the chain — including, in comparison models, the fact that data reaches insurers who do not win the sale.
The lawful basis: consent is the default, not the only door
Modern regimes, PDPL included, recognise several bases for processing and disclosing personal data — the data subject's consent chief among them, alongside grounds such as legitimate interests in defined circumstances. For embedded quoting, our strong recommendation is to build on explicit consent even where a narrower basis might be argued, for three practical reasons. Consent is the basis the customer can see, which matters in a flow whose entire premise is trust. It is the basis that travels best across the multi-party chain described above. And it is the basis least likely to be second-guessed when a regulator, a partner insurer or a procurement team audits the programme.
Consent, to be worth the name, has to be real. In practice that means:
- Affirmative: the customer acts — a tap, a check — rather than failing to notice a pre-ticked box. Pre-filled data is the shortcut; pre-given consent is not.
- Specific: consent to share identified categories of data with identified categories of recipients for the purpose of quoting and issuing this insurance — not a general licence buried in signup terms accepted months earlier.
- Separable: declining the insurance data share must not break the underlying purchase. Bundled take-it-or-leave-it consent is the pattern regulators everywhere have learned to look for.
- Withdrawable: PDPL, like its international peers, recognises the right to withdraw consent — your architecture needs a way to receive that withdrawal and propagate it down the chain.
Minimisation: pre-fill is not bulk transfer
The pre-fill shortcut tempts platforms into sending everything they hold and letting the insurer pick. Data minimisation — a core PDPL principle, as its guidance on limiting collection to what a specific purpose strictly requires makes explicit — runs exactly opposite: send the fields the quote needs, and nothing else. In practice this means maintaining a field-level schema per product: motor quoting needs the vehicle and driver facts, not the customer's order history; travel medical needs the trip and traveller, not the payment instrument. The discipline pays twice — it shrinks your regulatory exposure, and it shortens the security review every serious insurer will run on you.
A related trap: enrichment drift. Programmes that begin with clean quote-only data flows sometimes drift into using insurance-flow data for marketing, or platform behavioural data for underwriting, without revisiting the consent that authorised neither. Purpose limitation is not a launch-day checkbox; it is a standing constraint on what both sides may later build.
The pre-fill interaction itself
Lawful mechanics extend into the interface. Three design rules keep the one-screen quote honest:
- Show the data being used. A quote screen that displays the vehicle, dates or names it was priced on lets the customer correct errors — which is simultaneously a data-quality control, an accuracy right in action, and protection against issuing policies on wrong facts.
- Distinguish pre-fill from commitment. Filling the form for the customer is service; submitting it for them is not. The binding action stays with the customer, unambiguous and unpre-triggered.
- Disclose the parties. The customer should be able to see, before buying, who insures the risk and who processed their data to get there. In an embedded chain this is also simply accurate expectation-setting for claims day.
Records: consent that cannot be evidenced does not exist
When scrutiny arrives — from SDAIA, from the Insurance Authority's conduct side, from a partner insurer's audit — the question is never whether your flow was designed to capture consent. It is whether you can produce, for one specific policy sold at one specific timestamp, the consent record: what the customer saw, what version of the wording, what they affirmed, and what data then moved to whom. That demands versioned consent copy, per-event logging keyed to the policy, and retention aligned to the policy's life and the regulator's clock. This record-keeping is unglamorous, is precisely the sort of thing an orchestration layer should provide by default, and is the first thing to verify when evaluating one.
A closing note on trust
It is tempting to read all of the above as compliance overhead on a growth feature. The better reading is that the lawful mechanics are the growth feature. The one-screen quote works because the customer trusts the platform enough not to interrogate the shortcut; visible consent, visible data, and a clean answer when someone finally does interrogate it are what keep that trust earning. The programmes that treat data protection as conversion friction eventually meet the regulator; the ones that treat it as product design rarely need to.