Three minutes is a specific number that we state publicly and I want to explain where it comes from, because it is not a marketing figure — it is an engineering constraint. The question we started with when building the Indie platform was not "how do we make insurance faster" in the abstract. It was "what is actually taking the time in a traditional insurance application, and which of those steps can be eliminated without compromising legal validity or risk accuracy?"
The answer turns out to be: most of it. A traditional insurance application takes days or weeks because of manual underwriting review, document verification queues, back-office policy issuance processes, and physical or PDF mail. Almost none of those steps are legally required. They are organisational artifacts from a time when the alternative — running a risk model in real time and generating a policy document programmatically — did not exist.
The six inputs and why they are enough
For an auto policy, we ask six questions. Most people's instinct is that six inputs cannot possibly capture enough information to price a risk accurately. That instinct is wrong in an interesting way. It confuses the number of inputs with the quality of inputs.
A traditional actuarial rate table for auto insurance might have 40 or 50 input cells — but a large portion of those inputs are proxies. Age is a proxy for experience. Occupation is a proxy for typical driving patterns. Marital status historically correlated with risk in demographic studies. These proxies exist because insurers could not directly observe the things they actually care about: how much you drive, how you drive, where you park, and what you claim.
Our six inputs — vehicle matrícula, annual kilometres, primary use, overnight parking, licence tenure, and recent claims history — are closer to the actual risk factors than most of the demographic proxies. Annual kilometres is a direct predictor of exposure (more kilometres driven equals more opportunity for an incident). Overnight parking in a private garage versus street parking is a direct predictor of theft probability, which is a meaningful component of comprehensive claims. The vehicle matrícula gives us the make, model, age, and category, which directly predicts repair costs.
We are not saying six questions is always better than forty questions. We are saying that six well-chosen questions, fed into a model trained on actual Portuguese claims data, outperform forty generic demographic inputs for the population we serve.
The pricing model: gradient boosting on actuarial features
The core of our pricing engine is a gradient-boosted tree model. For an auto policy, the model takes the six inputs (plus some derived features — for example, vehicle age is derived from the matrícula and the current date, and the combination of annual kilometres and primary use gives us an estimated weekly kilometres figure) and outputs an expected loss cost.
Expected loss cost is the actuarial term for what the insurer expects to pay out in claims, on average, for a given risk profile. This is different from the premium. The premium is expected loss cost, plus a loading for expenses and profit margin, plus a capital charge for tail risk. The capital charge is where the ASF's solvency requirements bite — under the Solvency II directive as transposed into Portuguese law, every insurer must hold capital sufficient to survive a 1-in-200-year loss event. Our underwriting partners maintain these reserves; our model's job is to produce an accurate expected loss cost so the reserves are sized correctly.
The model was trained on historical claims data from the Portuguese auto insurance market. We cannot disclose the source or exact volume of that data. What we can say is that the training set covers a geographically diverse sample of Portuguese policies, spans multiple policy years, and was processed in compliance with RGPD (the Portuguese implementation of GDPR) — all individual identifiers were removed before the data was used in model training.
What happens in 180 seconds
When you submit your six answers, here is the actual sequence of system calls:
- Vehicle lookup (0.3s): The matrícula is sent to the vehicle registry API to retrieve technical data — make, model, year, fuel type, and vehicle category. This is the same data source that notaries and dealers use for vehicle transactions in Portugal.
- Model inference (0.1s): The six inputs plus derived features are passed to the pricing model. The model runs on our inference infrastructure and returns an expected loss cost with a confidence interval. The confidence interval is used internally — we widen the margin slightly for inputs where the model is less certain, which is the actuarially conservative thing to do.
- Premium calculation (0.05s): Expected loss cost, expense loading, capital charge, and applicable taxes (Imposto do Selo at 9% for auto third-party liability, plus applicable covenants) are combined to produce the quoted premium.
- Quote lock (instant): The quoted price is associated with your session and locked for 24 hours. If market conditions or model updates change the price in that window, you still get the locked quote.
- Payment processing (15–30s depending on card network): Standard 3D Secure payment flow. This is the slowest step in the process and it is entirely outside our control — the card network's authentication speed determines how long this takes.
- Policy document generation (2–4s): The policy document is generated programmatically from a legally reviewed template, populated with your specific coverage terms, policy number, start date, sum insured, and applicable endorsements. The document is a PDF/A — the archival-grade PDF format required for legally binding documents under EU standards.
- Policy registration (1–2s): The new policy is registered with the ASF's active policies database through our underwriting partner's API. From this point, the policy exists in the system that traffic authorities query when they scan a vehicle's registration plate.
- Email delivery (1–3s): Policy documents sent via transactional email. You have them before you close the browser tab.
Total elapsed time under normal conditions: 25 to 45 seconds from payment confirmation. The "three minutes" figure includes the time it takes a real person to read and answer the six questions. The actual system processing is under a minute.
Where it can go wrong and how we handle it
The vehicle lookup step has a failure mode: if the matrícula you enter does not match a vehicle in the registry — either a typo, or a vehicle that has not been updated in the registry after a recent change of ownership — the lookup fails. In that case, we fall back to asking you to enter the vehicle's make, model, year, and fuel type manually. This adds a step but does not prevent the quote from completing. The manually entered data goes through a validation check against known vehicle specifications before entering the model.
Payment failures route to standard retry and error messaging. A failed payment does not generate a policy document or a partial policy — the system is transactional, meaning either the full sequence completes or nothing is persisted. There is no state where you have paid but do not have a policy, or have a policy number but have not paid.
Policy registration failures — which are rare and typically related to transient API issues on the receiving end — are handled by a retry queue. If registration does not confirm within 60 seconds of payment, our monitoring system flags the policy for manual follow-up within four hours. In practice, this has occurred a handful of times during integration testing and not in production, but the handling exists because the consequence of a failed registration — a policy document that exists on our end but not in the ASF database — is something we consider unacceptable.
What we deliberately did not build
We get questions about telematics — the black-box style devices or mobile apps that track driving behaviour and adjust premiums based on actual observed driving. This is a real category of insurance technology and it produces genuinely better risk pricing in theory.
We chose not to build it for Indie's first product for two reasons. First, the data collection infrastructure for telematics is significant, the privacy implications are substantial (constant location tracking of users is not a light compliance burden under RGPD), and the friction of getting a telematics device fitted or an app running reliably in the background is meaningfully higher than answering six questions. Second, and more fundamentally, we are not certain that most Portuguese drivers would actually accept the trade-off of continuous monitoring in exchange for a potential price reduction. We may be wrong about this. If the data shows we are wrong, we will reconsider.
The version we built — six inputs, fast pricing, instant policy — is the version we were confident we could execute well and that we believe most customers actually want. Fast and fair, without the surveillance component.