CDR v3.3 — What the Treaty Extension Actually Requires
Treaty reinsurance. 47 new fields. Three computational sections. Every vendor claims CDR readiness. None ships the treaty logic. This is the specification-level analysis.
The Market Did Not Wait
Blueprint Two — the Lloyd’s-led market modernisation programme — was deferred to 2028 in March 2026. The Core Data Record is the structured data standard at its heart. The market’s response was decisive: the LMG Data Council published CDR v3.3 in May 2026, extending the placing standard from open market and facultative reinsurance to treaty reinsurance for the first time.
The consultation involved 68 organisations across the Lloyd’s and London markets, running from October 2024 to February 2025. A cross-market Working Group of treaty experts — including market associations, brokers, carriers, and service vendors — proposed the changes. LIMOSS hosted the consultation materials.
The CDR is not a technology project. It is a data architecture obligation. Version 3.3 means that every carrier with a treaty book now faces a structured data compliance requirement that did not exist under v3.2 — and the central programme that was supposed to deliver the infrastructure has been pushed back by two years.
What CDR v3.3 Introduces
The v3.3 placing CDR extends coverage from the current v3.2 standard to include both proportional treaty (quota share and surplus) and non-proportional treaty (excess of loss and stop loss). This is not a parameter change — it is a structural fork.
| CDR Section | New Fields | Scope | Computation |
|---|---|---|---|
| S27 — Contract | 14 | Surplus amount, quota share percentage, carry-forward attributes, treaty type classification | Surplus calculation, QS percentage application |
| S28 — Loss Participation | 10 | Profit commission corridors, loss ratio interpolation, deficit carry forward, scheduled frequency | Actuarial-grade corridor computation |
| S29 — Reinstatements | 9 | Reinstatement premium sequencing, same-event determination, reinstatement count | Claims-triggered premium sequencing |
| S14 — Commission (Extended) | 9 | Sliding scale parameters, calculation frequency, interpolation basis | Recalculation logic |
| S15, S07, S11 — Extended | 5 | Brokerage, premium, and security extensions for treaty | Field-level extension |
The field applicability matrix introduces a three-way classification: 15 fields apply to proportional treaty only, 11 fields to non-proportional only, and 21 fields are shared across both. This determines which data is captured, which calculations fire, and which downstream systems receive the output. It is a structural workflow distinction, not a configuration toggle.
Three Components No Vendor Ships
Every major vendor used the Blueprint Two delay to sell urgency. They were right about the urgency. But the product behind the pitch is a platform — not a CDR v3.3 specification. Guidewire claims CDR readiness for open market placing. Duck Creek launched a reinsurance product in April 2026 for programme management and exposure tracking — not CDR compliance. No vendor maps CDR v3.3 fields to ACORD RLC elements at specification level. No vendor ships the treaty terms architecture for Sections 27, 28, or 29 — the structured data capture at placing that the exchange layer requires.
Treaty Workflow Routing
15 fields proportional-only, 11 non-proportional-only, 21 shared. A structural fork, not a dropdown. Determines which fields are captured, which validation rules apply, which systems receive the output.
Treaty Terms Architecture
Section 28 requires profit commission corridor parameters — loss ratio interpolation bands, deficit carry-forward rules, sliding scale tables — captured as structured data at placing. Section 29 requires reinstatement terms — number, rate, pro-rata basis, aggregate cap — structured at the point of agreement, not computed. Reinstatement premiums are claim-triggered; the placing workbench captures the contractual parameters that downstream systems will later consume.
CDR Integration Layer
CRP gateway submission, EBOT accounting with treaty-specific TechAccount types, ECOT claims ingestion. The ACORD standards exist. The carrier-side implementation does not.
The Questions Your Platform Vendor Cannot Answer
CDR v3.3 creates a set of architectural questions that sit between the published standard and the platform your carrier runs. Strategy consultancies will analyse the standard. Your vendor will update their platform — eventually. Neither will answer the structural questions that determine whether your implementation works in production.
Does your data model fork correctly?
Proportional and non-proportional treaty are not variants of the same workflow. They require different fields, different calculations, and different downstream routing. A configuration toggle is the wrong abstraction. Does your platform treat treaty type as a structural decision or a dropdown?
Who structures the treaty terms?
Profit commission corridors require parametrised loss ratio bands and deficit carry-forward rules. Reinstatement terms — number, rate, basis, cap — are contractual parameters agreed at placing but captured today as narrative text in slip wordings. The premiums themselves are claim-triggered and computed downstream. Your vendor ships the settlement arithmetic. It does not ship the structured data capture at placing that CDR v3.3 requires. Who owns the gap between agreement and system?
Where does CDR data enter and leave?
CRP gateway submission requires treaty-specific TechAccount types. EBOT accounting requires new message structures. ECOT claims ingestion feeds reinstatement triggers. The ACORD standards exist. The integration architecture between your systems and the market infrastructure does not design itself.
These are not theoretical concerns. They are the same structural questions the practice answered — in production — when it delivered the only validated Blueprint Two Phase 1 and Phase 2 implementation. The difference between v3.2 and v3.3 is that the scope has expanded to treaty. The architectural pattern is the same. We have done it before.
Five Forces Implications
CDR v3.3 is not merely a compliance obligation. It is a structural event that reshapes the competitive dynamics of the London Market across four of the five forces the practice tracks.
| Force | CDR v3.3 Implication |
|---|---|
| F2 — Broker Dynamics | Aon’s Global Director of eCommerce chairs the Ruschlikon Placing Steering Committee that drove this standard. Brokers are building the infrastructure to enforce structured data capture on carriers. CDR v3.3 extends that enforcement to treaty. |
| F3 — Technology ROI | 47 new conditional mandatory fields represent a quantifiable technology investment obligation. Non-compliance means manual treaty processing — operational cost that scales with treaty volume. The investment case is arithmetic, not strategic. |
| F4 — Regulatory Oversight | CDR use case 4 (regulatory reporting and core reporting) now extends to treaty business. Structured data enables automated regulatory validation. The compliance surface area has expanded. |
| F5 — AI Architecture | 226 structured treaty fields create a machine-readable substrate that AI systems can consume directly. Carriers with mature AI architectures exploit it. Carriers without merely comply with it — or fail to. |
CDR v3.3 Is Not the Destination
The LMG Data Council has signalled a clear trajectory. CDR v3.3 is the treaty extension. It is not the final state. Three further developments are in progress or under consultation.
CDR v3.3 compliance is a data architecture project, not a technology project.
The practice delivered the only validated Blueprint Two Phase 1 and Phase 2 implementation in the world. CDR v3.3 extends the same standard to treaty. The architectural pattern is proven. The ten-day diagnostic identifies exactly where your carrier stands and what the remediation sequence looks like.
Begin a Conversation