prEN 18356-1

SLOVENSKI STANDARD
01-julij-2026
Dostop do podatkov strank in prenosljivost podatkov v zavarovalniškem sektorju -
1. del: Semantični vmesnik in podatkovni model
Customer Data Access and Portability in the Insurance Sector - Part 1: Semantic
interface and data model
Zugriff und Portabilität für Kundendaten in der Versicherungswirtschaft - Teil 1:
Semantische Schnittstelle und Datenmodell
Ta slovenski standard je istoveten z: prEN 18356-1
ICS:
35.240.01 Uporabniške rešitve Application of information
informacijske tehnike in technology in general
tehnologije na splošno
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2026
ICS
English Version
Customer Data Access and Portability in the Insurance
Sector - Part 1: Semantic interface and data model
Zugriff und Portabilität für Kundendaten in der
Versicherungswirtschaft - Teil 1: Semantische
Schnittstelle und Datenmodell
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 445.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 18356-1:2026 E
worldwide for CEN national Members.

Contents Page
European foreword. 3
Introduction . 4
1 Scope . 6
2 Normative references . 7
3 Terms and definitions . 7
4 Symbols and abbreviations . 9
5 Business process and functionality for the customer data access and portability . 9
5.1 The business process . 9
5.2 Preconditions of the business process for a customer data access . 10
5.3 Customer data access request . 10
5.4 Customer data access validation and data preparation . 11
5.5 Customer data access response . 11
5.6 The semantic process for the customer data access . 12
6 Data models for the customer data access . 13
6.1 General . 13
6.2 Data types . 14
6.3 Data model for the insurance policy and party data . 16
6.4 Data model for motor insurance products . 42
6.5 Data model for private property insurance products . 69
6.6 Data model for commercial property insurance products . 101
6.7 Data model for liability insurance products . 148
6.8 Data model for personal accident insurance products . 175
6.9 Data model for legal expenses insurance products . 191
6.10 Data model for travel insurance products . 210
6.11 Data model for financial loss insurance products . 228
6.12 Data model for life insurance products . 251
Annex A (informative) Digital Attachments . 287
Bibliography . 288

European foreword
This document (prEN 18356-1:2026) has been prepared by Work Group 1 “Digital Interchange” of
Technical Committee CEN/TC 445 “Digital information interchange in the Insurance Industry”, the
secretariat of which is held by DIN.
This document is currently submitted to the CEN Enquiry.
Introduction
The objective of this European Standard for customer data access and portability in the insurance sector
is to support the implementation of the EU General Data Protection Regulation 2016/679 (GDPR) Article
20 and of the proposed EU Regulation on a Framework for Financial Data Access (FIDA) Articles 2(1), 4
and 5.
The EU Commission referenced this European standardisation priority as Action 12 in the 2024 Annual
Union Work Programme for Standardisation, as well as in the Rolling Plan for ICT Standardisation 2024
as part of the requested actions for “Fintech and Regtech Standardisation” fostering innovation for the
Digital Single market (Action 5).
This document contains the semantic specification of the interfaces for the required access to customer
insurance data. In addition, CEN Technical Specifications describe the application programming
interfaces (API) at the technical implementation level, such as FprCEN/TS 18356-2, in the Open API
Technology.
The European standard for APIs and data formats is in demand in the insurance sector to support the
right of the consumer for the data portability on the basis of GDPR Article 20 and the right of customers
and data users for the customer data access to data holders on the basis of the proposed EU FIDA
Regulation.
Consumers will benefit from
• more effective control over their personal data with the ability to control how their data is shared
and used;
• standardised portability of their personal data from a data holder to a data user.
Insurance customers, consumers as well as companies, will benefit from
• standardised APIs which will result in a better flexibility to select the best products on the
market;
• standardised data access supporting more choice and more individualised, data-driven products
and services in the insurance sector;
• products that are better targeted to their demands and needs, including through more valuable
advice;
• improved customer choice by enabling them to switch providers more easily;
• more optimal insurance coverage and increased financial inclusion of otherwise underserved
customers;
• digital data entry at insurers and insurance intermediaries which will reduce their costs and will
likely reduce the insurance premiums for the customers;
• better risk and claims management and analysis resulting in improved loss prevention.
The insurance industry, insurers and insurance intermediaries, will benefit from
• standardised APIs for data access and portability which will boost the digitalisation and will have
significant efficiency gains in the data economy of the insurance sector;
• standardised customer data that will allow for the development of personalised tools for
customers, such as insurance dashboards;
• digital data entry at insurers and insurance intermediaries which will reduce their costs;
• standardised customer data resulting in better advice to the customers;
• standardised customer data that will enable tailored offers for customer-specific and data-driven
products, coverages, and services;
• increased cross-selling due to a better overview over the insurance status of the customers;
• better risk and claims management and analysis resulting in improved loss prevention for the
customers.
Moreover, the European API standard is an important prerequisite for enabling efficient and cost-
effective customer data access and portability (“plug-and-play communication”). Only a well-accepted
open standard ensures a level playing field for all market participants, especially for SMEs, and protects
consumers from lock-in effects.
Finally, the European API standard for customer data access and portability is an important step towards
a European digital single market for the insurance sector, which is currently still focused on national
markets. The standard will facilitate cross-border and cross-sector cooperation, supporting the
development of market innovations and the platform economy.
1 Scope
This document specifies the customer (natural or legal person) data access and portability in the
insurance sector based on the insurance-specific part of the proposed EU FIDA Regulation and therefore
contains:
• Semantic specifications for the processes to support the data access and portability. These
specifications define on the business level the functions and the behaviour for the following
process interfaces:
 Request of the customer to the data holder for an actual transfer of the customer data (FIDA
Article 4).
 Transfer of the requested customer data from the data holder to the requesting customer
(FIDA Article 4).
 Request of a data user to a data holder for an actual transfer of customer data under a
permission of the customer (FIDA Article 5).
 Transfer of the requested customer data from the data holder to the requesting data user
(FIDA Article 5).
• Semantic specifications for the customer data to be transferred by the above processes. The scope
of the customer data is limited to the insurance-specific part defined in the proposed FIDA
Regulation Article 2 (1) and Article 3 (3). These specifications define on the business level each
element of the customer data with unique name, precise definition, and value type (text, number,
amount, quantity, percentage, date, etc.). The composition of these data elements forms a
semantic data model for the insurance-specific customer data. The data model consists of the
following parts:
 General data of the insurance client (including personal details, address, contact information,
payment means, etc.).
 General data of the insurance policy (including policy number, insurance product and
coverages, insured period, premium amounts, etc.).
 Data specific to the insurance client’s assets and risks, collected in an assessment for the
purposes of a demands and needs test.
 Data depending on line of business, such as
 Motor insurance (details about vehicle, usage, drivers),
 Property insurance (details about building, household, or other objects),
 Liability insurance (details about insured parties and their activities),
 Personal accident insurance (details about insured persons and their activities),
 Legal expenses insurance (details about insured parties and objects),
 Travel insurance (details about insured parties and objects),
 Financial loss insurance (details about insured parties and risks),
 Insurance-based investment products and private and occupational pension products
(details about insured persons and the savings, investments, pension rights, etc.).
This document defines the semantic process specifications for the data access from a customer or a data
user to the data holder for the customer, policy, and claims data. The processes for the identification,
authentication, and authorisation of customers and data users and the processes for the handling of
customer permissions are not in the scope of this standard.
This document specifies the processes and the data models on the semantic level in a syntax-neutral
format, independent from its representation in a concrete implementation syntax. Separate CEN
Technical Specifications describe the application programming interfaces (API) at the technical
implementation level, such as FprCEN/TS 18356-2, in the Open API Technology.
The focus of this document is on the data elements usually required for the customer data access in
European insurance markets. For a concrete implementation of the customer data access in a specific
market, this standard could be extended by market-specific data elements. Many data elements in this
standard utilize coded value lists, some of which are based on ISO or other internationally standardised
code value lists, such as country or currency code values. Other code value lists are implemented on a
market-specific basis, as the requirements for the value lists are very different due to diverse market
conditions. This document makes no attempt to standardise these code value lists.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-3, Codes for the representation of names of languages — Part 3: Alpha-3 code for comprehensive
coverage of languages
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 4217, Codes for the representation of currencies
ISO 8601, Date and time format
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
customer
natural person or a legal person who is a micro, small or medium-sized enterprise, who makes use of
financial products and services, and it means insurance clients or insured persons, excluding third-party
beneficiaries
Note 1 to entry: Definition in accordance with proposed EU Regulation on a Framework for Financial Data Access
(FIDA).
3.2
insurance client
customer that requests insurance coverage and pays the premium to an insurance company in exchange
for the coverage provided by an insurance policy
Note 1 to entry: Insurance client is a synonym for the term “policyholder”.
3.3
insured person
party that is covered by an insurance policy
3.4
insurance intermediary
party that offers advice and arranges policies for clients
Note 1 to entry: Definition in accordance with IDD: Directive (EU) 2016/97 of the European Parliament and of the
Council of 20 January 2016 on insurance distribution (recast) (OJ L 26, 2.2.2016).
3.5
insurance company
organization that covers an insurance client against a financial loss on receipt of a premium
Note 1 to entry: Definition in accordance with Solvency II: Directive 2009/138/EC of the European Parliament
and of the Council of 25 November 2009 on the taking-up and pursuit of the business of Insurance and Reinsurance
(Solvency II) (recast) (OJ L 335, 17.12.2009).
3.6
customer data
personal and non-personal data that is collected, stored and otherwise processed by a financial
institution as part of their normal course of business with customers which covers both data provided by
a customer and data generated as a result of customer interaction with the financial institution
Note 1 to entry: Definition in accordance with proposed EU Regulation on a Framework for Financial Data Access
(FIDA).
Note 2 to entry: Customer data includes data from the customer's insurance policies.
3.7
data holder
financial institution that collects, stores and otherwise processes the data listed in FIDA Article 2(1)
Note 1 to entry: Definition in accordance with proposed EU Regulation on a Framework for Financial Data Access
(FIDA).
3.8
data user
entity listed in FIDA Article 2(2) who, following the permission of a customer, has lawful access to
customer data listed in Article 2(1)
Note 1 to entry: Definition in accordance with proposed EU Regulation on a Framework for Financial Data Access
(FIDA).
3.9
insurance policy
contract between an insurance client and one or more insurance companies to provide the insured
person or persons with one or more insurance products
3.10
insurance product
contract between an insurance client and one or more insurance companies to provide the insured
person or persons with coverage against certain specified risks in a specific insurance line of business
3.11
identifier
character string used to identify and distinguish uniquely one instance of an object in an identification
scheme from all other objects within the same scheme
4 Symbols and abbreviations
UN/CEFACT - The United Nations Centre for Trade Facilitation and Electronic Business
(UN/CEFACT) is a subsidiary of the United Nations Economic and Social Council and
serves as intergovernmental body for trade facilitation recommendations and
electronic business standards [unece.org/trade/uncefact].
UN/CCL - The data models specified in this standard are based on the UN/CEFACT Core
Components Library (UN/CCL) containing syntax-neutral and technology-
independent building blocks for data modelling [unece.org/trade/uncefact/unccl].
BPMN - BPMN stands for Business Process Model and Notation which is a standard to
visualize business processes as a kind of flowchart. Within this standard BPMN in
version 2.0 is used which itself is developed and maintained by the Object
Management Group (OMG) [ISO/IEC 19510].
Figure 1 shows all BPMN-symbols used in the process BPMN-diagram of this document.

Figure 1 — BPMN-symbols used in the use case BPMN-diagrams
5 Business process and functionality for the customer data access and portability
5.1 The business process
The business process for the customer data access and portability is defined in the Articles 4 and 5 of the
proposed EU FIDA Regulation on a Framework for Financial Data Access:
• Request of a customer to a data holder for an actual transfer of customer data (FIDA Article 4).
• Transfer of the requested customer data from the data holder to the requesting customer (FIDA
Article 4).
• Request of a data user to a data holder for an actual transfer of customer data under a
permission of the customer (FIDA Article 5).
• Transfer of the requested customer data from the data holder to the requesting data user (FIDA
Article 5).
Due to the similar functionality required by FIDA Articles 4 and 5, the customer data access for the
requesting party, a customer or a data user, is combined in this standard into one business process:
 Request of a customer or data user to a data holder for an actual transfer of customer data.
 Transfer of the requested customer data from the data holder to the requesting party, i.e. the
customer or data user.
The business process in this standard is defined for a data access to a single insurance policy. If several
policies are to be accessed, the process must be executed several times.
Based on the FIDA Regulation, the current status of the requested insurance policy shall be provided at
the time of the data access.
It is assumed that in the case of coinsurance, only the lead insurer is relevant as data holder in accordance
with the FIDA Regulation.
5.2 Preconditions of the business process for a customer data access
Before starting the process for the customer data access, some preconditions shall be fulfilled. The
processes for fulfilling these preconditions are not in the scope of this document. The preconditions are:
 The data holder shall uniquely identify the customer whose data is being accessed.
 If the customer data is accessed by a data user, the data holder shall uniquely identify the data
user.
 The data holder shall authenticate and authorise the party accessing the data, i.e. the customer
or data user, to ensure data protection and security.
 If the customer data is accessed by a data user, the data user shall be in possession of the
customer's permission for a purpose that covers the scope of the data. The permission shall have
an identification identifier. And the data user shall have shared the customer's permission with
the data holder.
 The party accessing the data shall know the unique identifier of the insurance policy, i.e. the
policy number, whose data is to be accessed.
5.3 Customer data access request
The request to access customer data from a service provided by a data holder shall consist of the
following data elements:
 An identification identifier, the policy number, shall be provided to identify the insurance policy.
 If the data access request is sent to a service that processes the requests for more than one data
holder, an identification identifier shall be provided to identify the data holder from whom the
data is requested, otherwise this data element is unnecessary.
 If the data access request is sent from a data user, the identification identifier of the customer
permission for the data access shall be provided. If the data access request is sent from a
customer, this data element is not relevant.
 If the data access request is sent from a data user, the purpose for the data access shall be
provided. If the data access request is sent from a customer, this data element is not relevant.
5.4 Customer data access validation and data preparation
When a data holder receives a customer data access request, the data holder must perform the following
validations:
 If the request contains an identification identifier of a data holder, the data holder shall validate
the correctness of the identification.
 The policy number uniquely identifies an insurance policy in the portfolio of insurance policies
of the data holder.
 If the request is sent from a customer, this customer is the insurance client or an insured person
of the requested insurance policy.
 If the request is sent from a data user, the data holder shall validate the existence and validity of
the identified permission given from the customer to this data user for the requested insurance
policy and the data holder shall validate that the provided purpose for the data access is in the
scope of this customer permission.
 The data holder shall comply with all legal requirements, in particular the GDPR and FIDA
regulations, such as the FIDA requirement to only provide data from insurance policies that are
in force.
If at least one of these validations fails, the data holder shall return an appropriate error message to the
requestor.
If all validations are successful,
 the data holder shall select the customer data of the insurance policy which is in the scope of the
requested purpose, and
 if the customer is not the insurance client, but an insured person, and the insurance policy
covers more than one insured person, then the data holder shall select only the customer data
with relevance to this insured person, and
 the data holder shall prepare the selected customer data of the insurance policy in the standard
of this document.
5.5 Customer data access response
The response from a data holder to an access request for customer data shall include all data elements
within the legal framework and within the scope of the requested purpose.
Clause 1 explains the different parts of the data model for customer data access. The general data on the
insurance policy and the insurance client is largely independent of the insurance line. In contrast, there
are different data requirements for the insurance products, coverages, and insured risks in each
individual line of business.
Application programming interfaces (APIs) in current digital technologies should be as simple as
possible. Simple means that the structure of the interface data model should be as simple as possible.
Therefore, the response for the customer data access should not be implemented by only one interface
with one large data model, but should consist of several interfaces with specific data models according
the general data and according to each insurance line.
Specific interfaces for each insurance line are more concrete for the requirements of a specific line, which
facilitates the implementation. And they are simpler for change management, as a necessary change in
one line of business does not affect the interfaces for the other insurance lines.
5.6 The semantic process for the customer data access
Figure 2 illustrates the semantic process for the customer data access as a BPMN diagram. The diagram is
based on the Business Process Model and Notation (BPMN 2.0) format. A short legend of the symbols
used is given in Clause 4.
Figure 2 — BPMN-diagram of the customer data access process
The process for the customer data access shall be implemented in the sequence of the following process
flow:
 The preconditions of the process specified in 5.2 shall be fulfilled.
 The request for the customer data access shall contain the data elements specified in 5.3.
 The data holder receives the request and shall perform the validation and preparation of the
data of the insurance policy as specified in 5.4.
 The response to the request shall contain:
 The general data for the insurance policy and the insurance client as specified in 6.3.
 A list of the line-specific insurance products contained in the insurance policy, each with a
link to the service where the corresponding product may be accessed. The details of this
product list are specified in 6.3.
 When the requestor of the customer data receives the general policy data, the requestor may
decide to access the product data or to waive access.
 If the requestor decides to access the product data, the requestor shall select one of the product
links provided with the response of the general data.
 The requestor shall use this product link for the request to access the product data from the
service of the data holder.
 The data holder receives the request and shall prepare the data of the requested insurance
product.
 The data holder shall send the product data to the requestor in the specific data model of the
insurance line of this product as specified in 6.4 to 6.12.
 When the requestor receives the product data and if not all products have been accessed yet, the
requestor may decide to access the data of the next product.
6 Data models for the customer data access
6.1 General
The data models defined in Clause 6 for the customer data access are based on the Core Components of
the UN/CEFACT Core Components Library (for reference see Clause 4).
A data model in the UN/CEFACT methodology consists of three different types of Core Components:
• ACC: Aggregate Core Component – a collection of related pieces of business information that
together convey a distinct business meaning. An ACC is also referred to as a class or entity in other
data modelling methodologies.
• BCC: Basic Core Component – a singular business characteristic of a specific Aggregate Core
Component. A BCC is of a Data Type defined in 6.2, which defines its set of values.
• ASCC: Association Core Component – a complex business characteristic of a specific Aggregate
Core Component that is associated to another Aggregate Core Component, which describes its
structure.
IMPORTANT:
The terms of the Core Components are decisive for this standard. They are essential for the
interoperability of implementations of this standard. In particular, these terms are used with
exactly the same naming in FprCEN/TS 18356-2, to implement this standard in Open API
technology. Therefore, the terms of the Core Components in the diagrams and the names of the
business terms and data types in the tables must not be changed or translated into other
languages.
The structure of the data models for the customer data access in this standard assumes that insurance
policies consist of one or more insurance products that may contain several coverages (see Figure 3). The
level of the insurance policy is independent of a specific insurance line. The insurance lines are
introduced on the product level, such as motor insurance or private property insurance.

Figure 3 — Structure of the insurance data model
Examples for the insurance data model:
• A home owner policy may consist of a building insurance, a household content insurance, a
personal liability insurance, and a bicycle insurance.
• A building insurance product may consist of coverages for fire, storm, flood, and vandalism
damages.
• A commercial policy may include a property insurance, a business interruption insurance, a
commercial liability insurance, a product liability insurance, and a machinery insurance.
• A life insurance policy may consist of one product which may include a base coverage (e.g., a
classic annuity coverage) and additional risk coverages (like occupational disability rider).
6.2 Data types
Table 1 provides the Data Types used by the Basic Core Components (BCCs) in the data models specified
in this document. The Data Types are based on version CCL24A of the UN/CEFACT Core Components
Library (for reference see Clause 4). Each data type is broken down into:
• DT: Data Type – A structured type that includes both a content and one or more optional
supplemental components.
• CC: Content Component – The mandatory core value of the data type which is a numeric or
Boolean value or an alphanumeric string.
• SC: Supplemental Component – Optional elements that qualify or contextualize the content (e.g.,
currency, code list identifier). The Supplemental Component may be omitted if a community of
data holders and data users have agreed on a specific definition of the values for a SC.
Table 1 includes the business term, a description, and an example for each Data Type.
Table 1 — UN/CEFACT Data Types CCL24A
CCT Business Term Description Example
DT Amount
CC Value A number of monetary units specified in a 50000.00
currency where the unit of currency is explicit or
implied.
SC CurrencyID The currency of the amount. ISO 4217 currency EUR
codes shall be used.
SC CurrencyCodeListVersionID The version of the ISO 4217 code list. 2015
DT Code
CC Value A character string (letters, figures, or symbols) NO
that for brevity and/or language independence
may be used to represent or replace a definitive
value or text of an attribute.
SC CodeListID The identification of a list of codes. ISO 3166-1
SC CodeListName The name of a list of codes. Country codes
SC CodeListAgencyID An agency that maintains one or more code lists. 5
UN/CEFACT 3055 responsible agency code list
shall be used.
SC CodeListAgencyName The name of the agency that maintains the code International
list. Organization for
Standardization
SC CodeListVersionID The version of the code list. 2024
SC CodeListURI The Uniform Resource Identifier that identifies https://www.iso.o
where the code list is located. rg/iso-3166-
country-
codes.html
CCT Business Term Description Example
SC CodeListSchemeURI The Uniform Resource identifier that identifies https://www.iso.o
where the code list scheme is located. rg/iso-3166-
country-
codes.html
SC CodeName The textual equivalent of the code content. Norway
SC LanguageID The identifier of the language used in the eng
corresponding text string. ISO 639-3 language
codes shall be used.
DT Date
CC Value The particular point in the progression of time. 2025-04-01
SC Format The format of the date content. ISO 8601 date YYYY-MM-DD
format shall be used.
DT DateTime
CC Value The particular point in the progression of time. 2025-03-
10T14:30:00
SC Format The format of the date/time content. ISO 8601 YYYY-MM-
date and time format shall be used. DDThh:mm:ss
DT Identifier
CC Value A character string used to identify and distinguish XYZ-1234567890
uniquely, one instance of an object in an
identification scheme from all other objects
within the same scheme.
SC IdentificationSchemeID The identification of the identification scheme. ABC-PolicyID
SC IdentificationSchemeName The name of the identification scheme. Scheme for policy
numbers of ABC
Insurance
SC IdentificationSchemeAgencyID The identification of the agency that maintains ABC
the identification scheme.
SC IdentificationSchemeAgencyName The name of the agency that maintains the ABC Insurance
identification scheme.
SC IdentificationSchemeVersionID The version of the identification scheme. 1.0
SC IdentificationSchemeDataURI The Uniform Resource Identifier that identifies https://abc-
where the identification scheme data is located. insurance.com/dat
a/policyID
SC IdentificationSchemeURI The Uniform Resource Identifier that identifies https://abc-
where the identification scheme is located. insurance.com/sc
heme/policyID
DT Indicator
CC Value The Boolean value of the indicator. true
SC Format Whether the indicator is numeric, textual, or binary
binary.
DT Measure
CC Value The numeric value determined by measuring an 120
object.
SC UnitID The type of unit of measure. MTK
UN/CEFACT Recommendation No. 20, Codes for
Units of Measure, shall be used.
SC UnitCodeListVersionID The version of the measure unit code list. 2021
CCT Business Term Description Example
DT Numeric
CC Value Numeric information that is assigned or is 5
determined by calculation, counting, or
sequencing.
SC Format The type of the Numeric Value may be specified integer
as one of: integer, decimal, real.
DT Percent
CC Value Numeric information that is assigned for a 20
percentage calculation.
SC Format The type of the Percent Value may be specified as: percentage
percentage.
DT Quantity
CC Value A counted number of non-monetary units 5
possibly including fractions.
SC UnitID The unit of the quantity. H09
SC UnitCodeListID The quantity unit code list. UN/ECE Rec 20

SC UnitCodeListAgencyID The identification of the agency that maintains 6
the quantity unit code list. UN/CEFACT 3055
responsible agency code list shall be used.
SC UnitCodeListAgencyName The name of the agency which maintains the United Nations
quantity unit code list. Economic
Commission for
Europe
DT Rate
CC Value Numeric information that is assigned for a 0.015
calculation.
SC Format The type of the Rate Value may be specified as decimal
one of: integer, decimal, real.
DT Text
CC Value A character string (i.e. a finite set of characters) Vehicle use limited
generally in the form of words of a language. to airport area.
SC LanguageID The identifier of the language used in the eng
corresponding text string. ISO 639-3 language
codes shall be used.
DT Time
CC Value The particular point in the progression of time. 14:45:00
SC Format The format of the time content. ISO 8601 time hh:mm:ss
format shall be used.
6.3 Data model for the insurance policy and party data
Figure 4 shows the data model specified in this standard for the general insurance policy data.
The following text specifies the overall structure of the insurance policy data model with the crucial ACC
Core Components. The details of all Core Components used in this data model are specified in Table 2.
The API response data model for the general policy data specified in 5.6 shall start with the ACC
InsurancePolicy and the associated ACC Contract which contain general information of an insurance
policy.
The insurance policy shall include a policy number specified in ACC Identity and may be part of a group
policy whose policy number is specified with ASCC GroupPolicy referencing ACC Identity.
The data holder shall be specified by either the ACC InsuranceCompany or the ACC InsuranceIntermediary
depending on the category of the data holder.
The insurance client shall be specified by exactly one instance (1.1) of ACC InsuranceClient.
The details of the ACCs InsuranceClient, InsuranceCompany and InsuranceIntermediary are shown in
Figure 5.
The data of a risk assessment of a private or commercial customer may be specified in the ACCs
PrivateCustomerAssessment or CommercialCustomerAssessment. The details of these ACCs are shown in
Figure 6 and Figure 7.
Categorisation of the insurance policy may be provided via the optional ASCC CategorisedUnder
referencing ACC InsuranceProduct.
The ACCs Status, Clause and Note may contain further details of the insurance policy on the level of ACC
Contract.
Several ASCCs (Binding, Effective, Initial, Lapse, RenewalTerm) referencing the ACC ContractPeriod may
provide information about specific periods within the duration of the insurance policy.
One or several occurrences of the ACC GrossPremium may be specified for gross premiums, each of which
is specified for a specific period in the associated ACC PremiumPeriod. The ACC GrossPremium may specify
the premium for the current or a future term or the premium that applied in a previous term. This may
provide an overview of the premium history.
The net premium, not including taxes, is part of the data models on the insurance product level.
In life insurance, such as insurance-based investment products and private and occupational pension
products, the ACC GrossPremium shall contain the premium payable rather than the calculated tariff
premium, as life insurance products incorporate savings and investment components that differ
fundamentally from pure risk-based premiums in other insurance lines. Tax considerations are typically
minimal in this context due to the favourable tax treatment specific to life insurance products.
Each ACC GrossPremium may reference included fees in the ACC Fee with taxes in the ACC Tax as well as a
payment plan in the ACC InsurancePaymentPlan. The payment plan may contain information about the
payment method in the ACCs FinancialCard or FinancialAccount as well as information about an
instalment plan in the ACC InstalmentPlan and a single or instalment payment in the ACC Payment.
The link between an insurance policy and one or more covered insurance products may be provided via
the ASCC Covered, which references the ACC InsuranceProductLink (0.*). Each product link contains a URI
and classification details, enabling access to the detailed product data via the API specified in 5.6 for the
access to the insurance product data.
Figure 4 — Insurance policy data model
Figure 5 shows the data model specified in this standard for the party data of the insurance client, the
insurance company and the insurance intermediary.
The ACCs InsuranceClient, InsuranceCompany, and InsuranceIntermediary may reference the ACC Party for
the information of the respective party details.
The party specified by the ACC Party may be either a natural person specified in the ACC Person or a legal
person specified in the ACC Organization.
An address of the party may be specified in the ACC Address and contact details may be specified in the
ACC Contact and the ACC Communication, such as a telephone number, email, or web address. The ACCs
AddressPreference and CommunicationPreference may specify preferences for the communication with
specific periods in ACCs Period.
Figure 5 — Party data model
The data model for the general data of an insurance policy may also include the data of a customer
assessment in accordance with Article 25 (suitability and appropriateness assessment) of EU Directive
2014/65 on Markets in Financial Instruments (MiFID II) or Article 20 (demands and needs assessment)
or Article 30 (appropriateness and suitability assessment) of EU Directive 2016/97 on Insurance
Distribution (IDD).
The data model comprises the data that the customer provided to the data holder during the assessment.
Data on existing financial products is excluded, as this data can be retrieved with the customer's
permission from the current data holders using financial data access.
The policy data model may contain the data of one or more assessments that are relevant to the specified
insurance policy and its products.
...