The Reinsurance data model

Learn the model · Data model · How the cash-flow model works · Ceding a loss distribution through contract structures · The reinsurance suite

This page teaches the data model of the Reinsurance module by following one sample placement from start to finish. You meet each entity as a node you can open. Then the page states the general rule and closes with a reference table.

Start with one placement

Alpina Versicherung AG, a Swiss insurer, buys property-catastrophe protection for 2024 through a London broker. The module ships that placement as nodes:

The platform draws the module's types and how they reference each other:

Prerequisite: the class diagrams on this page are embedded from the Data Modelling plugin's explorer (/DataModelling/Explorer), which Reinsurance does not require. On an installation without it they render nothing; each type's own page under /Reinsurance still lists its properties.

Step 1 — the treaty is the contract root

Alpina Property Cat XL 2024 is a Treaty (Reinsurance/Treaty/Source/Treaty.cs). Its content:

Look at the values in the right column. Every party and every dimension is a node path, never a copied name. The renewal chain (RenewedFrom / RenewedBy) is the exception: it holds the business id and a display name.

Step 2 — the parties

The three parties are full entities with their own fields:

• Cedent (Reinsurance/Cedent/Source/Cedent.cs) is the insurer transferring the risk. The sample Alpina Versicherung AG is domiciled in CH, has legal form AG, head office St. Gallen, rating A+ with a Stable outlook, and reports in Reinsurance/Currency/CHF.
• Broker (Reinsurance/Broker/Source/Broker.cs) is the intermediary. Cartwright Re is a Global broker in London, GB.
• Underwriter (Reinsurance/Underwriter/Source/Underwriter.cs) is the reinsurer's person who holds the pen. Jane Doe is a Senior Underwriter. She is authorised for Reinsurance/LineOfBusiness/Property and …/Casualty in EMEA and APAC, with MaxPremiumAuthority 5,000,000 and no capital cap (MaxCapitalAuthority null).

The fourth party type, Counterparty, is a lean dimension for parties such as retrocessionaires. It carries only a Description. The module ships no Counterparty members.

Step 3 — sections describe what is reinsured

A section is a slice of the business with its own cover. The base record Section (Reinsurance/Source/Section.cs) holds Id, Name, Order, a Parent, and the segment: LineOfBusiness, Product, Peril, Region and Currency, all node paths. ReinsuranceSection (Reinsurance/Source/ReinsuranceSection.cs) adds the annual aggregate band (AnnualAggregateDeductible, AnnualAggregateLimit, both null when there is none), a Premium and GrossNetPremiumIncome.

There are two concrete kinds of section.

ModelledReinsuranceSection is a leaf whose losses come from loss models. The sample Property Cat XL (Id S1) holds:

Check the premium yourself: UpfrontPremiumRelative × GrossNetPremiumIncome = 0.1 × 100 = 10, which matches UpfrontPremiumAbsolute. Measured against the limit, the same 10 is 10 / 40 = 25 % rate on line.

AggregateSection groups other sections. The sample Property Program (Id PROG1) lists them by path in SubSectionIds = ["Reinsurance/Samples/PropertyCatSection"]. Those are path references. The materialized children are a separate list, SubSections, and AllSections walks only that list: the section itself, followed by each resolved sub-section's own walk (Reinsurance/Source/AggregateSection.cs). Nothing resolves SubSectionIds into SubSections automatically. The sample ships subSections: [], so its AllSections returns PROG1 alone. The cession engine works from the ids instead: CededClaims cedes an aggregate section by evaluating each id in SubSectionIds (Reinsurance/Acceptance/Source/CededCashflows.cs).

Covers — the shape of the risk transfer

SectionCover (Reinsurance/Source/SectionCover.cs) is abstract and has two concrete forms:

Premiums

Premium (Reinsurance/Source/Premium.cs) is the base. ReinstatementsPremium adds Reinstatements (one fraction of the base premium per reinstatement). SlidingScalePremium adds RelativeToClaims and MaxPremium. The fixtures in Reinsurance/SampleData/Source/SampleContracts.cs build one of each: two full reinstatements [1.0, 1.0], and a slide of 70 % of claims capped at 15.

Loss-model maps — the deliberate gap

LossModelMap (Reinsurance/Source/LossModelMap.cs) binds an opaque loss-model id to the sections it feeds. property-cat-2024 is a bare string. The contract module holds no reference to any loss-model type, so the contract stays free of loss-modelling dependencies. The Pricing module resolves the id later, in its Program.LossModelsById.

The cession engine adds one more use. When a map's LossModel names another section, the section sees what that section left over, net of its cession. That is how inuring works — see How the cash-flow model works.

Step 4 — the acceptance is the reinsurer's line

An Acceptance (Reinsurance/Acceptance/Source/Acceptance.cs) is the reinsurer's signed share of a set of sections. The shipped Property Cat 40 xs 60 — UWY 2023 holds:

The premium at 100 % is Cover × PremiumRate (AcceptanceReport.Premium100): 40 × 0.25 = 10. The reinsurer's own premium is that times Share: 10 × 1.0 = 10.

The acceptance also carries SectionIds, Commissions, Order and the quote figures ExpectedLossRatio, ExternalCostRatio, InternalCostRatio, Favorite and the read-only PricedLossRatio. The two shipped acceptances leave SectionIds empty. The demo acceptance MTPL XL Layer 1 — 7m xs 3m (2026) fills it: SectionIds = ["ReinsuranceDemo/Submissions/MTPL2026/MotorSection"] with Share 0.5.

The acceptance page draws its structure and result with the platform's hierarchy, tower and waterfall controls:

Where is the link from treaty to acceptance? Neither record names the other. The Treaty has no list of acceptances, and the Acceptance has no treaty field. Other modules make the link: the pricing Program names the treaty in Header and the acceptances in AcceptancesById, and an underwriting Submission lists its acceptances by path. Demo acceptances also sit under their submission in the node tree.

Step 5 — the dimensions

Dimensions are the axes everything is sliced by. Each member is a node, and its identity is its path. Most dimensions derive from DimensionWithDescription (Reinsurance/Source/DimensionWithDescription.cs), which carries one Description. Some dimensions also have a self-referencing Parent, which makes them hierarchies.

The line-of-business and region members follow the FINMA StandRe taxonomies. That is why the SST module can reuse them.

Step 6 — the cash-flow fact

A Cashflow (Reinsurance/Cashflow/Source/Cashflow.cs) is one cell of the cash-flow cube. Property US 2023 — Paid Loss dev 2024 reads:

The record has no Id. Its identity is its node path. The module ships 18 such facts across four segments. How the cash-flow model works follows them through a cession.

Step 7 — the supporting types

• Exposure. ProfileModel (Reinsurance/Source/ProfileModel.cs) carries MarketModelId, AsOfDate and the segment Currency × LineOfBusiness × Region × RiskCategory. ExposureProfile adds a list of ExposureBands (From, To, Average, Count, PremiumRate, LossRatio, SelfInsuredRetention). AggregateExposureProfile instead describes the portfolio with parameters: Count, Exposure, ProfileLimit, ParetoAlpha, BandsPerDecade and more. No profile instances ship.
• Economics. YieldCurve holds Currency, Rates[], ValidAsOf and Periodicity. For example, FINMA USD — SST 2026 has 50 yearly rates, starting with Rates[0] = 0.03427. Index is an economic index time series on a segment. FxRate, ExposureIndex and TimeSeries are value records in Reinsurance/Source.
• Claim development. ClaimRecord is an empty content record. Its source carries ClaimDevelopmentRecord: the payment and incurred patterns of one claim and the ultimate, cumulative-paid and lag statistics derived from them. Its test fixture is Reinsurance/SampleData/Source/SampleClaims.cs: payments 1.0 / 0.5 / 1.0 at 2.5 / 6.0 / 6.5 years, so Ultimate = 2.5. The claims book itself lives in the Claims module.

The rule behind it

1. A reference is a node path. A field that points at another entity is a string holding a path, such as Reinsurance/Currency/USD, and is marked [MeshNode("namespace:Reinsurance scope:descendants nodeType:Reinsurance/Currency")]. The attribute's query lists the candidates. The edit form renders the field as a picker over them, and the UML diagrams above draw it as an association.
2. The node name comes from the content. [MeshNodeProperty(nameof(MeshNode.Name))] on Title or Name makes that field the node's name.
3. Value records are embedded, entities are referenced. SectionCover, Premium, LossModelMap, Commission and TimeSeries live inside their owner. Treaty, Acceptance, the sections, the parties, the dimensions and Cashflow are nodes in their own right.
4. Shared records live at partition level. Everything in Reinsurance/Source/ is compiled into each type that declares shared=@Reinsurance/Source.
5. Loss models are opaque ids. The contract never imports a loss-model type. Pricing resolves the id.

The chain, read left to right:

Treaty ──(Pricing Program.Header / AcceptancesById)──▶ Acceptance
Acceptance.SectionIds ──▶ ModelledReinsuranceSection | AggregateSection.SubSectionIds ──▶ sections
ModelledReinsuranceSection.Models[].LossModel ──▶ loss-model id (Pricing) | another section (inuring)
cession engine ──▶ ceded claims (TimeSeries, negative) · Cashflow facts on Currency × Country × LoB × CashflowType × UWY

Check yourself

Question. The sample section Property Cat XL has GrossNetPremiumIncome 100 and UpfrontPremiumRelative 0.1. What is its rate on line, and which field would you change to make it a 30 % quota share instead?

Answer. The premium is 0.1 × 100 = 10, so the rate on line is 10 / Limit = 10 / 40 = 25 %. For a quota share, replace Cover with ProportionalSectionCover { Cession = 0.30 }, optionally with a ClaimsLimit. Nothing else in the data model changes.

Reference

Next: How the cash-flow model works · The reinsurance suite · Claims data model