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.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Business context and lines of business
3. ACORD Reference Architecture alignment
4. Capability model mapping
5. Policy, billing and claims core
6. Product configuration and rating
7. Distribution and partner integration
8. Data model alignment
9. Reinsurance and large commercial
10. Regulatory reporting, security and privacy
11. Non-functional requirements
12. Migration and coexistence
13. Decisions, risks and traceability
14. Glossary and references

1. Introduction and scope

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

1.3 Scope

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

2.1 Lines of business and products

2.2 Value chain and actors

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

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.

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

4.1 Capability-to-application map

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

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.

5. Policy, billing and claims core

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.

5.2 Policy lifecycle events

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.

5.4 Design decisions for the core

6. Product configuration and rating

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.

6.2 Rating design

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

7.1 ACORD standard families and when to use them

7.2 Interface catalogue

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

8.1 Data domains and systems of record

8.2 Canonical model trace

8.3 Data quality rules

8.4 Extension log

9. Reinsurance and large commercial

9.1 Reinsurance programme in scope

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

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.

10.2 Financial reporting data supply

10.3 Security and privacy controls

11. Non-functional requirements

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

12. Migration and coexistence

12.1 Approach options

12.2 Plan by line of business

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

13.1 Architecture decisions

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

13.2 Risks

13.3 Traceability matrix

14. Glossary and references

14.1 Glossary

14.2 References

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.