Captive Insurance Management Software: How Do You Run Twenty Cells Without Twenty Spreadsheets?

A captive is a licensed insurer that nobody staffs like one

Walk into a captive management firm in Burlington or Grand Cayman in the third week of February and you will find the same thing every time: one senior analyst with four workbooks open, reconciling a cell's loss fund against a fronting carrier's collateral requirement while the actuary waits for a loss run and the domicile regulator's annual return is due in six weeks. The captive is a licensed insurance company. It has a regulator, an appointed actuary, an auditor, premium tax obligations and a balance sheet. It is administered by one and a half people and a folder structure.

That works fine at one captive. It stops working at ten, and it stops working violently at a protected cell company with twenty five cells, because the arithmetic stops being arithmetic and becomes bookkeeping with dependencies. Change a participant's exposure base and you have changed their premium allocation, their loss fund contribution, their share of the aggregate, the collateral the fronting carrier will require of them, and the number in their year end statement. In a workbook, that is five edits in five places and a prayer.

The failure that actually hurts is not a wrong number on a report. It is a letter of credit that expired because the renewal date lived in a calendar reminder belonging to someone who changed jobs, and the fronting carrier discovered it before you did. That conversation is expensive and it damages a relationship you cannot easily replace.

Problem one: allocation is a formula, and the formula changes

Group captives allocate. Premium splits between a loss fund the member bears and a shared layer the captive bears, usually with an experience modifier, an exposure base that might be payroll or revenue or vehicle count, and a tier structure that moves a member between funds as their loss history develops. Then dividends or assessments flow back years later once a policy year is mature.

The reason this cannot live in Excel forever is not complexity, it is time. A policy year stays open for a decade. Reserves develop. A claim from 2019 restates in 2026 and every allocation that touched that year has to be recomputed as at the new valuation, without destroying what you already reported to the members in 2021. A workbook has one state: current. It cannot answer what the allocation looked like as at 31 December 2022, which is exactly the question a member's CFO asks when they dispute an assessment.

What a custom build does: valuation dated everything. Every allocation run is a stored, immutable artifact tied to a valuation date and a set of loss data as at that date. Recomputing 2019 in 2026 produces a new run and a variance report against the old one, rather than overwriting history. Members see their own statements through a portal, and the difference between two runs is explainable to them line by line. That single design decision removes most of the disputes.

Problem two: collateral is a live obligation, not a filing cabinet

In a fronted structure the carrier issues the policy and the captive reinsures it, so the carrier holds credit exposure to the captive and demands collateral: a letter of credit, a Regulation 114 style trust, or funds withheld. That collateral is sized against outstanding reserves, which move. It has expiry dates, evergreen clauses with notice periods, issuing bank limits and, in a cell structure, it has to be attributed to the right cell rather than the whole company.

Origami Risk and Ventiv are strong systems and this is not where their strength lies. Both are built as risk management information systems around claims, incidents and exposure data, which they handle very well, and which is why so many captive owners already have one. Neither is designed to administer the captive's own balance sheet, its cell level reinsurance positions, or a collateral instrument register with call and release logic. Sapiens comes from the other direction as core insurance administration, so it assumes a conventional insurer, and a series or cell structure has to be represented as a stack of separate entities, which multiplies configuration effort and licence cost per cell.

What a custom build does: collateral instruments become tracked objects with issuer, amount, effective and expiry dates, notice period, attached cell and the reserve basis they support. The system computes required versus posted collateral at each valuation and flags the gap before the fronting carrier does. Renewal notice dates generate work items with owners. When reserves develop upward, the collateral call is a calculated number with the supporting schedule attached, not an argument.

Problem three: every cell needs its own books, and so does the whole

A protected cell company is legally one entity with statutorily separated cells. Practically it is twenty five sets of books that must not commingle, plus a core, plus a consolidated view. Each cell has premium written, ceded reinsurance, losses paid and reserved, investment income allocated on its share of assets, expenses allocated on some agreed method, and an equity balance that belongs to a participant who wants to know what it is.

Generic accounting packages will do this if you are willing to run a separate company file per cell, which means twenty five closes, twenty five reconciliations and no consolidated position without another spreadsheet. Doing it as departments or classes in a single file gets you the consolidation and loses the separation that regulators and participants care about.

What a custom build does: cell is a first class dimension on every transaction, with hard rules preventing a journal from crossing cells except through a defined intercompany reinsurance or expense allocation mechanism. Statutory basis financials generate per cell and consolidate up. Intercompany quota share and aggregate stop loss between the core and the cells are modeled as actual cessions with their own accounting, because that is what they are, and because the domicile regulator will ask.

Problem four: the compliance calendar is the product

Every domicile has its own filing set. Vermont, Utah, Arizona, Delaware, North Carolina, Tennessee, Cayman and Bermuda each ask for their own annual return, actuarial opinion, audited financials and premium tax return, on their own dates, with their own tolerance for extensions. A management firm running captives across four domiciles carries a compliance calendar with hundreds of dated obligations, and it usually lives in Outlook.

What a custom build does: obligations are generated from a template per domicile per captive type, dated automatically from fiscal year end, assigned to an owner, and closed only with the filed document attached. The evidence trail is a byproduct of doing the work rather than a reconstruction exercise. For a management firm this is also the billing engine, because service fees are usually tied to the same schedule of deliverables, and the two should not be tracked separately.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category prices consistently. A first release covering the captive and cell entity model, participant and loss fund allocation with valuation dating, and the collateral register runs $60,000 to $130,000 and ships in 12 to 18 weeks. The full platform, adding intercompany and outward reinsurance accounting, statutory basis financials per cell, domicile filing calendars, participant portals and management fee billing, runs $180,000 to $400,000 phased over 7 to 12 months.

What pushes cost up in captive work specifically: the number of domiciles, because each one is its own filing template and premium tax rule set. Group captive allocation formulas, because no two are identical and the retrospective rating features are where the arithmetic gets serious. Multi currency, which arrives the moment an offshore domicile is involved. Integration with the fronting carriers' bordereaux and with the TPA loss runs that feed everything. And conversion, because loading ten years of open policy years with their historical valuations is slow, careful work and it is the part that makes the system trustworthy.

What keeps cost down: starting with the captives that share a structure. Do the ten group captives with the same allocation model first, then add the odd single parent ones.

When you should not build

A single parent captive writing general liability and property for its own parent, with a couple of dozen policies and a stable program, does not need software. Your manager, your actuary and your auditor already have a working process and the annual cost of that process is lower than the maintenance cost of a system. Do not build.

Equally, if what you actually need is better claims and exposure data rather than captive administration, buy Origami Risk or Ventiv and be happy. That is a different problem with a good product answer, and confusing the two is the most common mistake we see.

Build when two or more of these are true. You administer eight or more captives or cells. You run a group captive with formula based participant allocation and you have had a member dispute an assessment. You post collateral to more than one fronting carrier. You operate in more than one domicile. You are a management firm whose growth is limited by how many captives an analyst can carry, which is the real economic case: the build raises the captives per analyst ratio, and that is the number your business runs on.

How to choose a developer for captive administration software

Ask them to draw the entity model before you sign anything. Captive, cell, participant, policy year, fund year, program layer, cession, collateral instrument, filing obligation. If they cannot immediately articulate why policy year, accident year and fund year are three different things that must coexist on the same record, they will build you something that gives the wrong answer in year four.

Ask specifically how they handle a retrospective reserve restatement. The right answer involves valuation dated allocation runs and variance reporting, not recalculation in place. Anyone who says the system just recalculates has not administered a long tail book.

Ask what they have integrated. A TPA loss run, a fronting carrier bordereau, a bank feed for the trust account, an investment custodian statement. Name the counterparty and the file, not the category.

Ask who owns the code and put it in the contract before kickoff. You should hold the repository, the infrastructure accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns it from the first commit. In a business where a captive can outlive three software vendors, owning the system that holds your policy year history is not a nice to have.