Insurtech Development in 2026: Build, Buy or Extend

Insurtech development means building the software an insurer or MGA runs on: quoting and rating, policy administration, underwriting, claims, distribution portals and the APIs that embed cover into other products. In 2026 the practical answer for most carriers is a hybrid: buy or keep a core system for policy and financial records, and build custom modules around it where the business differentiates. This guide covers what those systems are, build vs buy vs extend, the integration map, the European and UK rules that shape architecture, and how to scope a project that ships.

What an insurtech system actually contains

"Insurance software" is a set of systems with different rates of change; projects fail when the team treats them as one.

Policy administration system (PAS). The system of record for policies, endorsements, renewals, cancellations, billing and commissions. It feeds finance and regulatory reporting, changes slowly and is expensive to get wrong.

Quoting and rating engine. Takes risk inputs (vehicle, property, business activity, health declarations) and returns a price from rating tables, factors and rules. Product managers change it monthly, so it needs versioning and auditability more than raw speed.

Underwriting workbench. The tool underwriters use to review referred risks: the submission, third-party data, appetite rules, prior losses, notes and a decision. Straight-through processing handles the simple cases; the workbench handles the rest.

Claims management. First notice of loss (FNOL), triage, reserves, adjuster assignment, documents and photos, repair networks, payments, subrogation and fraud checks. The most workflow-heavy domain and the one customers judge you on.

Broker and agent portals. Front ends for intermediaries: quote, bind, mid-term adjustments, renewals, documents, commission statements. Often the first custom build, because vendor portals are generic and brokers vote with their feet.

Embedded insurance APIs. Quote-bind-issue endpoints consumed by a retailer, travel platform, car-sharing app or lender. The product is the API contract: idempotency, latency, sandbox, versioning, clear errors.

Around these sit documents, e-signature, payments, KYC/AML, data enrichment and the customer-facing apps.

Build vs buy vs extend a core system

The decision is not "vendor or custom" but which capability goes into which bucket. Core platforms of the Guidewire, Duck Creek and Sapiens class cover PAS, billing and claims with configurable products. They are strong at record-keeping and regulatory reporting, and weak or expensive at anything customer-specific, channel-specific or fast-changing.

Criterion	Buy core (Guidewire / Duck Creek / Sapiens class)	Extend core (custom modules around a vendor PAS)	Build custom end to end
Best for	Policy, billing, claims records; multi-line carriers	Portals, embedded APIs, quote flows, claims intake, data products	Niche MGAs, single-line startups, parametric or usage-based products
Time to first release	Long: vendor implementation programs run over quarters	Months per module	Months for a narrow product; long if you also rebuild the ledger
Change speed for products	Configuration-driven, but constrained by vendor release cycles	Fast where you own the code; still bounded by core APIs	Fastest, with full responsibility
Regulatory reporting	Included, mature	Inherited from the core	You build it, and you own the audit
Total cost profile	High license and implementation cost, predictable run cost	Moderate; integration effort is the main cost	Low license cost, high engineering and ops cost
Vendor lock-in	High	Medium: the core is locked, your modules are portable	Low
Typical risk	Scope creep and customization inside the vendor stack	Integration debt if contracts are not owned	Rebuilding accounting and compliance you did not need to

Rule of thumb for 2026: buy or keep the ledger, build the experience and the data. Custom accounting and regulatory reporting are hard to justify unless the product fits no vendor model, which is true for some parametric and usage-based lines.

The pattern that fails most often is customizing the vendor core until it looks like a custom build; every deep customization blocks the next upgrade. Logic written inside the PAS to serve a portal or an API belongs in a module you own, talking to the core through a contract you own. It is the same reasoning as migrating legacy systems: strangle the edges, do not rewrite the middle.

The integration landscape

Any insurance application is an integration hub. Map it before the first sprint; each connector has its own contract, failure mode and compliance implication.

Integration	What it does	Typical failure mode	Design note
Core PAS / claims system	System of record for policies and claims	Slow or batch-only APIs; brittle vendor SDKs	Wrap in an anti-corruption layer; never expose vendor models to portals
Payment provider (cards, SEPA, direct debit)	Premium collection, refunds, claims payouts	Failed mandates, chargebacks, reconciliation gaps	Idempotent payment intents; reconcile daily against the ledger
KYC / AML and sanctions screening	Identity, PEP and sanctions checks at onboarding and payout	False positives blocking bind; stale lists	Async screening with a hold state, not a synchronous gate on quote
Document generation	Policy schedules, IPIDs, certificates, claims letters	Template drift between languages and products	Version templates with the rating version; render from structured data
E-signature	Binding declarations and mandates	Legal validity across jurisdictions; expired envelopes	Store evidence packages with the policy, not just a signed PDF
Data providers	Vehicle data, property data, credit, weather, telematics, claims history	Cost per call; unavailable at quote time	Cache with a TTL that matches the data's legal use; fall back to a referral
Repair and supplier networks	Garages, contractors, replacement providers	Manual email workflows	Event-driven assignment with status callbacks

Two decisions here matter more than the rest. Own the canonical models for customer, risk, quote, policy and claim in your own services; vendor and partner models change, yours should not have to. And treat every external call as unreliable: a quote flow must degrade when a data provider is down (refer the case, keep the lead), and a claims flow must survive a payment outage without losing the instruction.

Regulation in Europe and the UK: what each rule means for the code

Regulation sets architecture requirements. Four frameworks appear in nearly every European or UK scope.

GDPR. Personal data across quote, policy and claims. In practice: lawful basis and retention per data category, data minimization in quote forms, subject access and erasure that reach every integrated system, and DPIAs for profiling and automated decisions. Health data in life, health and some travel lines is special-category data. Our GDPR guide for software teams covers the engineering side.

Solvency II. The EU prudential regime: capital requirements, risk management and supervisory reporting. Software teams rarely implement the capital model, but they own the data that feeds it. The implication is data lineage: premiums, reserves and claims figures need traceable origins, immutable history and reconciled totals between operational systems and the reporting layer. The UK runs its own adapted version of the regime.

DORA (Digital Operational Resilience Act). The EU framework for ICT risk in financial entities, insurers included: ICT risk management, incident reporting, resilience testing and oversight of third-party ICT providers. For a development team: documented critical services and dependencies, tested recovery, incident classification and reporting paths, and controls on every SaaS and cloud provider in the chain. A cloud-hosted PAS, a payment provider and a data API are all third-party ICT risk under DORA.

FCA Consumer Duty (UK). A conduct standard requiring good outcomes for retail customers across products, price and value, understanding and support. In software terms: clear product information at the point of sale, no dark patterns in quote and renewal journeys, accessible support, and evidence of outcomes, which means instrumenting journeys and keeping the data. Renewal and auto-renewal flows get particular attention.

Depending on line and country, IDD, PSD2, national document rules and ombudsman requirements also apply. Bring compliance into scoping, not into UAT.

Data and AI in underwriting and claims: what works and what does not

The useful applications of AI are narrower than the pitch decks suggest.

What works in production.

• Document extraction: claims forms, invoices and medical reports into structured fields, with a confidence score and a review queue.
• Claims triage: simple, low-value claims to straight-through handling, complex ones to adjusters.
• Fraud signals: anomaly and network detection that flags cases for investigation. The output is a reason list for a human, not a decision.
• Pricing inputs: risk factors consumed by the rating engine as versioned, explainable features.
• Support assistants over policy documents, with retrieval grounded in the customer's own policy.

Where the limits are.

• Automated decisions with legal or similarly significant effects fall under GDPR's rules on automated decision-making: explanation and a route to human review. Declining cover or a claim on a score alone is a conduct and legal problem.
• Model drift is real: a pricing model trained before a shift in claims inflation or a new fraud pattern degrades quietly. Monitoring belongs in scope from day one; see MLOps in production.
• Bias and proxy discrimination: features correlated with protected characteristics need review, and some markets restrict specific factors outright.
• Generative models hallucinate. Never let one produce a coverage statement without grounding in the policy wording and marking it as guidance.

The engineering contract: every model output stored with its version, input snapshot and explanation; every automated outcome reversible by a human; every model monitored against a baseline.

Architecture patterns that hold up in insurance

Three patterns come up in nearly every well-run build.

Event-driven claims. A claim is a long-running process with many actors: customer, adjuster, garage, medical provider, payment system, fraud team. Modeling it as domain events (ClaimRegistered, DocumentsReceived, ReserveSet, AssessmentCompleted, PaymentInstructed, ClaimClosed) lets each service react independently, gives a natural audit log, and makes SLA measurement trivial. Use an outbox so events are never lost between the database write and the broker. Trade-offs are in event-driven architecture.

Rules engines with owned rules. Appetite, referral, eligibility and compliance rules change often and must be explainable. Keep them as data (decision tables or a DSL) with versioning, tests and effective dates, not as scattered if statements. Off-the-shelf engine or in-house evaluator matters less than three properties: a business user can read the rule, a test proves it, and a log shows which version fired for a given quote.

Versioned rating tables. A price must be reproducible months later for a complaint or an audit. The rating engine takes an explicit version and returns a breakdown; old versions are never edited in place.

{
  "product": "motor-private",
  "ratingVersion": "2026.08.1",
  "effectiveFrom": "2026-09-01",
  "basePremium": 412.00,
  "factors": [
    { "name": "vehicleGroup", "value": "14", "multiplier": 1.12 },
    { "name": "ncdYears", "value": "5", "multiplier": 0.68 },
    { "name": "postcodeZone", "value": "C", "multiplier": 1.05 }
  ],
  "rules": [
    { "id": "REF-017", "version": 3, "outcome": "refer", "reason": "prior-claims >= 2" }
  ],
  "premium": 329.61
}

Store this breakdown with the quote. When someone asks why a customer paid that amount in March, you answer from data.

Also worth adopting: an anti-corruption layer around the vendor core, a single customer identifier you own, idempotent APIs for every embedded endpoint, and separate read models for portals and dashboards so reporting never competes with transaction traffic.

Scoping and delivery checklist

Most overruns come from scope, not technology. Answer six questions before estimating.

1. Which product line and which channel? One line, one channel for the first release: motor via one aggregator, pet direct-to-consumer, or one commercial package through five brokers. Multi-line, multi-channel from day one is a program, not a project.
2. Where does the record of truth live? An existing PAS stays the ledger and the project builds around it. Otherwise decide now between a vendor core and a lightweight custom ledger; it defines the integration work.
3. What must be reproducible? Prices, decisions, documents and payments. This sets the versioning and audit requirements, and is where most estimates go wrong.
4. Which integrations are on the critical path? Payment and document generation always are. KYC, data enrichment and e-signature can often be phased.
5. What are the regulatory gates? Product approval, DPIA, outsourcing and resilience assessments, conduct sign-offs. Put them in the plan with owners and dates; they do not compress.
6. What does success look like in numbers? Quote-to-bind conversion, straight-through rate, claims cycle time, cost per policy. Baseline them before you build.

A sensible first phase for a carrier with an existing core: a broker portal for one product, an embedded quote-bind API for one partner, or a claims intake and triage module for one line. Each is a few months of work for a focused team, produces a measurable result, and establishes the integration layer every later module reuses. Teams sizing this kind of scope often bring in a partner for custom software development with insurance domain experience rather than staffing from zero.

Once scope is set, use this as the program-level definition of done.

• Domain model owned: customer, risk, quote, policy, claim and payment defined in your services, mapped to each vendor and partner model.
• Rating and rules versioned: immutable versions, tests, effective dates, stored breakdown per quote.
• Audit trail: who changed what, when, from which system, for policies, claims, reserves and payments.
• Data protection built in: retention per data category, erasure that propagates to every integrated system, DPIA for profiling and automated decisions.
• Resilience evidence: critical services and dependencies documented, recovery tested, incident reporting path defined (DORA-ready).
• Third-party controls: contracts, access controls and monitoring for every external provider, core vendor and cloud included.
• Consumer outcome evidence: journey instrumentation, plain-language documents, accessible support, frictionless renewal and cancellation (Consumer Duty-ready).
• Integration contracts: schemas, idempotency, retry and timeout policies, partner sandbox, versioning.
• Test matrix: rating regression against golden quotes, contract tests per integration, end-to-end for quote-bind-issue and FNOL-to-payment.
• Observability: business metrics (quote-to-bind, claims cycle time, referral rate) alongside technical ones, alerts owned by named people.
• Release safety: feature flags for product changes, canary releases for pricing changes, rollback tested.
• Security baseline: distinct roles for customers, brokers and staff, encryption at rest and in transit, secrets management, dependency scanning in CI.

Recommendation

Keep or buy the core for policy records, billing and regulatory reporting. Build the layers customers, brokers and partners touch, plus the data and rules that make your products yours. Own the domain model and the integration contracts so the core stays replaceable. Version everything that produces a price, a decision or a document, and design claims as events from the start. Bring GDPR, Solvency II lineage, DORA resilience and Consumer Duty evidence into scope before the first sprint. At Arvucore we usually recommend a first module that ships within months and proves the integration layer, then scaling line by line rather than attempting a platform program up front.