Fintech & Financial Services
Software engineering for Insurance
Insurance software is not hard because the front end is hard. It is hard because a rating engine encodes decades of actuarial judgement, a policy-admin system that nobody fully understands sits underneath everything, and the FCA is watching how you treat customers. We build for that reality, incrementally, without pretending the legacy estate does not exist.
Why the domain matters
Insurance runs on rules and data, and both are older and more tangled than any greenfield pitch admits. A rating engine is not a formula, it is decades of accumulated actuarial judgement, regulatory carve-outs and hard-won loss experience encoded as logic that a handful of people understand and nobody wants to touch. A policy-admin system (the PAS that holds every policy, endorsement, renewal and premium calculation), is frequently a decade or three old, patched by people who have long since left, and load-bearing in ways that only reveal themselves when something breaks. The claims system is its own world again. Any software you build for an insurer, an MGA or a broker has to make peace with this estate, because the estate is not going anywhere on the timescale of your project.
The value chain has a shape worth naming, because software lands differently at each stage. Distribution is where the customer or broker meets you: aggregators, comparison sites, broker platforms, direct quote-and-buy. Underwriting is where risk is assessed and priced, increasingly at a workbench where an underwriter needs data pulled together and a decision recorded. Policy administration is the system of record for the contract and its money. Claims is where the promise is tested: first notification of loss, triage, adjustment, settlement, and the constant pressure of fraud. Reinsurance and capital sit behind all of it. In the London Market and the broker/MGA/carrier ecosystem, work crosses several organisations and several ageing systems before a single risk is bound, which is why integration is usually the majority of the effort and the front end is the easy part.
We are a senior-led team, and we operate what we build, so we start from the constraints rather than the demo. The hard parts of insurance software are the actuarial and rules complexity, the regulatory obligations that shape what the software is even allowed to do, and the integration with entrenched policy-admin systems that resist change. None of that is solved by a rewrite. We favour incremental modernisation, strangling a legacy PAS one capability at a time, putting a clean service in front of a system you cannot yet replace, proving each step in production before the next, because the big-bang replacement of a core insurance platform is the single most reliable way to spend two years and a large budget arriving back where you started, only later.
The challenges in insurance
Legacy policy-admin systems nobody wants to touch
The PAS at the centre of most insurers is old, poorly documented and encodes business rules that live nowhere else. It is the system of record for every policy and every pound of premium, so it cannot go down, and the people who understood its internals have often moved on. This is the gravitational fact of insurance IT: you build around it far more often than you replace it, and any plan that assumes otherwise is a plan to fail.
Actuarial and rating complexity that is genuinely hard
Pricing a risk is not a lookup. Rating engines encode factor tables, rules, referrals, minimum premiums and regulatory constraints that reflect years of loss experience and actuarial work. Get a factor or a rounding rule wrong and you either leak money on every policy or price yourself out of the market: silently, at scale. The complexity is real and irreducible, and treating it as a simple calculation is how expensive mistakes get shipped.
Regulation that shapes the software, not just wraps it
The FCA’s conduct rules and Consumer Duty are not a compliance checkbox you tick at the end. They govern how a quote journey is allowed to present price and cover, what a fair claims outcome looks like, and what evidence you must retain to show you treated a customer well. Solvency II drives capital and reporting requirements that reach into your data. Compliance is a design input from the first sprint, not a gate before launch.
Fragmented integration across many parties and systems
A single risk can pass through a broker platform, an aggregator, an MGA’s system, a carrier’s PAS, a rating engine and a reinsurance arrangement, often across separate organisations, often over ageing interfaces. Data has to stay consistent as it crosses each boundary. Most of the effort, and most of the failure modes, live in these integrations rather than in any one application.
Fraud that adapts as fast as your defences
Claims fraud is a persistent cost, from opportunistic exaggeration to organised rings. Detection has to catch enough to matter without drowning genuine claimants in friction and false positives, and every model you deploy is studied by people whose job is to defeat it. Fraud is an adversarial, moving target, not a filter you build once.
Data that is sensitive, regulated and sometimes medical
Insurance holds personal, financial and (in health, life, travel and PMI lines), medical data, which is special category data under UK GDPR. It is a rich target and a serious liability. Handling it demands genuine data protection engineering, tight access control and a clear-eyed view of what you retain and why, not a privacy policy bolted on afterwards.
What we build for insurance
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Digital quote-and-buy journeys
Quote, price and bind journeys for direct and broker distribution that call your rating engine as the source of truth rather than re-implementing the maths in the browser. We build the parts that make these journeys convert and stay compliant, honest presentation of price and cover, sensible handling of referrals and declines, and a journey that meets Consumer Duty expectations instead of dark-patterning a sale.
Underwriting workbenches
Tools that pull the data an underwriter needs into one place (submission details, third-party enrichment, prior claims, exposure), and let them assess, price and record a decision with the referral rules enforced. The aim is to remove the copy-paste and the tab-juggling while keeping the underwriter firmly in the decision, with every judgement captured for audit.
Claims automation and FNOL
First-notification-of-loss capture and claims workflow that gets a claim in cleanly, triages it by severity and complexity, and routes the straightforward ones down a fast path while flagging the ones that need a human adjuster. Automating the routine early frees your people for the claims where their judgement actually earns its keep.
Policy-admin modernisation
Incremental modernisation of the PAS, extracting capabilities into clean services, putting modern interfaces in front of the parts you cannot yet replace, and strangling the legacy system one function at a time. Each step is proven in production before the next. We do not sell the big-bang replatform, because it is the thing most likely to fail.
Fraud detection
Detection built into claims and underwriting that scores for known fraud signals and surfaces anomalies for investigation, tuned to the real cost of false positives against genuine claimants. We treat it as an adversarial, evolving problem (models that are monitored and retrained), rather than a rules file that ages into uselessness.
Self-service portals and AI-assisted processing
Customer and broker portals for policy changes, documents, renewals and claims tracking that take load off the phones. Where it genuinely helps we apply AI to claims triage and document processing (reading a claim pack, extracting the fields, drafting a summary), always as an assistant with a human confirming anything that touches a decision or a payout, never a black box left to settle claims on its own.
Where we help
Comparison-site quote flow behind a legacy rater
A quote-and-buy journey for aggregator and direct traffic that answers in the milliseconds a comparison site demands, while every price still comes from the existing rating engine. The work is a clean, fast service layer in front of an old rater (caching, resilience and graceful degradation), so customers get a modern journey without anyone re-implementing the actuarial logic and introducing pricing drift.
Claims triage that fast-tracks the simple and escalates the rest
FNOL and triage that classifies incoming claims by likely complexity, cost and fraud risk, auto-progressing the clean low-value claims and routing the ambiguous or high-value ones to an adjuster with the context already assembled. The measurable win is faster settlement on the routine majority and adjuster time spent where it matters.
Underwriting workbench for a specialty or MGA book
A workbench that consolidates submission data, enrichment and referral rules for a specialty line where underwriters work in spreadsheets and email today. It enforces the authority limits and referral triggers, records the rationale for each decision, and gives the carrier behind the MGA the audit trail and consistency they need, without taking the pricing judgement away from the underwriter.
Strangling a monolithic PAS one capability at a time
Peeling a single high-value capability (say, renewals or endorsements), out of an ageing policy-admin monolith into a clean service, with the legacy system kept authoritative until the new path is proven, then cut over. Repeated capability by capability, this is how a core system actually gets modernised: in production, reversibly, without the all-or-nothing bet of a full replacement.
How we build for insurance
We start with the rules and the estate, not the screens. Before anyone designs a journey we want to understand how the rating engine really behaves, where the business logic actually lives, what the PAS will and will not let us do, and which regulatory obligations shape the feature. In insurance the constraints are the design, and skipping this is how teams build something elegant that cannot be integrated or cannot be signed off.
We modernise incrementally and prove each step in production. The default is the strangler pattern: a clean service in front of the legacy system, one capability moved at a time, the old path kept as a fallback until the new one has earned trust. This is slower to demo than a rewrite and far more likely to still be standing in two years. We will say so plainly when a stakeholder is being sold the big-bang alternative.
We treat the rating and money-touching logic as the thing that must be provably correct. Pricing, premium calculation and anything that moves money gets tested against real cases, reconciled against the system of record, and instrumented so drift is visible rather than silent. A pretty journey that quietly misprices is worse than no journey.
We keep the underwriter, the adjuster and the actuary in the loop by design. The software’s job is to remove the drudgery around their judgement, not to replace the judgement, and where we apply AI, a human confirms anything consequential. Because we operate what we build, the people designing these flows are the ones who get called when a claim is mishandled, which keeps everyone honest about the failure modes.
Regulation and compliance
The FCA regulates conduct across the general insurance market, and its rules reach directly into the software. How a quote presents price and cover, whether a renewal is fair, how declines and referrals are handled: these are conduct questions before they are UX questions, and we design the journeys to meet them rather than retrofitting compliance after a design review kills the build.
Consumer Duty raised the bar from "did you disclose it" to "did the customer get a good outcome and can you show it". In practice that means the journey has to support fair value, clear communication and evidence of the outcome, and the systems behind it have to retain what you need to demonstrate you acted in the customer’s interest. We treat that evidence trail as a first-class requirement, not logging added at the end.
Solvency II drives capital adequacy and regulatory reporting, and its data demands reach back into the operational systems. Where the software we build is a source of the data that feeds capital and reporting, we take the completeness, accuracy and traceability of that data seriously, because a gap here surfaces as a reporting problem long after the feature shipped.
Data protection under UK GDPR is non-negotiable, and it is heavier in insurance because some lines handle special category data: health and medical information in life, health, travel and PMI. That raises the bar on lawful basis, retention, access and minimisation. We engineer for it from the start; we do not treat privacy as a policy document stapled to a finished system. We build compliant systems, but we are engineers, not your regulatory or legal advisers, sign-off on conduct and capital obligations rests with your compliance and actuarial functions, and we build to work with them.
Integration
The policy-admin system is the centre of gravity. It is the system of record for policies and premium, and almost everything we build has to read from or write to it, usually over interfaces that were not designed for the demands we are placing on them. We invest heavily in a clean, resilient boundary around the PAS, so the modern systems on our side of it are not held hostage by the legacy system’s quirks and downtime.
The rating engine is the source of truth for price, and we call it rather than reimplement it. Re-encoding rating logic in a new application is how pricing drift and silent mispricing get introduced. Our job is to integrate with the rater reliably and fast enough for the channel (including the millisecond budgets an aggregator imposes), not to duplicate the actuarial work it represents.
Distribution means aggregators, comparison sites and broker platforms, each with their own data formats, quote protocols and latency expectations. In the London Market and the broker/MGA/carrier ecosystem a risk crosses several organisations before it is bound, so we build for consistency and reconciliation across those hops, and for the data-provider enrichment (credit, vehicle, property, prior-claims), that underwriting depends on.
Behind the primary risk sit reinsurance arrangements and the data flows they need, and across all of it the recurring engineering problem is the same: keeping data consistent and reconciled as it crosses systems and organisations that were never designed to agree with one another. We treat that reconciliation as core work, not an afterthought, because it is where the real defects hide.
Security and data protection
Insurance data is a high-value target: personal details, financial information, payment data, and in several lines medical and health records that are special category data under UK GDPR. A breach here is both a regulatory event and a serious harm to real people. We build with access controls scoped to genuine need, encryption in transit and at rest, and retention limited to what a lawful basis actually supports.
Medical and health data gets stricter handling again: narrower access, clearer purpose limitation, and careful thought about who and what ever needs to see it. Where AI touches claim documents or medical evidence, we are deliberate about what data reaches a model and where it goes, because that is exactly the sort of flow that turns into an incident when it is bolted on without thought.
Fraud is a security concern as much as a claims one. Underwriting and claims are targets for manipulation (falsified applications, staged and inflated claims, account takeover on portals), so we build detection, anomaly monitoring and strong authentication into the flows that matter, and assume the people probing them are adapting to whatever we ship.
Because we operate what we build, security is not a report handed over at the end. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation would need, and treat the ability to reconstruct exactly what happened to a customer’s data as part of the deliverable, not something you discover you are missing after an incident.
What changes
Modernisation that ships without betting the core
Because we strangle the legacy estate incrementally and prove each step in production, capabilities reach customers steadily and the core system of record stays stable throughout, instead of the multi-year big-bang that so often arrives late, over budget and no better off.
Pricing and money logic you can trust
By calling the rating engine as the source of truth and testing money-touching logic against real cases, the journeys we build price consistently with your system of record, so you are not silently leaking margin or mispricing risk at scale behind a nice front end.
Your people freed for the judgement calls
Automating the routine (clean claims, standard renewals, data assembly for underwriting), means adjusters, underwriters and actuaries spend their time on the cases where expertise actually changes the outcome, rather than on copy-paste and triage.
What we build for insurance
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for insurance?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in insurance choose us
We start from the legacy estate, not a blank canvas
We assume there is an old PAS, an entrenched rating engine and rules that live nowhere but in the code, because there almost always is. Our default is to build around and incrementally modernise that reality, which is the approach that actually works in insurance, and the one a greenfield-only shop is least equipped to deliver.
Senior engineers who respect the actuarial complexity
Rating, referrals and premium calculation are hard, and we treat them as hard, integrating with the logic and testing it rigorously rather than casually re-implementing maths we do not fully own. Senior people who know what they do not know are the right people near a rating engine.
We build compliance in and say so honestly
Conduct rules, Consumer Duty and data protection are design inputs in our work from the first sprint, and we are candid about where our engineering ends and your compliance and actuarial sign-off begins. We build systems that meet the obligations; we do not pretend to be your regulator.
We operate what we build
The people who design a claims flow or a PAS integration are the ones who get paged when it misbehaves. That concentrates the mind on the failure modes that matter in insurance (mispricing, mishandled claims, data exposure), and it means we are honest up front about trade-offs rather than discovering them in production on your behalf.
Related sectors
Part of Fintech & Financial Services. Adjacent sectors we also know.
Common questions
Should we replace our legacy policy-admin system or build around it?
Almost always build around it first, and modernise incrementally. A big-bang PAS replacement is the single most reliable way to spend two years and a large budget arriving back where you started. We favour the strangler approach: a clean service layer in front of the legacy system, capabilities extracted one at a time, each proven in production with the old path kept as a fallback until the new one has earned trust. Full replacement, when it makes sense at all, is the end of that road, not the start.
Can you build a quote-and-buy journey without re-implementing our rating engine?
Yes, and that is exactly how we prefer to do it. The rating engine is the source of truth for price; re-encoding its logic in a new application is how pricing drift and silent mispricing creep in. We build a fast, resilient service layer that calls your existing rater (including within the millisecond budgets an aggregator imposes), so customers get a modern journey while the actuarial logic stays in the one place that owns it.
How do you handle FCA conduct rules and Consumer Duty in the software?
As design inputs from the first sprint, not a compliance gate before launch. Consumer Duty in particular shifts the bar from disclosure to demonstrable good outcomes, so the journey has to support fair value and clear communication, and the systems behind it have to retain the evidence that you acted in the customer’s interest. We build that in. To be clear about the boundary: we build systems that meet the obligations, but sign-off on conduct compliance rests with your own compliance function, and we build to work alongside them.
Where can AI genuinely help in claims and underwriting, and where should it not?
It helps most on the routine and the document-heavy: triaging incoming claims by complexity and risk, reading a claim pack and extracting the fields, drafting summaries, assembling the data an underwriter needs. In every one of those a human confirms anything that touches a decision or a payout. Where it should not go is settling claims or declining risks on its own: the models are confidently wrong often enough, and the regulatory and fairness stakes high enough, that autonomous decisions on customer outcomes are the wrong place to remove the human. We will tell you where the line is rather than oversell it.
How do you deal with the sensitive and medical data in insurance?
With genuine data-protection engineering rather than a privacy policy bolted on afterwards. Personal, financial and payment data get access scoped to real need, encryption in transit and at rest, and retention limited to what a lawful basis supports. Medical and health data, special category data under UK GDPR, common in life, health, travel and PMI lines, gets stricter handling again: narrower access, clear purpose limitation, and deliberate care about where it flows, including into any AI processing. We design for that from the start, because it is exactly the sort of flow that becomes an incident when it is added without thought.
Building for insurance?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if insurance is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.