What do you buy when nobody sells software for your product?

Most policy administration systems are built around a shape that is easy to recognise: a customer buys a policy, pays a premium, and the coverage runs for a defined term until it renews or lapses. The shape is so common that the software industry has quietly treated it as the definition of insurance itself.

But insurance is older and stranger than its software. Some of the most interesting products being built today separate the policyholder from the exposures that drive premium, begin with little or no premium at inception, and change whenever accepted declarations alter the risk. This is the story of one of them.

The MGA in this story designed a complementary commercial insurance product with no established policy-administration template behind it — no vendor module to switch on, no configuration preset, no reference implementation to copy.

The policyholder operates at portfolio level, while the exposures that drive coverage and premium emerge beneath it over time. Business reaches it through wholesale brokers rather than a direct sales force. And its most unusual property is temporal: premium can begin at zero. There may be nothing to charge on day one, because the exposure the product covers does not yet exist. It emerges over time, as declarations arrive from several different sources, and the premium emerges with it.

That means the policy's financial state is not an annual figure with occasional endorsements. It is a living calculation, revised as accepted declarations change the underlying exposure — and the accounting records underneath it have to move in step, or the policy and financial records can quietly drift apart.

Consider what a conventional system assumes, and what this product breaks.

A conventional system assumes one policyholder who is also the source of information about the risk. Here, the policyholder is a portfolio-level entity, and the declarations that change exposure arrive from multiple parties, each with their own formats and rhythms. A conventional system assumes premium is set at inception and adjusted occasionally. Here, premium is an output that must be recalculated whenever the underlying declarations change. A conventional system treats the policy record and the accounting ledger as loosely related documents reconciled at period-end. Here, they must remain aligned continuously — because at any given moment, someone may need to know exactly what is on cover and exactly what is owed, and the two answers must agree.

Operated manually, a product like this consumes people. Every declaration needs checking, every recalculation needs doing, every discrepancy between the policy view and the financial view needs hunting down. The team's discipline holds it together, but discipline is not an operating model, and it does not scale with the book.

Facio modelled the product on its own terms rather than forcing it into a familiar shape.

Declarations from the programme's various sources are validated before they are allowed to change anything. Accepted information updates the relevant exposure under the product's approved rules, premium is recalculated according to the commercial model the MGA actually designed, and the policy state and financial ledger are updated as connected but distinct records. Reconciliation runs as part of the operation itself — identifying inconsistencies as they appear rather than letting them accumulate for a painful period-end discovery.

The result is an operation led by exceptions. The routine flow — declaration arrives, validates, exposure updates, premium recalculates, ledger follows — can proceed without a person manually carrying every step, while unresolved declarations and decisions outside the approved rules remain with authorised people. People are reserved for the cases that deserve them: a declaration that doesn't resolve, an exposure pattern outside the rules, a decision the product's logic was never meant to make alone.

The instinct, for a founder whose product no vendor seems to understand, is to build the operating system in-house. That instinct is usually right about the diagnosis and wrong about the cure. Building internally means becoming a software-maintenance organisation on top of being an MGA — a second business, running alongside the first, forever.

The alternative demonstrated here is different: infrastructure flexible enough to express the product's real structure — its parties, its declarations, its calculations, its exceptions — without every difference becoming a custom engineering project. A product with genuinely unusual economics became, operationally, one of the simplest things this MGA runs.