Home/Industries/Insurance
Industry

Modern engineering for an industry built on trust.

Policy administration, claims automation and digital distribution — modernised around the books of record.

InsuranceWhat we do
01Digital distribution
02Claims automation
03Policy admin modernisation
04Data & actuarial platforms
How it runs
  1. Estate walk and evidence plan
  2. Characterise and build a thin slice
  3. Parallel run and widen
  4. Cutover, line by line
  5. Operate and prove
What makes it hard

Insurance runs on systems older than some of its products.

Insurance runs on systems older than some of its products — and on data whose accuracy is a legal obligation. We modernise around the core: digital journeys in front, automation in the middle, and careful strangler-pattern re-engineering of the policy admin systems themselves.

The constraint that shapes everything is duration. A policy written this year may still be paying claims in twenty, so the system that holds it cannot simply be replaced when a better one appears; it has to be understood, reproduced and proven equal before anything is switched off. That is why insurance modernisation is mostly an exercise in evidence rather than in features: characterising what the old engine actually does — including the behaviour nobody documented and the exception somebody coded in 2009 — then demonstrating, on real portfolios, that the new path agrees with it to the last cent.

At the same time the front of the business has changed shape. Customers expect a fast quote and a prompt claim acknowledgement, brokers compare carriers on how easy the API is, and embedded distribution puts your product inside somebody else’s checkout. So the same organisation has to move at two speeds — a fast, well-instrumented distribution and service layer, and a deliberate, reconciled core — without the fast layer telling customers something the slow one will later contradict.

What we do in this sector

Four areas we work in.

The work in this sector divides cleanly: what customers and brokers touch, what the operation processes, what holds the book of record, and the data layer everyone argues over. We build across all four, and we treat the last two with the caution they deserve.

01

Digital distribution

Quote-and-bind journeys, broker portals and embedded-insurance APIs that turn products into channels. The journey is short because the rating call is fast and the questions are the ones underwriting actually needs; the portal is used because it answers a broker’s three real questions — where is my quote, where is my document, where is my commission. Embedded distribution is the same product exposed as an API with its own rate limits, versioning and settlement statement.

02

Claims automation

Intake, triage and straight-through processing — with ML-assisted fraud signals and human adjudication where it belongs. Documents and photographs are extracted and structured on arrival, simple claims settle without a queue, and complex ones reach an adjuster with the evidence already gathered. Every automated decision records its inputs, its model or rule version and its outcome, because a decision you cannot explain is a decision you cannot defend.

03

Policy admin modernisation

Strangler-pattern re-engineering of legacy PAS estates, with parallel-run validation on the books of record. We wrap the existing system with contracts, move one line of business or one function at a time, and run old and new side by side on live data until the outputs match. Cutover happens on evidence — a signed reconciliation — and the rollback path stays live until the next cycle proves itself.

04

Data & actuarial platforms

Governed data models that give actuaries, finance and regulators the same numbers. One definition of premium, exposure, reserve and claim, versioned, with lineage from the source system to the report. Built by data engineering as a contract between departments rather than as a warehouse project, so the quarterly argument about whose number is right stops being an argument.

In practice

What we build, in detail.

01

A quote journey that underwriting can still recognise.

Most digital journeys fail in one of two ways: they ask everything the core system’s screen asks, so nobody finishes, or they ask almost nothing and bind risk the underwriter would have declined. The fix is to separate the journey from the rating engine and make the question set a product decision. Data that can be fetched — vehicle, address, prior claims, company registry — is fetched rather than typed. Questions that only change the price under specific conditions are asked only under those conditions. Referral is a designed state with an owner and a clock, not an error page. And the whole funnel is instrumented step by step, so a conversion drop is traced to the question that caused it instead of debated in a monthly review.

  • Rating, eligibility and referral rules held as versioned configuration, with the version recorded on every quote
  • Third-party enrichment replacing typed questions wherever a reliable source exists
  • Referral, decline and re-quote designed as first-class states with an owner, a clock and an audit record
  1. 01Quote
  2. 02Underwrite
  3. 03Bind
  4. 04Issue
  5. 05Renew

Quote-to-bind lifecycle

02

Claims triage that sends the easy ones straight through.

A claims queue treated as one undifferentiated stream is expensive at both ends: simple claims wait behind complex ones, and complex ones get the same attention as a windscreen replacement. We build triage that scores each claim on arrival — completeness of documents, policy validity, amount against thresholds, fraud signals — and routes it. Inside agreed limits and with clean evidence, the claim settles automatically. Outside them, it reaches an adjuster with documents already extracted, the policy already validated and the reason for referral written down. What matters most is that every automated decision can be explained.

  • Document and photograph extraction at intake, with confidence thresholds that route low-confidence cases to a human
  • Fraud and anomaly signals as an input to triage, not as a silent decline — the adjuster sees the signal and the reason
  • Every automated decision recorded with inputs, rule or model version and outcome, retained for audit and complaint handling
03

Cutover on evidence, not on a date in the plan.

Nothing in insurance modernisation is as important as the parallel run. Before a single policy moves, we characterise the legacy engine with golden-master tests built from its own historical output, so its quirks are captured as behaviour rather than dismissed as bugs. Then both engines process the same live population every cycle and every difference is triaged: a defect in the new path, a quirk to be reproduced deliberately, or a legacy error to be corrected on purpose with the business signing the correction. The difference count goes to zero, and only then does anything cut over. By then the argument about whether the new system is right has already been settled on real numbers.

  • Golden-master characterisation of the legacy engine before any migration code is written
  • Every cycle compared movement by movement, with differences triaged as defect, quirk or deliberate correction
  • Cutover on a signed reconciliation, line of business by line of business, with the rollback path kept live
By carrier

Three books, three engineering problems.

P&C carrier

Volume, rating and the claims queue.

General insurance lives on throughput: many small policies, frequent claims, price competition that punishes a slow quote. The engineering priorities are a rating path that answers in real time under aggregator or broker load, rules that product managers can change without a release, and claims triage that keeps the adjuster pool focused on the claims that need judgement. The core stays where it is until the parallel run says otherwise.

  • Rating and eligibility rules as versioned configuration, simulated against historical quotes before release
  • Aggregator and broker traffic shaped with per-source limits, caching and honest degraded responses
  • Claims triage tuned per line of business, with thresholds owned by the business, not buried in code
Life & health

Long duration, sensitive data, careful automation.

Life, pensions and health carry contracts that outlive the systems administering them and data that is special-category under GDPR and KVKK. Automation here is assistive by default: underwriting evidence gathered and structured, medical documents extracted, decisions proposed with reasons and confirmed by a person. Access is minimised and logged, retention is enforced by the platform rather than by policy documents, and every model-assisted step is explainable to a regulator and to the customer.

  • Special-category data minimised, encrypted, access-logged and retained on enforced schedules
  • Underwriting and medical document extraction as an assistant, with human confirmation on every decision
  • Long-duration record keeping designed for migration — because the system will be migrated again
Broker & MGA

Distribution is the product.

For a broker or managing general agent, the platform is how business is won: quoting across carriers, documents produced without re-keying, commission visible before the argument. We build the panel integration layer — each carrier behind its own contract, timeout and health check — the document and e-signature flow, and the bordereaux and commission reporting that keeps the carrier relationship clean.

  • Carrier panel abstraction with per-source timeouts, health checks and automatic fallback
  • Document generation and e-signature in the journey, not as an emailed attachment afterwards
  • Bordereaux, commission and settlement statements produced from the record and reconciled per carrier
Integrations

The estate an insurer actually runs on.

Policy administration

Legacy and packaged PAS wrapped in versioned service contracts — quote, bind, endorse, renew and cancel exposed as APIs while the core stays the book of record

Claims systems

Intake, reserve and payment events exchanged as messages, with document stores linked rather than duplicated and every state change carrying its actor

Finance & general ledger

Premium, commission, claims payment and reserve movements posted on agreed cut-offs and reconciled to the ledger before anything is reported

Reinsurance & bordereaux

Treaty and facultative cessions, bordereaux production and settlement statements generated from the record and matched per period

Payments & collections

Card, direct debit and bank transfer flows with tokenisation, retries, refunds and clean linkage back to the policy and the claim

Documents & e-signature

Template-driven document generation, archival and e-signature providers, with the signed artefact retained on the audit trail

Health & medical data

HL7 and FHIR-shaped exchanges for health lines, handled as special-category data with minimisation, access logging and enforced retention

Regulatory & actuarial reporting

Solvency and IFRS 17-aware data marts with lineage from source to disclosure, and Power BI models for the finance team

Discipline

The habits we bring to an insurance engagement.

  • Parallel-run reconciliation on any system holding the book of record. Old and new process the same live population until the difference count is zero, and cutover happens on a signed reconciliation rather than on a date agreed at kick-off.
  • Auditability by design — every state change traceable. Who changed what, when, under which rule version, and what the state was before. Retro-fitting an audit trail after a regulator asks for it is far more expensive than building it in.
  • Solvency and IFRS 17-aware data lineage. Every figure in a report can be walked back to the source record through named, versioned transformations, so a question from an actuary or an auditor is answered from the record rather than reconstructed by hand.
  • KVKK and GDPR-aware handling of health and personal data. Special-category data is minimised, encrypted, access-logged and retained on enforced schedules; residency is a deployment decision documented for your auditors — see security & compliance.
  • Rules as configuration, owned by the business. Rating, eligibility, triage and referral rules are versioned, simulated against historical data before release, and changed without a deployment — with the version stamped on every decision they produced.
  • AI as an assistant with a paper trail. Extraction, triage scoring and fraud signals are inputs to a decision a person can see and override. Model version, inputs and outcome are recorded, and no customer-facing decision is made by a model nobody can explain — see AI & machine learning.
  • Contracts before code at every boundary. Interfaces to the PAS, claims, finance and payment systems are versioned and contract-tested in CI, which is what lets the distribution layer and the core each move at their own pace — see integration & API development.
  • Observability from the first sprint. Traces across the quote and claim funnels, latency budgets per step, and alerting on the steps that convert or settle — so a regression is visible early rather than in the month-end report.
How an engagement runs

From the estate walk to a cutover on evidence.

01

Estate walk and evidence plan

We map the policy, claims and finance systems with your architects and actuaries, agree what may not move, and write down how correctness will be proven. The output is an integration map, a reconciliation definition and the first flow to be built.

02

Characterise and build a thin slice

Golden-master tests capture the legacy engine’s real behaviour from its own historical output, while one journey — usually a quote or a claim intake — runs end to end on production integrations with real data shapes and real timing.

03

Parallel run and widen

Both engines process the same live population every cycle. Differences are triaged as defect, quirk or deliberate correction, and the count is reported to the steering group regularly, at a rhythm agreed with you. In parallel, the distribution or claims layer keeps shipping on its own cadence.

04

Cutover, line by line

When a line of business reconciles clean for an agreed number of cycles, it cuts over — with the rollback path live and the previous system still reachable read-only. The next line follows. Nothing is migrated because the plan says this is the week.

05

Operate and prove

Dashboards, SLOs and incident handling to the hours the run contract sets, plus the periodic reconciliation and evidence pack that turns your next audit into a retrieval exercise.

FAQ

Frequently asked questions

Yes — that’s the normal case. We characterise its behaviour, wrap it with modern APIs, and migrate line-by-line with reconciliation, not big-bang. In practice the wrapping comes first and delivers value on its own: a portal, a quote journey or a claims intake in front of a core that has not changed, followed by strangler-pattern replacement of the parts where the risk is understood.
Assistive first: document extraction, triage scoring, fraud signals — with human adjudication and full audit trails on decisions. Model version, inputs and output are recorded with the case, confidence thresholds route uncertain items to a person, and we measure the model against held-out history before it touches a live queue.
We engineer for auditability and work with your compliance team’s requirements as design inputs — Turkish, EU and UK regimes included. We do not offer legal interpretation; we take the controls your compliance and actuarial functions specify and make them properties of the system, with the evidence produced as a by-product of running it.
Yes — distribution tooling too: quoting, document flows and commission visibility brokers actually use. Because it sits in front of the core rather than inside it, a portal or an embedded-insurance API can ship independently of the core and removes re-keying.
Our data engineering practice builds the governed layer — one definition of premium, exposure and claims across the company. Definitions are versioned and owned, lineage runs from the disclosure back to the source record, and the marts that actuaries, finance and the regulator use are built from the same models rather than from three competing extracts.
With numbers, not assurances. The parallel run compares old and new on your real population every cycle, and the difference count is reported openly — including the differences that turn out to be legacy errors. Cutover requires a signed reconciliation and an agreed number of clean cycles; until then nothing moves.
That is the usual arrangement. We run as an embedded team on your board and your review process, or as a dedicated team owning a defined slice with its own SLOs. Handover is continuous rather than an event at the end.

Bring us a problem from your industry.

Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.

✓ No pitch deck✓ Reply from an AI-native engineer✓ Written follow-up