About this site
Why reinsurance.dev exists, who it is for, what it deliberately leaves out, how it is made (including how AI is used), and who writes it.
reinsurance.dev is the programming reference for reinsurance analytics that I went looking for when I joined the industry, and could not find.
Why this site exists
Section titled “Why this site exists”When I started in reinsurance in 2007, there was no single reference I could go to. What had been written down was scattered across academic literature, white papers, and conference material, and nearly all of it covered the actuarial side of the business. There was no programming reference: nothing that described the algorithms a reinsurer’s systems run, in terms a software engineer could build from.
Most of what I learned, I learned from Excel spreadsheets. The brilliant people I worked with built them, and they knew far more about the industry and its mechanics than I did. Each workbook held a piece of the business logic in its cells and formulas, and working through them was my education in the domain.
The idea for this site has been in my head for nearly fifteen years, with countless attempts at it in between. Only in the last twelve months have I had the tools to pull it off: AI agents. The section on how this site is made states exactly how I use them.
What it is about
Section titled “What it is about”reinsurance.dev is about the algorithms that drive the business logic of reinsurance analytics: how a contract transforms a loss, how losses from many contracts roll up to a portfolio, and how prices and capital follow from the result. Each concept moves from intuition to a formal definition to code, and the code is runnable Python on the data of one fictional reinsurer, Caldera Re.
I am a software engineer, and the site is written for the reader I was. I would use it to learn what a system like this has to do, to understand the intuition behind those requirements, and to get an example implementation to extend. Other readers come to it for different things:
| Reader | What the site gives them |
|---|---|
| Software engineers | What a reinsurance analytics system has to compute and why, with a reference implementation to start from |
| Data scientists | Implementations to use directly: Python and pandas, runnable in the browser or on your own machine |
| Actuaries, underwriters, portfolio managers | A shared vocabulary and worked examples for specifying requirements to the internal IT team or the contractor that builds these systems |
What it is not
Section titled “What it is not”The site covers one niche of reinsurance: property-catastrophe analytics after the catastrophe model has run. The home page’s scope statement draws that boundary and lists what sits outside it. Within the niche, four limits apply.
- It is not comprehensive. It is a living site. I update it continuously and add new material, and whole areas (scenario analysis and portfolio optimisation among them) are still to come.
- It is not a complete reinsurance analytics system. The code implements each calculation so that you can see how it works. The platform around the calculations (data loading, storage, user interfaces, deployment) is left out.
- It is not production scale. Every worked example runs on a 20-trial dataset small enough to check by hand. Demo scale states what that costs, and At production scale describes what changes with realistic trial counts.
- It is not an authority on methodology. Where practice varies, the site picks one method, labels it as this site’s choice, and names the alternatives. The conventions index lists every such choice. Your organisation may do it differently, and may be right to.
How this site is made
Section titled “How this site is made”This site is written by me, Oliver Baltzer. I’ve spent close to twenty years building reinsurance analytics systems (about the author has the details), and everything here comes out of that experience: the topics, the order they’re taught in, the examples, the mistakes I warn you about. Those warnings exist because I’ve made most of the mistakes myself.
I also use AI heavily in producing this site, and I’d rather tell you exactly how than let you wonder.
What I do
Section titled “What I do”I decide what gets taught and why. I structure the curriculum, design Caldera Re and its portfolio, choose the examples, and set the technical depth. The judgment calls are mine: what an engineer entering this industry actually needs to know, which simplifications are safe and which will hurt you later, where real systems diverge from the textbook picture. They can’t come from anywhere else, because they come from having built these systems and watched them succeed and fail in production.
I also review and verify everything before it’s published: every formula, every contract mechanic, every architectural claim. If it’s on this site, I’m prepared to defend it.
What the AI does
Section titled “What the AI does”I use AI agents as drafting, coding, and checking tools. In practice that means turning my outlines, notes, and rulings into text; writing the Python examples and the charts to my specification; generating variations of examples for me to choose from; recomputing the numbers so that every table reconciles with the Caldera Re data; checking each page against the site’s style guide and notation; and acting as a tireless first reader that asks “would this be clear to someone who has never seen a reinsurance contract?”
It’s the same way I use a compiler or a linter: a tool that makes me faster without changing what I’m responsible for. An AI model doesn’t know what a reinstatement premium does to your cash flow projections, why a naive loss aggregation stops scaling, or which assumptions in a catastrophe model deserve your skepticism. I do, and that knowledge is the product. The tooling is how it gets onto the page at a pace that is compatible with also having a job and a family.
What this means for you
Section titled “What this means for you”Two commitments:
Every technical claim is mine. If something on this site is wrong, that’s my error: not the AI’s, not a source’s. I won’t hide behind the tooling.
Errors get fixed in the open. If you find a mistake, tell me on LinkedIn. I’ll correct it and note the correction. A resource like this earns trust by how it handles being wrong, not by pretending it never is.
Why say any of this
Section titled “Why say any of this”You’re an engineer. You use these tools too, and you’ve seen what happens when AI generates content with nobody behind it who knows the domain. I think the honest position in 2026 is not “no AI was used”. It is “here is exactly where the human judgment lives.” On this site, it lives in close to twenty years of building the systems this site teaches you to build.
If you have questions about the method, or think I’ve drawn a line in the wrong place, I’d like to hear it.
About the author
Section titled “About the author”
I build the computational engines behind reinsurance risk: the systems that price contracts, roll up portfolio losses, and respond to live catastrophes while the numbers still matter.
I joined the industry in 2007 as a high-performance computing (HPC) architect at a Bermuda-based reinsurance start-up, later becoming Chief Architect for Analytics. My teams there helped pioneer real-time portfolio roll-up and real-time marginal pricing, and built an end-to-end hurricane LiveCAT platform that could re-price a live event (forecast, hazard, vulnerability, financial impact) within about twenty minutes of new satellite data. By 2011 we were running a million simulation trials in under a minute, operationally, for the January 1 renewals.
In 2013, I co-founded Analyze Re with two colleagues to bring that capability to the whole industry. We built a cloud-based, vendor-agnostic analytics platform around three convictions: real-time performance, composable flexibility that adapts to each reinsurer’s methodology rather than prescribing one, and deep domain expertise built into the product. Analyze Re’s platform came to be used by brokers, underwriters, retrocession writers, Lloyd’s syndicates, and insurance-linked securities (ILS) funds. Verisk acquired us in 2016, and I’ve since led the architecture and design of Verisk’s next-generation reinsurance financial modelling and portfolio analytics engine.
Along the way I picked up a Master’s in Computer Engineering (HTW Berlin), a Master’s in High-Performance Computing (University of Reading), and a PhD in Computer Science (Dalhousie University). I’ve been programming since 1987, when I got my hands on a Commodore C116 at age eight. I’m back home in Berlin now.
I write reinsurance.dev to teach software engineers how reinsurance analytics actually works. If you’re building these systems, or wrestling with one, I’m always glad to talk shop.
Disclaimer. The views expressed on this site are my own. They do not represent the views of my employer, past or present, or of anyone I am associated with. reinsurance.dev is a personal project: it contains no confidential or proprietary information from any employer, and Caldera Re, its contracts, and its data are fictional.