# Insurance Solution Design: [Programme or platform name] on the ACORD Reference Architecture

> Solution design for an insurance core platform (policy administration, rating and product
> configuration, billing, claims, distribution and reinsurance) aligned with the ACORD Reference
> Architecture and the ACORD data standards. It maps the solution to the seven Reference
> Architecture facets (Business Glossary, Information Model, Data Model, Capability Model, Component
> Model, Process Model, Product Model), selects the ACORD message families for each partner
> interface (Property and Casualty XML and AL3, Life and Annuity XML, Global Reinsurance and Large
> Commercial, Next-Generation Digital Standards for APIs), and records the regulatory reporting
> touchpoints and the migration of the in-force book. Versions as listed on acord.org in October
> 2026: Data Model 2.14, Information Model 2.14, Business Glossary 2.17, Capability Model 2.6,
> Component Model 2.4, Process Model 2.5, Product Model 2.1, NGDS Final Release v1-13-0 (May 2026).
> Replace every `[bracketed]` value and every row marked *Example*. This is a documentation format,
> not legal, actuarial or regulatory advice.

<!--
Guidance: How to use this template
- Write one design per programme (for example a commercial lines policy platform replacement).
  Enterprise-wide capability work belongs in the Business Capability Map
  (`architecture/business-capability-map`); this document consumes it.
- Fill section 2 (lines of business and volumes) and section 4 (capability mapping) first. They
  decide which core systems are in scope and which ACORD message families you need.
- ACORD standards and Reference Architecture files are available to members and subscribers. Record
  only facet names, versions and your own mapping here; do not paste ACORD definitions, schema
  fragments or model diagrams into this document.
- Regulatory sections name the regimes that usually apply. Confirm the applicable rules for each
  legal entity and jurisdiction with compliance and actuarial colleagues.
- Related documents: Solution Architecture (`architecture/solution-architecture`), Integration
  Design (`architecture/integration-design`), Data Migration Strategy
  (`architecture/data-migration-strategy`), Master Data Management Design
  (`architecture/master-data-management-design`), Business Capability Map
  (`architecture/business-capability-map`), DORA ICT Third-Party Register
  (`compliance/dora-ict-third-party-register`).
-->

## Document control

<!-- Guidance: Identify the programme, the insurer legal entities in scope and the ACORD versions the design is pinned to. A change of core system vendor or of the migration approach is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [INS-SD-001] |
| Programme | [Programme name] |
| Insurer legal entities | [Entity names, jurisdictions, regulators] |
| Lines of business in scope | [Personal auto / Homeowners / Commercial property / Term life / Annuities] |
| ACORD Reference Architecture versions used | [Data Model 2.14, Information Model 2.14, Capability Model 2.6, Component Model 2.4, Process Model 2.5, Product Model 2.1, Business Glossary 2.17] |
| ACORD data standards used | [P&C XML release, AL3 release, Life and Annuity XML release, NGDS v1-13-0] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@chief-architect], [@head-of-underwriting], [@claims-director], [@cfo-delegate], [@ciso], [@data-protection-officer] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Business case], [Capability map], [Integration design], [Migration strategy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Architecture board | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Business owner (underwriting and product) | [@name] | [Decision] | YYYY-MM-DD |
| Claims owner | [@name] | [Decision] | YYYY-MM-DD |
| Finance and actuarial | [@name] | [Decision] | YYYY-MM-DD |
| Security and privacy | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added broker AL3 download interface and reinsurance bordereaux |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build of commercial property release 1 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Business context and lines of business](#2-business-context-and-lines-of-business)
3. [ACORD Reference Architecture alignment](#3-acord-reference-architecture-alignment)
4. [Capability model mapping](#4-capability-model-mapping)
5. [Policy, billing and claims core](#5-policy-billing-and-claims-core)
6. [Product configuration and rating](#6-product-configuration-and-rating)
7. [Distribution and partner integration](#7-distribution-and-partner-integration)
8. [Data model alignment](#8-data-model-alignment)
9. [Reinsurance and large commercial](#9-reinsurance-and-large-commercial)
10. [Regulatory reporting, security and privacy](#10-regulatory-reporting-security-and-privacy)
11. [Non-functional requirements](#11-non-functional-requirements)
12. [Migration and coexistence](#12-migration-and-coexistence)
13. [Decisions, risks and traceability](#13-decisions-risks-and-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: State the business problem in insurance terms (speed to market, combined ratio, broker experience, regulatory pressure), not in technology terms. Pitfall: scoping "the core" without naming which lines of business and which jurisdictions move first. -->

### 1.1 Purpose

This document describes the target solution for [programme name]: which core insurance capabilities
are delivered by which applications, how those applications exchange data with brokers, agents,
reinsurers and service providers, and how the in-force book moves from the legacy platform. It uses
the ACORD Reference Architecture as the shared vocabulary between business, vendors and integrators,
so that every capability, data entity and message in this design can be traced to an industry model
element rather than to a vendor's product terminology.

### 1.2 Drivers and outcomes

| ID | Driver | Measurable outcome | Owner |
|---|---|---|---|
| DRV-001 *(Example)* | New commercial products take 9 months to launch on the legacy system | Launch a product variant in 8 weeks using configuration only | [@head-of-product] |
| DRV-002 *(Example)* | Brokers re-key submissions from email and PDF | 60% of new business submissions received as structured messages | [@distribution-lead] |
| DRV-003 *(Example)* | Legacy policy system out of vendor support in 2028 | Legacy decommissioned after last policy renews off it | [@cio] |
| DRV-004 *(Example)* | Manual data assembly for financial and solvency reporting | Contract-level data delivered to the finance subledger daily | [@cfo-delegate] |
| [DRV-nnn] | [Driver] | [Outcome and target] | [@owner] |

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| [*Example:* Commercial property and liability, UK and Ireland entities] | [*Example:* Life and pensions, handled by a separate programme] |
| [*Example:* Quote, bind, issue, endorse, renew, cancel] | [*Example:* Actuarial reserving models (consumed as outputs only)] |
| [*Example:* First notice of loss to claim closure for property] | [*Example:* Investment management] |
| [*Example:* Direct billing and broker account current statements] | [*Example:* General ledger replacement] |
| [*Example:* Outward treaty and facultative reinsurance cessions] | [*Example:* Assumed reinsurance] |

### 1.4 Constraints and assumptions

- [*Example:* The policy, billing and claims suite is a SaaS core platform selected in the
  build-versus-buy decision (reference ADR-003); customisation is limited to its configuration layer
  and extension APIs.]
- [*Example:* The insurer holds ACORD membership with access to P&C XML, AL3, NGDS and the Reference
  Architecture files.]
- [*Example:* Regulatory reporting runs on the existing finance data platform; this programme
  supplies data to it and does not replace it.]

## 2. Business context and lines of business

<!-- Guidance: Quantify the book. Volumes drive the non-functional requirements and the migration plan. Pitfall: missing seasonal peaks such as 1 January and 1 April renewal dates in commercial and reinsurance markets. -->

### 2.1 Lines of business and products

| ID | Line of business | Products | Channels | In-force policies | New business per year | Renewal pattern |
|---|---|---|---|---|---|---|
| LOB-001 *(Example)* | Commercial property | SME package, mid-market property | Brokers | 48,000 | 9,000 | 35% renew 1 January |
| LOB-002 *(Example)* | Commercial liability | Public and products liability, employers' liability | Brokers, MGAs | 31,000 | 6,500 | Spread evenly |
| LOB-003 *(Example)* | Fleet motor | Fleet, haulage | Brokers | 4,200 | 700 | 1 April peak |
| [LOB-nnn] | [Line] | [Products] | [Channels] | [Count] | [Count] | [Pattern] |

### 2.2 Value chain and actors

| Actor | Role in the solution | Interaction style |
|---|---|---|
| Broker or agent | Submits risks, receives quotes and documents, collects premium on account | Portal, broker system integration, AL3 or XML downloads |
| Managing general agent (MGA) | Underwrites under delegated authority, reports bordereaux | File and API exchange, delegated authority reporting |
| Policyholder | Self-service, payments, claims notification | Customer portal and contact centre |
| Claims service provider | Loss adjusting, repair, legal | Assignment and status messages |
| Reinsurer and reinsurance broker | Treaty and facultative placement, accounts, claims | Global reinsurance and large commercial messages |
| Regulator and auditor | Supervisory and statutory reporting | Reports from the finance data platform |

### 2.3 Current state summary

[Summarise the current application landscape, pain points and technical debt. Reference the Current
State Assessment (`architecture/current-state-assessment`) rather than repeating it.] *Example:* One
mainframe policy system holds property and liability; motor runs on a separate package; claims are
on a third system with nightly batch interfaces; brokers receive documents by email; billing is
embedded in the policy system and cannot support instalments.

## 3. ACORD Reference Architecture alignment

<!-- Guidance: Show which facets you actually use and for what. A facet you list but never trace to is decoration. Pitfall: mixing versions across facets so the capability, component and data views no longer match. -->

### 3.1 Facet usage

The ACORD Reference Architecture is a set of seven interrelated industry models. Use each one for a
specific design purpose and record the version pinned for the programme.

| Facet | Version pinned | Use in this design | Owner |
|---|---|---|---|
| Business Glossary | [2.17] | Agreed meaning of business terms in requirements, user stories and data dictionary | [@business-analyst-lead] |
| Information Model | [2.14] | Conceptual subject areas and relationships for the canonical model (section 8) | [@data-architect] |
| Data Model | [2.14] | Logical entities to validate the vendor data model and design the operational data store | [@data-architect] |
| Capability Model | [2.6] | Capability-to-application mapping and heatmap (section 4) | [@enterprise-architect] |
| Component Model | [2.4] | Service boundaries and build-or-buy scoping of components (section 5) | [@solution-architect] |
| Process Model | [2.5] | Reference workflows mapped to ACORD messages (sections 5 and 7) | [@process-lead] |
| Product Model | [2.1] | Notation for product structure in product configuration (section 6) | [@product-architect] |

### 3.2 Alignment principles

1. Use ACORD terms for business concepts in requirements and interfaces; keep vendor terms only
   inside the vendor's configuration.
2. Map every in-scope application function to at least one Capability Model element, and every
   canonical entity to an Information Model subject area.
3. Prefer an ACORD message for an external partner interface where one exists and the partner
   supports it; justify every proprietary format with an ADR.
4. Extend ACORD structures only through the extension mechanisms the standard provides, and register
   every extension in the extension log (section 8.4).
5. Pin versions per release and plan upgrades as change requests, not as silent drift.

## 4. Capability model mapping

<!-- Guidance: Map capabilities at the level of detail where the build-or-buy decision is made, usually the second or third level of the hierarchy. Pitfall: listing capabilities without owning applications and without a gap rating. -->

### 4.1 Capability-to-application map

Use your own short capability labels traced to the Capability Model element identifiers your licence
provides.

| ID | Capability (own label) | ACORD Capability Model reference | Target application | Current fit | Gap rating | Action |
|---|---|---|---|---|---|---|
| CAP-001 *(Example)* | Submission intake | [Element ID] | Core platform underwriting workbench | Manual email intake | High | Configure intake; add broker API |
| CAP-002 *(Example)* | Risk assessment and underwriting referral | [Element ID] | Core platform rules plus third-party data | Spreadsheet rules | High | Rules configuration, data enrichment service |
| CAP-003 *(Example)* | Rating and premium calculation | [Element ID] | Rating engine | Hard-coded in legacy | High | Externalise rates (section 6) |
| CAP-004 *(Example)* | Policy issuance and documents | [Element ID] | Core platform plus document composition | Batch print | Medium | Template migration |
| CAP-005 *(Example)* | Premium billing and collection | [Element ID] | Core billing module | No instalments | High | Configure plans and payment gateway |
| CAP-006 *(Example)* | Claims notification and triage | [Element ID] | Claims module | Phone and email | Medium | Digital first notice of loss |
| CAP-007 *(Example)* | Claims settlement and recovery | [Element ID] | Claims module | Legacy claims system | Medium | Migrate open claims |
| CAP-008 *(Example)* | Reinsurance cession and accounting | [Element ID] | Reinsurance management system | Spreadsheets | High | Procure or extend |
| CAP-009 *(Example)* | Distribution partner management | [Element ID] | Core platform producer module | Partial | Low | Configure commissions |
| [CAP-nnn] | [Capability] | [Reference] | [Application] | [Fit] | [High / Medium / Low] | [Action] |

Rate a gap High when the capability is missing or unfit and blocks a driver (release 1), Medium when
it works with manual effort or risk (release 1 or 2), and Low when it is fit for purpose (retain or
migrate as is).

### 4.2 Component boundaries

Group capabilities into components using the Component Model as the reference for boundaries. Each
component has one owning team and one system of record.

| Component ID | Component (own label) | Capabilities | System of record for | Owning team |
|---|---|---|---|---|
| CMP-001 *(Example)* | Underwriting and policy | CAP-001 to CAP-004 | Policy, coverage, endorsement | Policy platform team |
| CMP-002 *(Example)* | Billing | CAP-005 | Invoice, payment plan, receivable | Billing team |
| CMP-003 *(Example)* | Claims | CAP-006, CAP-007 | Claim, reserve, payment | Claims platform team |
| CMP-004 *(Example)* | Party and producer | CAP-009 | Party, producer, licence | Customer data team |
| CMP-005 *(Example)* | Reinsurance | CAP-008 | Treaty, cession, bordereau | Reinsurance team |

## 5. Policy, billing and claims core

<!-- Guidance: Describe how the core modules interact across the policy lifecycle. Name the system of record for each event. Pitfall: letting billing and claims read policy data from a nightly copy, which breaks mid-term changes and coverage verification. -->

### 5.1 Context view

The context view shows the core components, the partner entry point and the data flow to finance.
Every arrow is an interface in section 7.2 or an event in section 5.2.

```mermaid
flowchart LR
  BRK[Broker systems and portal] -->|Submissions, quotes, documents| GW[API gateway and B2B hub]
  MGA[MGAs] -->|Bordereaux, delegated authority data| GW
  GW --> UW[Underwriting and policy]
  UW --> RATE[Rating engine]
  UW --> PRD[Product configuration]
  UW --> BIL[Billing]
  UW --> CLM[Claims]
  CLM --> BIL
  UW --> RI[Reinsurance]
  CLM --> RI
  UW --> PTY[Party and producer]
  BIL --> PAY[Payment gateway]
  UW --> DOC[Document composition]
  UW --> ODS[Operational data store]
  BIL --> ODS
  CLM --> ODS
  RI --> ODS
  ODS --> FIN[Finance subledger and reporting]
```

### 5.2 Policy lifecycle events

| Event ID | Event | Producer | Consumers | Notes |
|---|---|---|---|---|
| EVT-001 *(Example)* | Policy bound | Underwriting and policy | Billing, reinsurance, document composition, data store | Carries policy version and effective date |
| EVT-002 *(Example)* | Policy endorsed (mid-term change) | Underwriting and policy | Billing (pro-rata premium), reinsurance, claims | Version history kept for coverage at date of loss |
| EVT-003 *(Example)* | Policy renewed | Underwriting and policy | Billing, broker download | Renewal offer and acceptance are separate states |
| EVT-004 *(Example)* | Policy cancelled | Underwriting and policy | Billing (return premium), reinsurance | Reason code required |
| EVT-005 *(Example)* | Claim opened | Claims | Reinsurance (large loss notification), data store | Coverage verified against policy version |
| EVT-006 *(Example)* | Reserve changed | Claims | Reinsurance, finance | Threshold triggers reinsurer notification |
| EVT-007 *(Example)* | Claim payment issued | Claims | Billing or payments, finance | Sanctions screening before release |
| [EVT-nnn] | [Event] | [Producer] | [Consumers] | [Notes] |

### 5.3 Policy state model

The policy state model is owned by the underwriting and policy component. Billing, claims and
reinsurance react to its transitions; they never change policy state themselves.

```mermaid
stateDiagram-v2
  [*] --> Submission
  Submission --> Quoted: rated
  Submission --> Declined: underwriting decline
  Quoted --> Bound: accepted
  Quoted --> Lapsed: quote expired
  Bound --> InForce: effective date reached
  InForce --> InForce: endorsement
  InForce --> RenewalOffered: renewal invited
  RenewalOffered --> InForce: renewed
  RenewalOffered --> Expired: not renewed
  InForce --> Cancelled: cancellation
  Expired --> [*]
  Cancelled --> [*]
  Declined --> [*]
  Lapsed --> [*]
```

### 5.4 Design decisions for the core

| Decision | Options | Choice | Reason |
|---|---|---|---|
| Policy versioning | Overwrite; effective-dated versions; full temporal (effective and transaction time) | *Example:* Full temporal | Claims must see coverage at the date of loss and finance must see what was known at a reporting date |
| Billing integration | Embedded billing; separate billing module fed by events | *Example:* Separate module fed by events | Supports instalments and broker account current without changing policy |
| Claims coverage check | Copy of policy in claims; live call to policy service | *Example:* Live call with cached snapshot at first notice | Avoids stale coverage while tolerating policy service outage |
| Document composition | Inside core platform; separate composition service | *Example:* Separate service | Shared across policy, billing and claims letters |

## 6. Product configuration and rating

<!-- Guidance: Product configuration is where speed to market is won or lost. Describe how a product is defined, versioned, tested and released, and who may change it. Pitfall: rating logic duplicated between portal, core platform and broker systems. -->

### 6.1 Product structure

Use the Product Model notation (or your own equivalent) to describe each product as a hierarchy of
product, coverage, limit, deductible, rating factor and rule. Keep the product definition in one
repository and publish it to every system that needs it.

| Element | Example *(Example)* | Owner | Changed by |
|---|---|---|---|
| Product | SME package 2027 | Product manager | Product release |
| Coverage | Buildings, contents, business interruption | Underwriting | Product release |
| Limit and deductible options | Buildings limit bands, voluntary excess options | Underwriting | Product release |
| Rating factor | Construction class, occupancy, postcode risk score | Pricing actuary | Rate release |
| Underwriting rule | Refer if sum insured above authority limit | Underwriting | Rule release |
| Form and wording | Policy wording, endorsements, schedule | Legal and product | Document release |

### 6.2 Rating design

| Topic | Design | Notes |
|---|---|---|
| Rating engine location | [Embedded in core / external rating service] | *Example:* External service called by core and broker API |
| Rate table storage | [Versioned tables with effective dates] | Rates selected by policy effective date, not by transaction date |
| Rate change release | [Pricing pipeline with tests] | Back-test against a sample of in-force policies before release |
| Explainability | [Rating worksheet stored with quote] | Required for complaints and audit |
| Use of models | [Rating factors from pricing models] | Record model owner and validation; see Model Validation Report (`ai-data/model-validation-report`) where models are used |

### 6.3 Product release process

1. Product manager raises a product change request with impact on coverages, rates, rules and
   documents.
2. Pricing and underwriting update definitions in a non-production product repository.
3. Automated regression rates a frozen sample of policies and compares premium deltas against the
   approved tolerance.
4. Compliance reviews customer-facing wordings and filing obligations in each jurisdiction.
5. The release is promoted with an effective date; quotes before that date keep the prior version.

## 7. Distribution and partner integration

<!-- Guidance: Pick one message family per partner interface and record why. Brokers often support only one format; check before you design. Pitfall: treating ACORD as a single format; it is a family of standards with different scopes and technologies. -->

### 7.1 ACORD standard families and when to use them

| Family | Typical use in this design | Technology | Selection notes |
|---|---|---|---|
| Property and Casualty XML | Broker and agency system real-time quote, policy and claims exchange in P&C | XML messages | Use where the broker platform supports it; agree the release and the implementation guide |
| AL3 | Policy and accounting downloads to agency management systems, mainly in the US P&C market | Fixed-format batch | Common for downloads to agency systems; plan a mapping layer from the canonical model |
| Life and Annuity XML | New business, in-force and illustration exchange for life and annuity products | XML messages | Relevant only if life products are in scope |
| Global Reinsurance and Large Commercial | Placing, accounting and settlement, and claims between insurers, brokers and reinsurers | XML and JSON | See section 9 |
| Next-Generation Digital Standards (NGDS) | Fine-grained APIs and microservices for new digital journeys | Technology-agnostic resource definitions and schemas for RESTful APIs and microservices | Final Release v1-13-0 (May 2026); a v1-14-0 candidate was listed in October 2026 |
| ACORD Forms | Standard application and certificate forms | Forms | Use where the market expects them, for example certificates of insurance |

### 7.2 Interface catalogue

| ID | Interface | Partner | Direction | Standard and version | Pattern | Volume | Owner |
|---|---|---|---|---|---|---|---|
| INT-001 *(Example)* | New business submission | Top 20 brokers | Inbound | P&C XML [release] | Request and response through B2B hub | 300 per day | Distribution |
| INT-002 *(Example)* | Policy download | US agency systems | Outbound | AL3 [release] | Daily batch per agency | 12,000 records per day | Distribution |
| INT-003 *(Example)* | Quote API for digital brokers | Digital trading platforms | Inbound | NGDS v1-13-0 | REST through API gateway | 40 per minute peak | Digital |
| INT-004 *(Example)* | First notice of loss | Brokers, policyholders | Inbound | NGDS v1-13-0 | REST | 150 per day, up to 2,250 per day (15 times) after a storm | Claims |
| INT-005 *(Example)* | Claims assignment to adjusters | Loss adjusters | Outbound | P&C XML [release] | Asynchronous message | 120 per day | Claims |
| INT-006 *(Example)* | MGA bordereaux | Delegated authority partners | Inbound | ACORD delegated authority standards [release] | Monthly file | 25 files per month | Delegated authority |
| INT-007 *(Example)* | Reinsurance technical accounts | Reinsurance brokers | Outbound | GRLC [release] | Message per account | Quarterly | Reinsurance |
| [INT-nnn] | [Interface] | [Partner] | [Direction] | [Standard] | [Pattern] | [Volume] | [Owner] |

### 7.3 Integration architecture

- Route all partner traffic through a B2B and API layer that validates messages against the agreed
  schema release, authenticates the partner, and logs every message with a correlation identifier.
  Follow the Integration Design (`architecture/integration-design`) and API Management Platform
  Design (`architecture/api-management-platform-design`).
- Translate between ACORD messages and the core platform's own API in one mapping layer. Do not let
  the core platform's proprietary model leak to partners.
- Version partner interfaces explicitly. Support the previous ACORD release for an agreed overlap
  period, published in the partner onboarding pack.
- Use the Event-Driven Architecture Design (`architecture/event-driven-architecture-design`) for the
  lifecycle events in section 5.2.
- For file exchange (AL3 downloads, bordereaux), follow the B2B EDI and File Transfer Design
  (`architecture/b2b-edi-file-transfer-design`).

### 7.4 Partner onboarding checklist

- Agreed message family, release and implementation guide reference.
- Test cases covering new business, mid-term change, renewal, cancellation and error responses.
- Certificate and credential exchange, with rotation dates.
- Code list mapping (for example coverage, peril and loss cause codes) signed off by both parties.
- Service levels for response time and file delivery windows.
- Contact list and incident route for message failures.

## 8. Data model alignment

<!-- Guidance: Trace your canonical and vendor entities to Information Model subject areas and Data Model entities, and log every gap. Pitfall: adopting the full ACORD Data Model physically; it is a logical reference, so design the physical store for your access patterns. -->

### 8.1 Data domains and systems of record

| Domain | System of record | Key identifiers | Data owner | Master data approach |
|---|---|---|---|---|
| Party (insured, claimant, broker, reinsurer) | Party and producer component | Party ID, external IDs (company number, licence number) | [@customer-data-owner] | Registry style MDM; see `architecture/master-data-management-design` |
| Product | Product configuration repository | Product code and version | [@product-owner] | Single repository |
| Policy and coverage | Underwriting and policy | Policy number, version, term | [@underwriting-owner] | Transactional |
| Billing | Billing | Account, invoice, payment plan | [@finance-owner] | Transactional |
| Claim | Claims | Claim number, exposure, reserve line | [@claims-owner] | Transactional |
| Reinsurance | Reinsurance | Treaty, section, cession | [@reinsurance-owner] | Transactional |
| Reference data | Reference data service | Code lists | [@data-governance-lead] | ACORD code lists where available |

### 8.2 Canonical model trace

| Canonical entity | Information Model subject area | Data Model entity or entities | Vendor entity | Gap or extension |
|---|---|---|---|---|
| CAN-001 *(Example)* Policy | Policy | [Entity names from licensed model] | PolicyPeriod | None |
| CAN-002 *(Example)* Coverage | Policy and product | [Entity names] | Coverage | Vendor lacks coverage-level deductible history; extension EXT-001 |
| CAN-003 *(Example)* Party | Party | [Entity names] | Contact | Split person and organisation roles |
| CAN-004 *(Example)* Claim | Claims | [Entity names] | Claim, Exposure | None |
| CAN-005 *(Example)* Location | Party and location | [Entity names] | Location | Add geocode and risk score attributes, EXT-002 |
| [CAN-nnn] | [Subject area] | [Entities] | [Vendor entity] | [Gap] |

### 8.3 Data quality rules

| Rule ID | Entity | Rule | Threshold | Action on failure |
|---|---|---|---|---|
| DQ-001 *(Example)* | Location | Every insured location has a validated address and geocode | 99% | Refer to underwriting before bind |
| DQ-002 *(Example)* | Party | Sanctions screening completed for parties receiving payment | 100% | Block payment |
| DQ-003 *(Example)* | Claim | Loss date falls within a policy version's effective period | 100% | Coverage review task |

### 8.4 Extension log

| ID | Standard element extended | Reason | Approved by | Raised with ACORD |
|---|---|---|---|---|
| EXT-001 *(Example)* | Coverage deductible history | Required for claims at date of loss | Data design authority | [Yes / No] |
| EXT-002 *(Example)* | Location risk attributes | Catastrophe exposure management | Data design authority | [Yes / No] |

## 9. Reinsurance and large commercial

<!-- Guidance: Reinsurance often stays on spreadsheets because it is out of the core vendor's scope. Decide explicitly. Pitfall: cession calculated on a different policy version than the one billed. -->

### 9.1 Reinsurance programme in scope

| ID | Programme | Type | Basis | Data needed per policy or claim |
|---|---|---|---|---|
| RI-001 *(Example)* | Property quota share | Proportional treaty | Risks attaching | Sum insured, premium, line of business, location |
| RI-002 *(Example)* | Property per risk excess of loss | Non-proportional treaty | Losses occurring | Claim incurred by risk, date of loss |
| RI-003 *(Example)* | Catastrophe excess of loss | Non-proportional treaty | Losses occurring per event | Event code, aggregated losses |
| RI-004 *(Example)* | Facultative placements | Facultative | Per risk | Placement slip reference, share |

### 9.2 Design

- Calculate cessions from the policy and claim events in section 5.2, using the same policy version
  that billing used.
- Exchange placing, technical accounts and claims with brokers and reinsurers using the Global
  Reinsurance and Large Commercial standards where counterparties support them; record the release
  in the interface catalogue.
- Keep treaty terms in a reinsurance system, not in the core platform's rating tables.
- Report ceded premium and recoveries to finance with the contract-level keys required by the
  financial reporting design (section 10).

## 10. Regulatory reporting, security and privacy

<!-- Guidance: Name the regimes, then describe the data the solution must supply and the controls it must implement. Do not restate the rules. Pitfall: designing reporting as an afterthought, so contract grouping and cash-flow data needed by finance are missing at source. -->

### 10.1 Regulatory touchpoints

Confirm with compliance which rules apply to each legal entity. The table lists regimes that
commonly affect insurance platform design; check the current applicable text for each.

| ID | Regime | Typical design impact | Applies to | Owner |
|---|---|---|---|---|
| REG-001 | IFRS 17 Insurance Contracts (effective for annual periods beginning on or after 1 January 2023) | Contract-level data with grouping attributes, cash flows and dates delivered to the actuarial and finance subledger | [Entities reporting under IFRS] | [@finance-lead] |
| REG-002 | Solvency II (Directive 2009/138/EC as amended; review amendments in Directive (EU) 2025/2, OJ 8 January 2025; Member States apply the new rules from 30 January 2027, check the consolidated text) | Data for technical provisions, quantitative reporting and data quality evidence | [EU entities] | [@actuarial-lead] |
| REG-003 | Solvency UK (the PRA's reformed UK regime) | Reporting and disclosure data for UK entities; check the PRA's current policy statements | [UK entities] | [@actuarial-lead] |
| REG-004 | NAIC model laws as adopted by US states, for example the Insurance Data Security Model Law | Information security programme, cybersecurity event investigation and notification; check each state's enacted version | [US entities] | [@ciso] |
| REG-005 | DORA (Regulation (EU) 2022/2554) for EU insurers | ICT risk management, incident reporting, register of ICT third-party providers for the SaaS core | [EU entities] | [@ciso]; see `compliance/dora-ict-third-party-register` |
| REG-006 | GDPR and local data protection law | Lawful basis, special category data in claims (health), retention, data subject rights | [All entities] | [@dpo]; see `compliance/dpia` |
| [REG-nnn] | [Regime] | [Impact] | [Entities] | [@owner] |

### 10.2 Financial reporting data supply

| Data item | Source | Frequency | Consumer | Control |
|---|---|---|---|---|
| Policy and coverage with contract grouping attributes | Policy | Daily | Finance subledger | Reconciliation of policy counts and written premium |
| Premium transactions | Billing | Daily | Finance subledger | Billing to ledger reconciliation |
| Claims paid and reserves | Claims | Daily | Finance and actuarial | Reserve movement reconciliation |
| Ceded premium and recoveries | Reinsurance | Monthly | Finance | Treaty statement reconciliation |

### 10.3 Security and privacy controls

| Control ID | Control | Design |
|---|---|---|
| SEC-001 *(Example)* | Partner authentication | Mutual TLS for B2B, OAuth 2.0 client credentials for APIs, per-partner scopes |
| SEC-002 *(Example)* | Least-privilege access to claims health data | Attribute-based access on claim sensitivity flag |
| SEC-003 *(Example)* | Payment fraud and sanctions | Screening before claim payment release, dual approval above threshold |
| SEC-004 *(Example)* | Data residency | Customer data stored in [region]; verify SaaS sub-processors; see `compliance/data-residency-sovereignty-assessment` |
| SEC-005 *(Example)* | Audit trail | Immutable log of underwriting decisions, rate versions and claim reserve changes |

## 11. Non-functional requirements

<!-- Guidance: Give every quality a number and a measurement method. Insurance peaks come from renewal dates, catastrophe events and month-end billing. Pitfall: sizing claims intake for an average day instead of the day after a storm. -->

| ID | Quality | Requirement | Measure | Source |
|---|---|---|---|---|
| NFR-001 *(Example)* | Performance | Broker quote API responds within 3 seconds at the 95th percentile | API gateway metrics | DRV-002 |
| NFR-002 *(Example)* | Capacity | Claims intake handles 15 times the daily average for 72 hours after a catastrophe event | Load test | Claims operations |
| NFR-003 *(Example)* | Availability | Quote and bind 99.9% in broker trading hours | Monthly availability report | Distribution |
| NFR-004 *(Example)* | Batch window | AL3 and billing batches complete by 05:00 local time | Scheduler logs | Agency SLAs |
| NFR-005 *(Example)* | Recoverability | RPO 15 minutes, RTO 4 hours for policy and claims | DR test | Resilience tiering, see `architecture/resilience-tiering-ha-dr-design` |
| NFR-006 *(Example)* | Auditability | Rating worksheet and rule outcomes retained for policy life plus [n] years | Retention audit | Compliance |
| [NFR-nnn] | [Quality] | [Requirement] | [Measure] | [Source] |

The NFR Catalogue (`requirements/nfr-catalogue`) holds the full list; keep this table to the
requirements that shape the architecture.

## 12. Migration and coexistence

<!-- Guidance: In-force book migration is the riskiest part of a core replacement. Decide the approach per line of business and show how coexistence works. Pitfall: converting policies without their history, so claims on old losses cannot verify coverage. -->

### 12.1 Approach options

| Approach | Description | Pros | Cons |
|---|---|---|---|
| Renewal-based migration | Each policy moves to the new platform at its next renewal | Low conversion risk, natural rewrite of terms | 12 months or more of dual running |
| Bulk conversion | All in-force policies converted at a cutover date | Short dual running | High data risk, large reconciliation effort |
| Hybrid | New business and renewals on new platform, bulk conversion of the remainder after [n] months | Balances risk and dual running | Two migration mechanisms to build |

### 12.2 Plan by line of business

| ID | Line | Approach | Start | Legacy decommission | Open claims handling |
|---|---|---|---|---|---|
| MIG-001 *(Example)* | Commercial property | Renewal-based | [YYYY-MM] | After last renewal plus claims run-off decision | Open claims stay on legacy claims system until closed or bulk moved |
| MIG-002 *(Example)* | Commercial liability | Hybrid | [YYYY-MM] | [YYYY-MM] | Long-tail claims bulk converted with full reserve history |
| MIG-003 *(Example)* | Fleet motor | Bulk conversion at 1 April renewal season | [YYYY-MM] | [YYYY-MM] | Convert open claims at cutover |

### 12.3 Coexistence rules

- One system of record per policy at any time, recorded in a routing table that the broker
  interfaces and claims intake consult.
- Brokers receive one download format regardless of which platform holds the policy.
- Finance receives one combined feed with a source-system attribute.
- Reconciliation per run: policy counts, written premium, outstanding reserves and receivables. Use
  the Data Migration Reconciliation template (`project/data-migration-reconciliation`) and the Data
  Migration Strategy (`architecture/data-migration-strategy`).
- Cutover steps follow the Cutover Plan (`project/cutover-plan`).

## 13. Decisions, risks and traceability

<!-- Guidance: Keep decisions short here and link to the ADRs. The traceability matrix proves each driver is served by capabilities, components and interfaces. Pitfall: a risk list without owners and dates. -->

### 13.1 Architecture decisions

| ADR | Decision | Status |
|---|---|---|
| ADR-001 *(Example)* | Use NGDS for new digital broker APIs; P&C XML for existing broker platforms | [Accepted] |
| ADR-002 *(Example)* | Full temporal policy versioning in the core platform | [Accepted] |
| ADR-003 *(Example)* | Buy a SaaS core suite; build rating as an external service | [Accepted] |
| ADR-004 *(Example)* | Renewal-based migration for property | [Proposed] |

Record each in the Architecture Decision Log (`architecture/architecture-decision-log`).

### 13.2 Risks

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Brokers cannot move to the chosen ACORD release in time | Medium | High | Support prior release in mapping layer for 12 months | [@distribution-lead] |
| RSK-002 *(Example)* | Vendor data model lacks attributes needed for financial reporting | Medium | High | Early data trace (section 8.2); extensions agreed before build | [@data-architect] |
| RSK-003 *(Example)* | Catastrophe event during migration overloads dual running claims intake | Low | High | Claims intake on new platform first; surge runbook | [@claims-lead] |
| RSK-004 *(Example)* | Rating differences between legacy and new platform at renewal | High | Medium | Premium delta tolerance check and broker communication | [@pricing-lead] |

### 13.3 Traceability matrix

| Driver | Capabilities | Components | Interfaces | NFRs | Regulatory |
|---|---|---|---|---|---|
| DRV-001 *(Example)* | CAP-003, CAP-004 | CMP-001 | INT-003 | NFR-001 | REG-006 |
| DRV-002 *(Example)* | CAP-001, CAP-002 | CMP-001, CMP-004 | INT-001, INT-003 | NFR-001, NFR-003 | REG-005, REG-006 |
| DRV-003 *(Example)* | CAP-001 to CAP-007 | CMP-001 to CMP-003 | INT-002 | NFR-005 | REG-005 |
| DRV-004 *(Example)* | CAP-005, CAP-007, CAP-008 | CMP-002, CMP-003, CMP-005 | INT-007 | NFR-006 | REG-001, REG-002, REG-003 |

## 14. Glossary and references

<!-- Guidance: Use your own short definitions. For agreed business meanings, point to the licensed ACORD Business Glossary instead of copying it. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| AL3 | ACORD fixed-format standard used mainly for policy and accounting downloads to agency systems |
| Bordereau | Periodic report of risks or claims sent by a delegated authority partner or to a reinsurer |
| Cession | Share of a risk or loss transferred to a reinsurer |
| Endorsement | Mid-term change to a policy |
| GRLC | ACORD Global Reinsurance and Large Commercial standards |
| In-force book | Policies currently providing cover |
| MGA | Managing general agent underwriting under delegated authority |
| NGDS | ACORD Next-Generation Digital Standards for fine-grained APIs |
| System of record | The one application whose data is authoritative for an entity |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ACORD Reference Architecture, acord.org/standards-architecture/reference-architecture | Facet versions listed October 2026 | Sections 3, 4, 8 |
| ACORD Data Standards overview, acord.org/standards-architecture/acord-data-standards | Checked October 2026 | Section 7 |
| ACORD Next-Generation Digital Standards, acord.org | Final Release v1-13-0 (May 2026) | Section 7 |
| IFRS 17 Insurance Contracts, ifrs.org | Issued May 2017, amended June 2020; effective for annual periods beginning on or after 1 January 2023 | Section 10 |
| EIOPA, Solvency II regulation and policy page, eiopa.europa.eu | Checked October 2026 | Section 10 |
| Bank of England PRA, Solvency II and Solvency UK pages, bankofengland.co.uk | Checked October 2026 | Section 10 |
| [Internal standards] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the ACORD Reference Architecture facets (Business Glossary, Information
Model, Data Model, Capability Model, Component Model, Process Model, Product Model) and the ACORD
data standard families as named on acord.org in October 2026. ACORD standards and models are
proprietary to ACORD and available to members and subscribers; this template uses only their names
and version numbers, and no ACORD definitions, schemas, code lists or model content are reproduced.
Regulatory regimes (IFRS 17, Solvency II, Solvency UK, NAIC model laws, DORA, GDPR) are named for
orientation only; check the current official text and the rules that apply to each entity. ACORD is
a trademark of its owner; this template is not affiliated with or endorsed by ACORD. This template
is original text written for this collection. Check the current official versions before use.
Template licence: MIT.