Burn the silos: why best-of-breed insurance software is no longer the safe choice

The policy administration system you run was chosen by someone who compared four of them across sixty rows of a spreadsheet, and they chose correctly. It handles endorsements the way your book actually endorses. The document tool you bought afterwards reads a schedule of values better than that policy system ever would have. Billing came from somewhere else again, because the policy system's version of billing could not do trust accounting and yours has to.

Every one of those decisions was right on its own terms. A vendor who has spent fifteen years on one problem beats a vendor who has spent eighteen months on it as one module out of nine, and for a long time buying the specialist and connecting it was strictly better than accepting a generalist's version of the same job.

It was also a risk decision, and that is the half people forget when they argue against it. A stack you assembled is a stack you can take apart. If the rating engine disappoints you, you replace the rating engine, not the firm. Nobody signs one contract, one roadmap and one support queue for the whole business when the alternative is a suite that is adequate at eight things and takes three years to leave.

That is the received view, stated as strongly as I can state it, and it is what most of this industry runs on today. It is also a large part of why a forty-person MGA can go to market looking like a carrier. AM Best's annual market segment report on managing general agents put direct premiums written through MGAs and other delegated authority enterprises at $108.7 billion in 2025, up 17.8 percent on the $92.3 billion of 2024, against roughly 5 percent growth for the wider United States property and casualty industry. Assembled stacks built that.

So the question was never whether best-of-breed worked. It is what it costs now, and the cost has moved.

Say you decide to start capturing distance to coast on every insured location. This is not a programme. It is a Tuesday decision, made because the cat model came back and somebody in the room wants that number in front of them before they quote anything else on the Gulf.

Now count the places one fact has to be declared before anybody can act on it.

• Intake, so a broker or a portal can supply it.

• Document reading, so it comes off the schedule of values instead of being typed a second time.

• The underwriting screen, so it appears next to the location the underwriter is already looking at.

• The rating and appetite rules, so it can change a decision rather than sit there decoratively.

• The policy record itself, so it survives to bind and does not evaporate at issuance.

• Reporting, so somebody can finally ask what the book looks like inside two miles.

Six declarations of one fact. Six change processes, six owners, and at least two of them behind a vendor ticket with a quarterly release train attached to it.

None of this is peculiar to insurance. It is an enterprise condition that insurance has an unusually acute form of, because our records are long lived and our field definitions are contractual. Salesforce's 2026 Connectivity Benchmark Report, a survey of 1,050 IT leaders published in February 2026, puts the average organisation at 957 applications with 27 percent of them connected to one another.

Here is the part that actually hurts. Those six systems do not end up disagreeing because somebody made a mistake. They disagree because each one has its own idea of what a location is. Integration moves values between systems. It does not move meaning. So the field lands in all six, and four months later somebody notices that reporting measures to the nearest named coastline while the intake form let brokers round to the nearest mile, and now two numbers that both say distance to coast are different and both are defensible.

That is the reconciliation project. It has a name in most firms. It happens roughly annually, it is never finished, and it is never finished because the input never stops: every new attribute, every new workflow, every new product line feeds it. Deloitte's 2026 global insurance outlook, published in October 2025, describes the same condition from the outside: insurers struggling with fragmented data sprawl and outdated systems, while executives hesitate to commit to yet another multi-year core replacement.

Money is not the constraint. Datos Insights, surveying carrier CIOs and technology leaders for its June 2026 insurer IT outlook, puts insurer technology spend at 4.6 percent of direct written premium this year against 3.7 percent a decade ago, with core systems the single largest category and more than half of a large carrier's total IT budget. Spending is up by roughly a quarter in ten years. Nobody I have met believes their systems became a quarter easier to change.

The real cost is not the six declarations. It is the seventh thing nobody asks for. When a change reliably costs a quarter, people stop proposing changes worth less than a quarter, and the strategy your business is capable of quietly shrinks to the strategy your systems already support.

Nothing on the invoice describes that.

The pitch on every stage this year is that the problem above is already solved. Expose the systems over a protocol, describe the tools in a catalogue, point an agent at the lot, and let a model do the reconciliation an analyst used to do by hand.

We have watched a great deal of that get built. It is the same move, one storey up.

An agent reading six systems does not resolve their disagreement. It reads six versions of distance to coast and then picks one, averages them, or tells you very fluently about whichever one it queried first. It has no basis for choosing, because the basis for choosing was never written down anywhere. It lived in the head of the analyst who built the mapping, and it left when she did.

A connector catalogue over five systems that disagree is a sixth system. It has its own schema to maintain, its own drift, its own owner and its own opinion about what an account is. You have not removed a layer. You have added the least legible one in the set, because when this one is wrong it is wrong in confident English.

The uncomfortable version of the argument is this. An abstraction cannot be better than the foundation it reads. Excellent reasoning over an incoherent data model produces excellent reasoning about the wrong numbers, and it produces it faster than anyone can check it. The bottleneck was never the intelligence. It was that nobody, human or otherwise, could get a straight answer out of the business about what the business already knows.

So build the foundation instead. That is the whole bet.

In Riska, an object is a kind of thing you keep and a record is one of them. Location, coverage, exposure, quote version, and whatever else your book needs that we did not think of. You define the objects, the attributes on them and the relationships between them yourself, under the labels your own team already uses, and you do it in a settings screen rather than in a statement of work.

Distance to coast, in that arrangement, is one attribute on location. Adding it is the entire project.

What happens next is the only claim in this piece that really matters. A view is a saved query over an object's records, so the new attribute is a column and a filter the moment it exists. An appetite dimension reads a value off the record and maps it to a score, so the new attribute can score. A portfolio metric is a saved query too, so it can be grouped on and rolled up across the book. A workflow trigger names the attribute it watches and the value that should fire it. And Ask Riska is handed your object model in your own words, so you can ask about the new attribute in the sentence you would have used with a colleague.

None of those five surfaces was told about the attribute. There was nothing to tell them. They resolve against the same objects, so there is one definition of distance to coast and it is the one all of them read.

The property runs backwards too, which is the half people miss. Every appetite knockout and referral is written down as it fires, against the version of the rule that fired it. So the rule you wrote this morning is a thing you can count this afternoon. Not we think we are declining more habitational than we intended, but the number, by rule, taken from the decisions themselves. A split stack cannot close that loop, because the decision and the measurement live in different buildings.

And the configuration is versioned. Objects, attributes, views, document types and rate books move together as one release. You publish it and every surface reads the new shape at the same moment, which is a sentence a best-of-breed stack cannot say about anything.

Three objections, and all three are fair. I would rather answer them here than in a procurement call.

It is a bigger bet

Five vendors are five smaller bets. One system is one bet. If we are wrong about something structural you are more exposed than you would be with a point solution you could swap out inside a quarter, and there is no clever answer to that. What we can do is make the exit real rather than rhetorical. Your records are yours. Riska syncs policy, billing and claims data from external systems of record as readily as it acts as one, and a firm that keeps its policy administration system and runs everything upstream of bind here is a supported way to work, not a consolation prize.

You trade depth for coherence

This is the real one, so let me state it without softening. A vendor who has spent fifteen years on one narrow problem will be deeper on that narrow problem than we are. If your entire business turns on one specialist capability, keep the specialist and connect it. The argument in this post then applies to everything around it, which is most of it.

Migration is work

Moving a book is moving a book. Nobody has made that pleasant and we have not either.

And here is the thing the approach genuinely gives up, which nobody raises until month four. A system that lets you define any object and any attribute will also happily let you define three attributes that mean the same thing. Flexibility is not free of discipline. A rigid system says no to a bad model. Ours says yes, and six months later you have two attributes called class code and an argument about which one the board pack used.

We build the tools that make that visible: one history per record, versioned releases, views that show where an attribute is actually used. We cannot make the modelling decision for you, and we would be lying if we said the product removes the need for someone to own it.

Riska is a rebuild of the insurance software stack from the ground up, on one assumption: the model underneath is the product, and everything else is a surface over it.

Objects, attributes and relationships you define yourself, in the words your own team uses. That is the data model, and it is the floor the rest of this stands on.

Every surface resolves against it instead of keeping a copy. An extractor names the object and the path a field belongs to, so what comes back is a proposed change to your records rather than a summary of a file. A rate table names the object it rates. A workflow trigger names the attribute it watches. A portfolio metric is a query over the same records. That is the idea behind the Data Mesh, and the reason it deserves a name is that it is what makes the next twenty things cheap instead of expensive.

Because the model is one thing rather than six, an agent can be handed the whole of it. Ask Riska reads your objects and relationships under your own labels, writes the query, runs it, and puts the rows it read next to the number it gives you. Nothing had to be integrated for that to work. There was nothing to integrate.

So we did not build another layer over the stack. Burn the silos. Build the thing they were compensating for.

There is a great deal left to do. We are early, this industry is enormous, and the list of parts we have not built yet is longer than the list of parts we have. But the direction is settled and we do not intend to hedge it. If you have spent a career watching a good idea die inside a mapping document, come and build this with us.