SIST EN 17419-1:2021

SLOVENSKI STANDARD
SIST EN 17419-1:2021
01-januar-2021
Digitalna izmenjava informacij v zavarovalniški dejavnosti - Prenos elektronskih
dokumentov - 1. del: Procesni in podatkovni model
Digital Information Interchange in the Insurance Industry - Transfer of electronic
documents - Part 1: Process and Data Model
Digitaler Informationsaustausch in der Versicherungswirtschaft - Übertragung
elektronischer Dokumente
Échange d'informations numériques dans le secteur de l'assurance - Transfert de
documents électroniques
Ta slovenski standard je istoveten z: EN 17419-1:2020
ICS:
03.060 Finance. Bančništvo. Finances. Banking. Monetary
Monetarni sistemi. systems. Insurance
Zavarovanje
35.240.20 Uporabniške rešitve IT pri IT applications in office work
pisarniškem delu
SIST EN 17419-1:2021 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST EN 17419-1:2021

---------------------- Page: 2 ----------------------
SIST EN 17419-1:2021


EN 17419-1
EUROPEAN STANDARD

NORME EUROPÉENNE

November 2020
EUROPÄISCHE NORM
ICS 03.060; 35.240.20
English Version

Digital Information Interchange in the Insurance Industry -
Transfer of electronic documents - Part 1: Process and
Data Model
Échange d'informations numériques dans le secteur de Digitaler Informationsaustausch in der
l'assurance - Transfert de documents électroniques - Versicherungswirtschaft - Übertragung elektronischer
Partie 1 : Modèles de procédé et de données Dokumente
This European Standard was approved by CEN on 11 October 2020.

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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.

This European Standard exists 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, Turkey and
United Kingdom.





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
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17419-1:2020 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 8
5 Business processes and functionalities supported by the transfer of electronic
documents . 9
5.1 The business parties . 9
5.2 Requirements for the metadata of an insurance transaction . 9
5.3 Use case requirements supported . 11
5.4 Requirements for the transmission status message for an insurance transaction . 17
6 Data models for the transfer of electronic documents . 18
6.1 General . 18
6.2 Data model for the metadata of an insurance transaction . 18
6.3 Data model for the data of a transmission status message . 35
7 Sample use cases . 39
7.1 General . 39
7.2 Transfer from insurer to intermediary with insurance transaction issued by insurer
and addressed to intermediary . 39
7.3 Transfer from intermediary to insurer with insurance transaction issued by
intermediary and addressed to insurer . 41
7.4 Transfer from insurer to intermediary with insurance transaction issued by insurer
and addressed to client . 43
7.5 Transfer from service provider to intermediary with insurance transaction issued
by insurer and addressed to client . 45
7.6 Transfer from intermediary to insurer with insurance transaction issued by client
and addressed to insurer . 47
7.7 Transfer from insurer to intermediary with insurance transaction issued by insurer
and addressed to client, with a document that is to be signed by the client . 49
7.8 Transfer from intermediary to insurer with insurance transaction issued by client
and addressed to insurer, with a document that has been signed by the client . 51
7.9 Transfer of a transmission status message . 53
Annex A (normative) Code lists . Error! Bookmark not defined.
Bibliography . 65

2

---------------------- Page: 4 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
European foreword
This document (EN 17419-1:2020) has been prepared by Technical Committee CEN/TC 445 “Digital
information interchange in the Insurance Industry”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by May 2021, and conflicting national standards shall be
withdrawn at the latest by May 2021.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: 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, Turkey and the
United Kingdom.
3

---------------------- Page: 5 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
Introduction
Insurance is a very document-centric business. The number of documents issued is extremely high with
an average of at least one document yearly per insurance contract. Any strategy to establish a European
Single Market for insurance products requires as a mandatory prerequisite the automated transfer of
electronic documents for cross-border processes in the European insurance industry. The metadata are
supporting the automated processing and archiving of documents at the receiver of the document,
which leads to a straight through processing. Low expectation for national or market specific
requirements will facilitate the development and acceptance of a European standard. Saved costs for
document printing at the producer, saved costs for the transportation of physical documents and the
avoidance of manual processing at the receiver due to automated processing are strong arguments for a
digital transfer of documents. The reduced time for the document transfer supports faster processes for
an increased satisfaction of insurance clients.
























4

---------------------- Page: 6 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
1 Scope
This document defines the process and the structure of the transfer of electronic documents, and
facilitates the transfer of electronic documents between stakeholders in the insurance industry.
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.
EN ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1:
Country codes
ISO 639-3, Codes for the representation of names of languages — Part 3: Alpha-3 code for comprehensive
coverage of languages
ISO 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO/IEC 8859-15, Information technology — 8-bit single-byte coded graphic character sets — Part 15:
Latin alphabet No. 9
ISO/IEC 10646, Information Technology — Universal Coded Character Set (UCS)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
insurance business process
collection of insurance related, structured activities or tasks that in a specific sequence produces an
insurance related service or product for a particular insurance related party
Note 1 to entry: Examples of business processes in the insurance industry are: quotation, contract application,
documentation of contract, contract renewal, contract change, contract cancellation, premium invoice, claim
notification or claim settlement.
3.2
insurance transaction
structured collection of information within an insurance business process describing relevant terms of
this process, contents of corresponding documents
Note 1 to entry: An insurance transaction may also contain the binary representation of the related documents.
Note 2 to entry: For example, the insurance transaction of the business process “Documentation of Contract”
may result in the following documents: introductory letter, insurance policy, specific contract conditions, general
terms and conditions, invoice.
5

---------------------- Page: 7 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
3.3
document
information resulting from or supporting a business process
Note 1 to entry: Examples for documents are an insurance policy or a claims photo.
3.4
binary file
digital representation of a document
Note 1 to entry: For example, an insurance policy as a presentation in PDF-format or a claim photo as a JPG-
image file.
3.5
metadata
structured collection of information describing a business process and corresponding document
contents
Note 1 to entry: Examples for metadata are policy number, claim number, client name, insurer name.
3.6
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
3.7
insurance client
party 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: In reinsurance business, the insurance client is the ceding insurance company.
3.8
insured person
party that is covered by an insurance policy
3.9
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.10
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).
Note 2 to entry: In reinsurance business, the insurance company is the re-insurer.
6

---------------------- Page: 8 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
3.11
authentication provider
party that signs a document as a proof of identity and intent
Note 1 to entry: The signature can be handwritten or digital.
3.12
authentication signature verifier
party that proves the correctness of a (handwritten or digital) signature
Note 1 to entry: In case of a digital signature, this might be a (publicly accepted) trust centre.
3.13
insurance transaction issuer
party that initiates an insurance transaction
Note 1 to entry: In insurance business processes, the insurance transaction issuer is usually an insurance
company, an insurance intermediary or an insurance client.
3.14
insurance transaction addressee
party that is addressed by an insurance transaction
Note 1 to entry: An insurance transaction might address multiple addressees. In insurance business processes,
the insurance transaction addressee is usually an insurance company, an insurance intermediary or an insurance
client.
3.15
insurance transaction sender
party that performs the transmission of an insurance transaction
Note 1 to entry: In an implementation of this document, the sender party is technically the sending service
provider.
3.16
insurance transaction receiver
party that receives the transmitted insurance transaction
Note 1 to entry: In an implementation of this document, the receiver party is technically the receiving service
provider.
3.17
transmission status message
message from an insurance transaction receiver to an insurance transaction sender to notify on a
technical level the successful or unsuccessful transmission of a specific insurance transaction



7

---------------------- Page: 9 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
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 [www.unece.org/cefact].
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
[www.unece.org/cefact/codesfortrade/unccl/ccl_index.html].
Some code lists used in this standard are based on the United Nations Trade Data
Element Directory (UNTDED), a directory comprising a set of data elements intended
to facilitate an open interchange of data in international trade [UNTDED/ISO 7372].
UML - UML stands for Unified Modelling Language which is developed and maintained by
the Object Management Group (OMG) [ISO/IEC 19505] and which is the format of the
data model description of this standard.
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 use case BPMN-diagrams of this document.

Figure 1 — BPMN-symbols used in the use case BPMN-diagrams
8

---------------------- Page: 10 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
5 Business processes and functionalities supported by the transfer of electronic
documents
5.1 The business parties
Several business parties are involved in the transfer of electronic documents issued in the context of
insurance related processes. The following parties are the main stakeholders of the business processes
described in Clause 5.
— Insurance client;
— Insurance intermediary;
— Insurance company;
— Authentication provider;
— Authentication signature verifier;
— Insurance transaction issuer;
— Insurance transaction addressee;
— Insurance transaction sender;
— Insurance transaction receiver.
5.2 Requirements for the metadata of an insurance transaction
The electronic transfer of documents pertaining to an insurance transaction should include, besides the
binary file(s), a set of limited data describing both the insurance business process and the
corresponding document(s) in order to enable automated processing by the receiver. These so-called
“metadata” are limited only to requirements which directly support the standardized transfer process
and which are generic to a large number of document types and transaction types. Not specified are the
requirements for data of a specific insurance transaction type or a specific document type because they
are out of scope of this standard.
For specific insurance transactions even documents or binary files are not necessary, for example the
acknowledgement of a business process. In this case the insurance transaction contains metadata only.
Each requirement is given a requirement ID in the form of R+number. In Table 1 the requirements are
allocated to the data elements reflecting the requirement ID.
The following requirements for the metadata of an insurance transaction are identified:








9

---------------------- Page: 11 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
R1 The insurance transaction has one type to identify its purpose and to handle its
processing at the receiving party. The types are specified in Annex A, A.1.
R2 Additionally to the standardized type as in Annex A, A.1, a market specific transaction
type may be transferred. For this market specific transaction type code an identification
of the associated market specific code list and the agency responsible for this code list
shall be specified.
R3 The date and time when the sender has sent the insurance transaction to the receiver
shall be documented.
R4 Optionally a textual description of the insurance transaction may be given.
R5 Optionally the type of requester of the insurance transaction may be specified.
R6 Optionally the language in which the insurance transaction is documented may be
specified.
R7 If the insurance transaction requires a response an optional date and/or time may be
specified until the response should be provided.
R8 An identification identifier shall be provided to identify the insurance transaction.
R9 If the insurance transaction relates to another insurance transaction the identification
identifier of the referenced insurance transaction shall be provided.
R10 If the insurance transaction relates to a specific insurance policy, this policy is identified
by its policy number which shall be provided.
R11 If the insurance transaction relates to a specific claim, this claim is identified by its claim
number which shall be provided.
R12 If the insurance transaction relates to a specific claim, the insurance policy to which the
claim was made is identified by its policy number which shall be provided.
R13 For an insurance policy its main business class may be specified. The business class
codes are specified in Annex A, A.3.
R14 Additionally to the main business class as described in Annex A, A.3, a market specific
main business class may be transferred. For this market specific main business class
code the identification of the associated market specific code list and the agency
responsible for this code list shall be specified.
R15 Optionally for an insurance policy a market specific secondary business class may be
transferred. For this market specific secondary business class code the identification of
the associated market specific code list and the agency responsible for this code list shall
be specified.
R16 Optionally for an insurance policy the party that is the insurance client may be specified.
R17 Optionally for an insurance policy the party that is the insurance company may be
specified.
R18 Optionally for an insurance policy the party that is the insurance intermediary may be
specified.
R19 None, one or more documents may be contained in the insurance transaction.
R20 Each document has a type to identify its kind and to handle its processing at the
receiving party. The type codes are specified in Annex A, A.2.
R21 Additionally to the standardized type as in Annex A, A.2, a market specific document type
may be transferred. For this market specific document type code the identification of the
10

---------------------- Page: 12 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
associated market specific code list and the agency responsible for this code list shall be
specified.
R22 Optionally the name of the document may be given.
R23 Optionally the date and/or time when the document was issued may be given.
R24 Optionally the signature status of the document may be given. The signature status codes
are specified in Annex A, A.5.
R25 The document itself is transferred as a binary file.
R26 Additionally the binary file is described by its file name, URI, encoding type and/or
description.
R27 For each identification identifier, such as transaction identifier, policy, claim or party
number, a party that has issued this identifier may be specified.
R28 For each party a party's name may be specified.
R29 For each natural person a given name may be specified.
R30 For each party one or more party numbers may be specified to uniquely identify the
party.
R31 For each party one or more postal addresses may be specified.
R32 For each party one or more communication channels may be specified.

5.3 Use case requirements supported
5.3.1 Introduction
5.3 describes the process model for the transfer of insurance transaction information. Different use
cases specify the transaction information transfer between different business parties and define the
appropriate data required by these business parties.
The use cases describe only the transmission process to electronically transfer insurance transaction
information from one party to another party. Further internal processing by the involved parties is
described informally only to support the derivation and use of required data that should be included in
such a transfer process.
The provided diagrams for the use cases are given in the Business Process Model and Notation
(BPMN 2.0) format. A short legend of the symbols used is given in Clause 4.
The following use cases illustrate the main contexts in which the electronic transaction information
transfer is used:
• Direct transfer of insurance transaction from issuer to addressee;
• Transfer of insurance transaction from sender different from issuer;
• Transfer of insurance transaction to receiver different from addressee;
• Transfer of insurance transaction from sender different from issuer to receiver different from
addressee;
• Transfer of a document which has to be signed by an authentication provider;
• Transfer of a document which is signed by an authentication provider.
11

---------------------- Page: 13 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
Other use cases are not explicitly supported, but the specified process model might still be applicable.
5.3.2 Direct transfer of insurance transaction from issuer to addressee
In the direct transfer process, the issuer of an insurance transaction electronically transfers the
insurance transaction information directly to the addressee of the insurance transaction. Therefore the
insurance transaction issuer is also the sender party in this transfer process. Due to the direct transfer
the addressee is also the receiver party at the same time.

Figure 2 — Direct transfer of insurance transaction from issuer to addressee
In this process the involved parties have the following requirements for the data supporting this
process:
R33 The sender requires the party identification of the receiver for transfer routing purposes.
R34 The receiver requires the party details of the sender to identify the sender and to know
the contact details of the sender party in case of replies or queries.
R35 For each party the data may be specified as detailed in requirements R28 – R32.
12

---------------------- Page: 14 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
5.3.3 Transfer of insurance transaction from sender different from issuer
A party is sending an insurance transaction that was not issued by this party, the sender, but was issued
by a different party, the issuer.
EXAMPLE An insurance intermediary is sending a transaction originally issued by an insurance company to
an insurance client.

Figure 3 — Transfer of insurance transaction from sender different from issuer
In this process the involved parties have the following requirements for the data supporting this
process:
R36 The sender requires the party identification of the receiver for transfer routing
purposes (same as R33).
R37 The receiver requires the party details of the sender to identify the sender and to
know the contact details of the sender party in case of replies or queries (same as
R34).
R38 The receiver requires the party details of the issuer to identify the issuer and to know
the contact details of the issuer party in case of replies or queries.
R39 For each party the data may be specified as detailed in requirements R28 – R32.

13

---------------------- Page: 15 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
5.3.4 Transfer of insurance transaction to receiver different from addressee
Sometimes a party is sending an insurance transaction to a receiver who is not the addressee of this
insurance transaction.
EXAMPLE An insurance company is sending a transaction to an insurance intermediary, but the addressee is
an insurance client.

Figure 4 — Transfer of insurance transaction to receiver different from addressee
In this process the involved parties have the following requirements for the data supporting this
process:
R40 The sender requires the party identification of the receiver for transfer routing
purposes (same as R33).
R41 The receiver requires the party details of the sender to identify the sender and to know
the contact details of the sender party in case of replies or queries (same as R34).
R42 The receiver requires the party details of the addressee to identify the addressee and to
know the contact details of the addressee party in case of forwarding the transaction.
R43 For each party the data may be specified as detailed in requirements R28 – R32.
14

---------------------- Page: 16 ----------------------
SIST EN 17419-1:2021
EN 17419-1:2020 (E)
5.3.5 Transfer of insurance transaction from sender different from issuer to receiver different
from addressee
Sometimes a party is sending an insurance transaction that was not issued by the sender, but was
issued by a different party, the issuer, as well as the receiver is not the addressee of this insurance
transaction.
EXAMPLE An insurance intermediary is sending a transaction originally issued by an insurance company to
an insurance client, but the addressee is a dif
...