Reinsurance submission software builds the document a cedant sends to the reinsurance market at renewal (program structure, exposure profile, loss history, catastrophe model output and underwriting changes) from the cedant's own policy, claims, modelling and finance systems. The useful test of any such tool is not how polished its output looks but whether it holds up where submissions actually fail: figures that cannot be traced to a source, insured value that differs between the exposure chapter and the model input, losses trended on factors nobody approved, and last year's reinsurer questions asked again at roadshow week. Twelve questions cover those failure points, and each can be tested on a renewal the buyer has already done.
This guide sets out the twelve, what a good answer looks like and how to test it. It shows the answers given by Reinsurance Submission Preparation, Botminds' agentic solution for ceded reinsurance teams, on a fictional sample renewal: Harborline Mutual's 2027 property catastrophe program. The sample's companies and people are invented and its figures are sample data or design targets. The questions apply equally to any vendor, to an in-house build or to a spreadsheet process.
Twelve questions for any reinsurance submission software, and how to test each
| Question | A good answer | How to test it on last year’s renewal |
|---|---|---|
| 1. Can every figure name its source? | System, extract, date and who or what produced it, for every number | Pick ten figures from the cover letter and ask for each trail |
| 2. What happens when two systems disagree? | A gap with an owner and a due date, never a silent choice | Feed it a premium that differs between the plan and the letter |
| 3. Can it explain change since last year? | Every material movement split into causes | Ask why insured value and the 1-in-100 moved |
| 4. Does it read last year’s question log? | Each question mapped to the section that answers it | Load last year’s broker log and count the answers |
| 5. What does it do with an unanswerable question? | Declares it, with an owner and a plan | Include a question your data cannot answer |
| 6. Will it ever answer without a figure? | No: every answer cites a figure in the submission | Ask a question whose figure is absent |
| 7. Does it run the cat model? | No: it reads the output; the model stays with its owner | Ask who can change a model setting through it |
| 8. Does it compare model input with exposure? | Yes, at a stated tolerance, before release | Remove a program from the model input file |
| 9. Can it bridge last year’s PML? | A dollar bridge, signed by the cat modelling lead | Ask for the bridge from last year’s 1-in-100 |
| 10. Who can change factors and tolerances? | Named owners; every change versioned and logged | Try to change a trend factor as an analyst |
| 11. Can anything leave without a signature? | No: release waits for named sign-offs | Try to send an unsigned version to the broker |
| 12. What leaves the building? | Redacted locations, a frozen version, a change note for any later edit | Inspect the files the broker would receive |
What is reinsurance submission software?
It is software for the cedant's side of the renewal: assembling the submission, not administering treaties or pricing them. That distinguishes it from reinsurance administration systems, which hold contracts and calculate cessions and recoveries, from broker placement platforms, and from the reinsurer's pricing tools. A submission tool sits upstream of all of them. Its inputs are the cedant's in-force extract, claims listings, catastrophe model output, rate filings and finance plan; its output is a document a reinsurer can price and a trail showing where each figure came from.
Because the inputs differ by cedant and the professional standards for them are unsettled, no product can arrive with "the" submission format. The Casualty Actuarial Society's reinsurance working group put it bluntly in its 2026 call for papers:
"…the industry rarely converges on standard approaches to the key practical and theoretical challenges that persist."
Casualty Actuarial Society, Reinsurance Working Group, January 2026
So the first evaluation question is really a design question: does the tool adapt to your data and your panel's questions, or does it ask you to adapt to its template?
What should reinsurance submission software do, and never do?
It should do the mechanical work and refuse the judgement. The mechanical work is large: reading extracts, summing insured value by state and construction, applying approved trend factors, applying events as-if to the program, tying every figure across chapters and to its source, mapping last year's questions to this year's answers. The judgement is narrow but decisive: the trend factors, the model run and own view of risk, which of two disagreeing premium figures is right, and what to tell the market.
In Reinsurance Submission Preparation those limits are written into each agent. The exposure profile builder never edits an extract or fills a missing field with an estimate. The loss history builder never sets a trend factor or changes a reserve. The cat model reconciler never runs or alters the model. The question answerer never answers without a figure from the submission. The consistency and lineage checker never resolves a gap by choosing a number. A buyer should ask any vendor for the equivalent list, in writing.
Questions 1 to 3: can every figure prove where it came from?
Lineage is the first test because it is the hardest to fake. A tool that produces a handsome PDF but cannot say which extract a figure came from has only moved the spreadsheet problem. On the sample, each of the 1,284 figures carries its value, the section it appears in, the source system, the extract with its date and row count, and the agent or person who produced it; release is blocked while any figure lacks a trail.
Where every figure comes from: value, section, source system, extract and producer
Supervisors increasingly expect the same of any automated process. EIOPA's opinion on AI governance asks insurers, on a risk-based and proportionate basis, to keep records of data and methods "to enable their reproducibility and traceability", and lists human oversight among its expectations. A submission is not usually a high-risk use in that sense, but the same trail answers an internal auditor's question and a reinsurer's.
Question 2 is where tools quietly differ. When the cover letter says $1.14B of subject premium and the finance plan says $1.12B, a tool can pick one, average them, or stop and ask. On the sample the checker raises a gap at the 1.8% difference, names finance as owner, gives a due date and offers a single action, "Finance confirms $1.14B", which only finance can take. Question 3 asks whether change is explained: the sample splits insured-value growth of 9.5% into 4.1 points of indexation and 5.4 points of new policies, and the 1-in-100's movement into five dollar causes.
Questions 4 to 6: does it learn from last year's renewal?
The cheapest improvement in any renewal is not being asked the same question twice. Questions 4 to 6 test whether a tool uses last year's broker log as a specification. On the sample, the panel of seven reinsurers asked 18 questions at the last roadshow; when the chapters were assembled, 15 were answered with their figures and flagged in the margin of the section that answers them, two were partly answered and declared with an owner, and one waited on the cat modelling chapter. At release, 17 were answered and one declared with a plan.
Every question from the panel, by reinsurer and status
Question 6 is the one to press hardest. A language model can produce a fluent answer to any question; in EIOPA's survey of European insurers, inaccurate output was the risk they ranked first for generative AI. The defensible design is that an answer is drafted only from a figure already in the submission and cites where it sits, and that anything else stays open with an owner. Ask a vendor to show what happens when the figure is missing.
Questions 7 to 9: does it respect the catastrophe model?
The catastrophe model belongs to the catastrophe modelling lead, and a submission tool should treat it that way. The NAIC's catastrophe modelling primer counts version changes among regulators' concerns, because the same model can give materially different results after an update (NAIC); a tool that re-runs models or applies its own adjustments makes that problem worse by adding a second, unaccountable version. On the sample, the cat model reconciler reads the occurrence and aggregate curves for the vendor model and the own view, compares the model input with the exposure profile, builds the bridge from last year's 1-in-100 and reports where the program's top is reached. It found the model input $2.3B short of the exposure, because a coastal program's 6,214 locations were loaded after the input was built, and asked the lead to re-run. The lead re-ran and signed.
That is the test for question 8: remove a program from last year's model input file and see whether the tool notices before release. The PML itself, and the places it moves without anyone deciding, are traced in probable maximum loss in a reinsurance submission.
Questions 10 to 12: who decides, who signs, what leaves
Control questions decide whether the tool is safe to give to a busy team in October. On the sample, the renewal's rules are settings: the broker and due date, whether last year's questions are carried forward, a 0.5% cross-chapter tolerance, a $5M large-loss threshold, ten years of history, the trend factors with the actuary's name and approval date, and the two people who sign. Changes are versioned and on the audit trail. An analyst cannot alter the trend factors; the agents cannot alter anything they read.
Release requires the catastrophe modelling lead's signature on the model chapter and the head of ceded reinsurance's on the whole, after six checks. What leaves is defined: the submission document, exposure by ZIP code and grid with no policyholder names or street addresses, events and large losses, EP curves with the own-view note, and the answers letter. The released version is frozen and any later change is a new version with a change note.
Does reinsurance submission software run the cat model?
It should not, and Reinsurance Submission Preparation does not. Running the model, choosing its settings and applying an own view of risk are decisions the catastrophe modelling lead signs, and in many companies the same output feeds capital and rate filings. A submission tool's job is to read the output, check that the exposure it was run on is the exposure in the submission, explain the movement from last year and refuse release when the two disagree beyond tolerance. Tools that bundle a model are a different category, closer to exposure management, and should be evaluated as models.
How to run a fair test on last year's renewal
The best demonstration uses a renewal whose outcome you already know. Last year's submission, its source files and the broker's question log give a vendor a real problem and give you a way to score the result.
A demonstration script for any submission tool
- Bring last year’s source files, released submission and question log
The vendor rebuilds the submission; you compare it with what you sent.
- Plant three faults
A program missing from the model input, a large loss missing from the list, a premium that differs between plan and letter.
- Count what it catches and how
Each fault should become a gap with an owner, not a corrected number.
- Score last year’s questions
How many are answered from the rebuilt submission, with a figure and a location?
- Trace ten figures
Choose them from the cover letter; every one should name its extract and date.
- Try the controls
Change a trend factor as an analyst; release without the cat lead’s signature. Both should fail.
- Inspect the output files
No policyholder names or street addresses; a version number; a change note on any edit.
Three ways to build a submission, compared
Most ceded teams choose between three approaches, and many mix them. Spreadsheets and email are flexible and familiar. A central data warehouse or reinsurance system gives one store, but has to be fed and kept current. Agents working across the existing systems leave each system as the source of its data and do the reading, tying and drafting between them.
Spreadsheets, a central store, or agents across the systems you already run
Spreadsheets and email, or a central store: Copied into the workbook or loaded into the store, often from last year’s file
Agents across existing systems: Read from each system’s extract at its date, with the trail kept
Spreadsheets and email, or a central store: Found by whoever notices, often at review or roadshow week
Agents across existing systems: Raised on assembly day as a gap with an owner and due date
Spreadsheets and email, or a central store: In an email chain with the broker
Agents across existing systems: Mapped to this year’s sections and answered with figures
Spreadsheets and email, or a central store: Output pasted in; input rarely checked against exposure
Agents across existing systems: Output read; input checked against the exposure chapter
Spreadsheets and email, or a central store: File permissions and version names
Agents across existing systems: Named owners, versioned settings, signatures required before release
How long does reinsurance software take to implement?
It depends almost entirely on the inputs, so a vendor's answer should start with questions about yours. The work of a first renewal is mapping: which extract, at which cut-off, from which system, owned by whom, checked at what tolerance. If your extracts already exist and last year's submission and question log are to hand, the mapping is bounded by your own files rather than by a systems build; if exposure for a managing agent's book arrives only as a monthly bordereau, the first renewal will surface that as a gap. A sensible pilot runs on last year's renewal first, as in the script above, and then on the live one.
Where Botminds' Reinsurance Submission Preparation fits, and where it does not
It fits a cedant whose submission is built by a small ceded team from several systems, whose panel asks detailed questions, and whose catastrophe modelling and actuarial owners want their numbers used as they signed them. On the sample renewal the results were these:
Reinsurance Submission Preparation on the fictional sample renewal
15of 18
of last year’s questions answered when the chapters were assembled
sample data
1,284
figures in the submission, each with its source trail
sample data
$2.3B
of insured value missing from the model input, found before the broker saw it
sample data
6days
from first source file to a submission ready for the market
design target
It does not fit a team looking for a catastrophe model, a treaty administration system or a pricing tool, and it does not replace the policy or claims system as the source of the data. It does not decide the program or the price. If the gap in your renewal is in the contract wording rather than the submission, Botminds' Treaty Wording Comparison is the relevant solution, and its buyer's guide is the place to start. The inputs a pilot needs are listed in what to bring on day one.
Questions people ask
Is reinsurance submission software the same as reinsurance administration software?
No. Administration systems hold treaties and calculate cessions, statements and recoveries after placement. Submission software works before placement, building the document the market prices from; the two meet only when the placed structure is carried into administration.
Can software answer last year's reinsurer questions?
It can draft answers when the figure exists in this year's submission and show where it sits. On the sample, 15 of 18 were answered on assembly and 17 by release; the eighteenth, on roof age for 31% of North Carolina homeowners, went out declared with an owner and a plan.
Does it work for casualty programs?
The sample shown is a property catastrophe program. A casualty submission is built around development triangles, policy limit profiles and large-claim histories rather than catastrophe model output, so ask any vendor to demonstrate on a casualty renewal of your own before assuming the property result carries over.
Can the broker see the submission before release?
On the sample, nothing is sent to anyone until the head of ceded reinsurance releases it. The broker receives a frozen version 1.0, and any later change arrives as a new version with a change note.
What does a pilot need from us?
Last year's released submission and question log, the source extracts behind it, the approved trend factors and the model output with its input file. With those, the pilot can rebuild last year's renewal and be scored against what was actually sent.