Insurance estates carry decades of product decisions encoded in software. The difficulty is rarely that the systems do not work — it is that the rules inside them are no longer legible, so changing a product means changing something nobody can fully describe.
An insurer's estate is a record of every product it has ever sold. Policy administration platforms accumulate rules for products that are closed to new business but still in force, and those rules cannot be removed while a single policy depends on them.
Claims platforms grow similarly, and the two are frequently of different generations, integrated by batch transfers that were expedient at the time. Underwriting, distribution and finance then draw from both, usually through extracts that each apply their own interpretation.
The consequence is an estate where product change is slow, where the same customer appears differently in different systems, and where answering a regulator's question about how a figure was produced requires an investigation. Our work is usually about making the rules legible, deciding what is mastered where, and modernising in increments that do not require the whole book to move at once.
What insurers bring to us most often.
Underwriting and rating logic accumulated over decades sits in code, configuration and occasionally in a spreadsheet. Changing a product means changing something whose full behaviour is not documented anywhere.
Legacy platforms stay live for a shrinking book of in-force policies, carrying full operating and compliance cost for a decreasing share of the business.
The two platforms are usually different generations connected by batch transfer, so the same customer, policy or exposure is represented differently on each side.
Launching or amending a product requires change across administration, rating, documentation, distribution and finance, each on its own release cycle. The lead time is the sum, not the maximum.
Brokers, aggregators and bancassurance partners each integrate differently, so onboarding a partner is a project rather than a configuration.
Returns are compiled from extracts with manual adjustments, so each cycle repeats the same effort and the lineage supporting a figure lives in someone's working file.
The instinct in insurance transformation is to replace the policy administration platform, because it is visibly the constraint. That is also the largest, least reversible programme available, and it delivers nothing until it delivers everything.
The approach that works more often is to separate what changes at different speeds. Product definition, rating and documentation change frequently; policy record-keeping changes rarely. Moving the fast-changing parts out into services that can be released independently delivers most of the time-to-market benefit without betting the programme on a single cutover.
Insurers report against solvency, conduct and customer-protection obligations, and each requires figures whose derivation can be demonstrated. Where reporting is assembled from extracts with manual adjustment, that derivation lives in working files rather than in the estate.
Customer data adds a second dimension: policyholder records include sensitive personal data, and the Digital Personal Data Protection Act constrains its use, retention and cross-border processing. Retention is particularly awkward here because policy and claims records must be kept for long periods that vary by product.
We advise on the technical design and the evidence architecture. We do not provide legal or regulatory opinions, and we do not represent NG&NR as holding certifications it has not been awarded.
The central architectural decision is where product definition lives. Where it is embedded in the administration platform, every product change is a platform change and inherits the platform's release cycle and risk profile.
The second is mastering between policy, claims, customer and party. Insurers frequently have several representations of the same customer, and until one is authoritative, every consolidated view and every regulatory figure carries an unresolved discrepancy.
The third is how much the closed book is allowed to constrain the open one. Where legacy platforms remain integrated into the current estate, their limitations propagate into every new design. Isolating them behind a defined interface costs less than it appears to and removes a constraint from everything built afterwards.
Insurance workloads have an unusual shape: steady administration load with sharp peaks at renewal cycles, catastrophe events and modelling runs. That profile suits elastic capacity well, and modelling in particular is often the strongest early case.
Core administration platforms move more slowly, constrained by vendor support positions and by the practical difficulty of moving a system that holds in-force policies. We generally sequence modelling, analytics, digital distribution and recovery first, and are explicit that a hybrid position held deliberately is a legitimate destination.
The defining data problem in insurance is that the same entity exists in several systems with different rules — customer in administration, claimant in claims, party in finance — and no single one is authoritative. Every consolidated figure inherits that ambiguity.
Beyond identity, insurers need long-horizon consistency. Analysis frequently spans decades of policy and claims history, during which product definitions, coding schemes and platforms have all changed. That history has to be reconciled deliberately rather than assumed comparable.
Actuarial and reporting workloads also have very different access patterns from administration, and running them against the platform that administers policies degrades both. Separating the analytical store, with lineage back to the source, is usually the earliest change worth making.
Insurers hold detailed personal, financial and frequently medical information about policyholders, which makes the estate disproportionately valuable to an attacker and disproportionately consequential when access is loose.
The distinctive exposure is breadth of distribution. Brokers, aggregators, assessors and repairers hold access that was granted per relationship and rarely inventoried, so the blast radius of a partner compromise is usually unknown until it is measured.
The characteristic engineering problem in insurance is combinatorial. A rating or underwriting change can affect a very large number of product, cover and endorsement combinations, and testing them by sampling produces confidence that does not survive contact with the book.
That argues for rules expressed declaratively and tested against expected outcomes, so a change can be evaluated against the whole combination space rather than a selected subset — which is also what makes product change safe enough to do often.
Distribution integration is where insurers spend most of their integration effort, because each broker, aggregator and partner arrives with its own expectations. Where each is handled bespoke, onboarding a partner is a project and the estate accumulates variants indefinitely.
The internal problem is different: policy, claims and finance exchange data on batch schedules designed when overnight processing was acceptable. Moving selected flows to event-driven exchange resolves the reconciliation burden that batch timing creates.
The services usually engaged first in this sector, and why.
Deciding where product definition lives and what masters customer, policy and claim — the two decisions everything else inherits.
One authoritative party representation and history that is genuinely comparable across decades of product and coding change.
Rules expressed declaratively and tested across the combination space, so product change stops being a platform release.
Vendor-neutral assessment of administration and claims platforms, from a party that does not implement them or take a commission.
Intermediary and partner access, sensitive claim data handling, and retention over the long horizons insurance requires.
Combinatorial regression across products, covers and endorsements — where sampled testing gives confidence the book does not support.
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
The runtime much policy administration and rating software runs on, and where most modernisation of it is practical.
Common across claims, distribution and servicing platforms, with a supported path off .NET Framework.
Where in-force policy and claims history lives. Retention and historical comparability are decided here.
Actuarial and modelling workloads, data pipelines and the reconciliation of historical coding schemes.
Frequently the incumbent platform, and where elastic capacity for modelling peaks is most readily added.
For the product and rating services that need to release independently of the administration platform.
How an engagement runs where a book of in-force policies is at stake.
Your estate, product change lead time, and whether the constraint is the platform, the rules or the integration around them.
Where product logic actually lives, what masters which entity, and what the closed book is costing to keep alive.
Reporting, retention and data protection constraints recorded per product as hard inputs before design.
Product definition placement, mastering decisions and increments that each leave a working book.
Your engineers implement while we review design and validate that in-force behaviour is genuinely preserved.
Decision records, rule documentation and ownership, so the estate stays legible after we leave.
Frequently the better first move is to separate what changes at different speeds. Product definition, rating and documentation change often; policy record-keeping rarely does. Moving the fast-changing parts into independently releasable services delivers most of the time-to-market benefit without a single cutover the whole book depends on.
By extracting them from the running system rather than attempting to reconstruct intent from documents. The objective is rules expressed declaratively and version-controlled, so their behaviour is testable — at which point changing a product stops requiring someone who remembers why it works.
Isolate them so their cost and risk are visible and bounded, then treat migrating them as a separate decision with its own business case. Keeping a full platform alive for a shrinking book is a legitimate choice — but it should be a choice, not a default nobody has priced.
Less time than the sum of every downstream system's release cycle, which is what it usually is. The lead time is dominated by coordination across administration, rating, documentation, distribution and finance rather than by any individual change, so the improvement comes from decoupling those, not from working faster.
Largely, where the figures derive from a governed source rather than from extracts. The manual adjustments usually exist because two systems disagree structurally — and that is resolved by deciding what masters the entity, not by improving the spreadsheet.
With one partner-facing contract and configuration per partner, rather than a bespoke variant each. Where each integration is built individually, onboarding is a project by construction and the estate accumulates variants that all need maintaining.
Yes, but only if the mapping between schemes is made explicit rather than assumed. Long-horizon insurance analysis routinely compares data produced under different product definitions, and treating those as directly comparable is a quiet source of wrong conclusions.
Against the combination space rather than a sample. A rating or underwriting change can affect a very large number of product, cover and endorsement combinations, and sampled testing produces confidence that does not survive contact with the book. Declarative rules make that kind of testing practical.
Modelling and catastrophe workloads usually make the strongest early case, because the load is peaked and elasticity pays immediately. Administration platforms move later, constrained by vendor support positions. A deliberate hybrid position is a legitimate destination rather than an unfinished migration.
It is usually the largest unmeasured exposure in an insurer's estate, because access was granted per relationship and rarely inventoried. The remedy is an inventory first, then scoping and time limits — you cannot bound a blast radius you have not measured.
We do not name clients or publish case studies in any sector. During the first consultation we work through the reasoning on your own estate, which tells you more about our judgement than a reference list would.
Discuss an insurance estate
A free first consultation covering where your product logic actually lives, what your closed book is costing, and whether the constraint you are experiencing is architectural or definitional.
No cost, no obligation. Pricing is transparent and includes GST.