Reinsurance Submissions: The Data Problem That Shows Up at Renewal

Once a year, a cedant assembles a reinsurance submission and sends it to the market. Underwriters at the reinsurer price a treaty off that submission. Billions of dollars of risk transfer hinge on it. And it is, more often than anyone admits, a spreadsheet — assembled by hand, formatted to no standard, and trusted far more than its provenance deserves. The reinsurance data problem isn't exotic. It's that the most important document in the relationship is built by the least reliable process.

The submission is a summary of a summary

A treaty submission typically contains exposure data, historical loss experience, and portfolio characteristics. Every one of those is a rollup of the cedant's underlying policy and claims systems — systems that, as anyone who's worked inside an insurer knows, don't fully agree with each other. So the submission isn't ground truth; it's an interpretation, produced by whoever owned the extract that year, using whatever definitions were convenient. Change the analyst and you can change the numbers.

The reinsurer, meanwhile, prices off it as if it were fact. They have little choice — they can't see the cedant's raw data. So the entire transaction rests on a summarized artifact whose construction nobody on the receiving end can audit.

Where it actually goes wrong

  • Inconsistent exposure definitions. Sum insured, TIV, PML, occupancy codes — cedants define them differently, and sometimes the same cedant defines them differently across years. A reinsurer comparing this year to last may be comparing two different measurements and calling it a trend.
  • Loss data that doesn't reconcile. Are the losses gross or net? As-of when? Do they include IBNR? Development to date? A submission that's silent on these forces the underwriter to assume — and assumptions compound across a portfolio.
  • The bordereaux tail. On proportional treaties, the relationship doesn't end at binding — monthly bordereaux flow back, in yet another format, and reconciling them to the treaty is a perennial, manual, error-prone chore.
  • Geocoding and accumulation. If the cedant's exposure is geocoded to postcode centroid, the reinsurer's cat model inherits that imprecision and silently mis-estimates accumulation.

Why it persists

Because it survives. The submission gets built, the treaty gets priced, the year closes. Nobody's job is to fix the pipe, and the manual process is just good enough to avoid a crisis in any single year. The cost isn't a visible failure — it's mispricing spread thin across the book, plus weeks of skilled-analyst time every renewal season spent assembling and reconciling instead of analyzing.

What better looks like

The fix is unglamorous and entirely about the data foundation, not the underwriting:

  1. Standardized, defined extracts. The submission is generated from source systems against explicit definitions — gross/net, as-of date, IBNR treatment stated in metadata — not hand-assembled to taste.
  2. Reconciliation built in. Exposure and loss figures tie back to the underlying systems automatically, so a reinsurer's question ("does this reconcile to your financials?") has an answer that isn't "let me get back to you."
  3. Bordereaux automation. Inbound bordereaux are ingested, validated against the treaty, and reconciled without a human keying anything.
  4. Address-level exposure. Geocode to the risk, not the postcode, so accumulation is real.

None of that is an actuarial breakthrough. It's data engineering — extraction, standardization, reconciliation, lineage — applied to the one document the whole relationship depends on. Cedants who get it right submit faster, negotiate from a position of credibility, and stop losing renewal season to spreadsheet archaeology. Reinsurers who can ingest and validate submissions automatically price with less uncertainty load.

Getting the data foundation right beneath the submission — so the number the market prices off can actually be traced and trusted — is exactly the kind of work we focus on with insurers at IntelliBooks.

The treaty is only as good as the submission. And the submission is only as good as the pipe that built it — which, right now, is usually a person and a spreadsheet.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more