Insurance platforms, built for the day the customer finds out what they bought.

Product, regulatory position and distribution

What you are permitted to do decides the architecture before any preference does. Carrying risk on your own balance sheet, acting as a managing agent for someone else's capacity, broking, or embedding another carrier's product in your checkout are four different regulatory positions with four different systems behind them.

Distribution matters as much. Direct to consumer, through brokers, through an aggregator or embedded in a partner's purchase flow each impose their own commission structures, data flows and service expectations, and a platform built for one will not simply extend to another.

The output is a written position naming the licence, the capacity arrangement, the distribution channels and the product line you will launch with rather than the roadmap of lines you eventually want.

The rating engine, and why it must not be code

Pricing changes constantly in insurance: rates move, factors are added, a regulator queries a filing, an actuary sees a loss trend. A platform where rating lives in application code turns every one of those into a release, and the business will route around it with spreadsheets within a quarter.

Rating belongs in a configurable engine that actuaries can operate, with versioning, effective dating and the ability to reproduce exactly the rate that applied on the day a policy was written. That last requirement is not optional: a complaint or an audit years later asks precisely that question.

The same applies to underwriting rules. Referral triggers, declines and eligibility criteria change with appetite, and appetite changes faster than software.

Quote, bind and the policy as a contract

A policy is a versioned legal document, not a database record. It has a wording at a version, a schedule, endorsements that amend it mid-term, and a history that must remain intact because a claim will be assessed against the terms in force on the date of loss rather than today's.

Mid-term adjustments are where naive implementations break. Changing a vehicle, adding a property or altering a sum insured part-way through a term means recalculating premium pro rata, issuing an endorsement, and keeping both the old and new positions retrievable. Overwriting the policy loses the state a claim may need.

Renewal is its own workflow, with re-rating, notification obligations and lapse handling that differ by market and product.

Claims, which is the actual product

Everything before this is premium collection. The claim is the moment the policyholder discovers what they bought, and it is where insurers earn or destroy their reputation regardless of how good the buying experience was.

The workflow has a shape: notification, triage against cover, assessment, reserve, settlement or decline, and recovery where another party is liable. Each step needs evidence attached and a decision attributable, because a declined claim may be challenged by an ombudsman years later and the file is the whole defence.

Reserving belongs here rather than in finance. The moment a claim is notified it becomes a liability with an estimate attached, and that estimate moves as information arrives. A platform that treats reserve movement as an afterthought produces financial reporting nobody trusts.

Fraud detection and model governance

Fraud detection and pricing models are where an insurer's margin is made, and we build both: scoring on your own claims history, anomaly detection across the book, network analysis on linked claims, and referral scoring that routes the right files to investigators.

Alongside the models we build the governance layer that increasingly comes up in filings and reviews: explicability on any individual price, and outcome testing across groups where you want to run it. It is a capability we offer rather than a constraint we impose, and having it available before a regulator asks is considerably cheaper than assembling it afterwards.

Fraud output can route to an investigator or decline automatically, and that threshold is yours. Most insurers we work with set it high on automatic decline and route the middle band to a person, because a wrongly declined genuine claim is expensive in reputation, but the configuration is a business decision rather than an architectural one.

Reserving, reinsurance and regulatory reporting

Insurance reporting is heavier than most sectors and it is not optional. Regulators require returns on a schedule, in prescribed formats, reconciled to the policy and claims records that produced them. A platform that cannot produce those from its own data creates a quarterly manual exercise that grows with the book.

Reinsurance adds a layer that surprises teams building their first platform: ceded premium, recoveries on large claims and treaty terms that determine which losses are shared. Retrofitting reinsurance into a system that assumed you keep every risk is substantial rework.

Launch and the first claims cycle

One product line, one distribution channel, and a deliberately limited volume, because the first claims arrive weeks after the first policies and they test parts of the platform that selling never touches.

Day two is that first claims cycle: the first decline, the first complaint, the first reserve that moves materially. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.