% Response.CharSet="utf-8" %>
| Version: | D |
|---|---|
| Release: | 02A |
| Contr. Agency: | UN |
| Revision: | 1 |
| Date: | 2002-05-15 |
| SOURCE: | D9 Insurance (SWG) |
|
For general information on UN standard message types see UN Trade Data Interchange Directory, UNTDID, Part 4, Section 2.3, UN/ECE UNSM General Introduction |
|
This message also occurs in the following versions of this standard: D00A, D00B, D01A, D01B, D01C, D02A, D02B, D03A, D03B, D04A, D04B |
This specification provides the definition of the Reinsurance core data message (RECORD) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
The RECORD message will convey to partners involved in the placing of a reinsurance contract or endorsement in a structured format all the required core data that form the basis of the negotiation process and of the ensuing contract (such as : contract sections and their criteria, clauses, coverages, deductibles, deductions and premiums, parties involved).
The Reinsurance core data message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.
The RECORD message has been built up from a set of flexible modules which allow the specification of the function of the message, the contract details, the subdivisions within it and for each, its main characteristics (coverages, deductibles, deductions, premiums and applicable clauses), the party(ies) involved with tier involvement, special conditions and the response to them. The message can either be used in a "minimalist" manner - in which case only few data need to be provided (e.g. when first submitting a risk or when declining a risk), or in a "maximalist" way - in which case all applicable data can be provided (normally towards the end of the placing process). In addition to these business functions, the RECORD also links or points to various types of supporting documentation requested or available to supplement the EDI document.
RECORD is one of a complimentary pair of messages that support the placing of reinsurance business. RECORD carries the core business data related to the contract, whilst RELIST carries the list of items covered under the terms of the contract.
The RECORD message performs multiple functions in the placing process, and therefore consists of a set of flexible components which can either be switched on or off - depending on the type of transaction within a specified scenario. These components include:
The functions that the RECORD currently caters for are:
pre-quotation cycle:
quotation cycle:
order cycle:
endorsement cycle:
generic:
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.
Introduction
'Placing' is basically the term used for the whole negotiation cycle to get a risk or a set of risks reinsured in the form of a reinsurance contract. As this process is identical to the endorsement cycle (whereby modifications to a contract such as extensions in time, in number or value of risks to be covered, in special conditions go through a negotiation cycle), this cycle has also been included in the placing process. Some other similar business cycles such as the cancellation, renewal have equally been covered.
The placing process is essentially not different from any buyer-supplier bidding process, although this simple fact is too often dissimulated behind complex procedures and specific terminology: the objective of the process is to find 'suppliers' that are acceptable for the buyer and that meet his requirements.
In this sense, the RECORD message could be used by any other industry in which a contract is negotiated.
Placing sub-processes
Bidding round 1: the process is initiated by the prospective buyer who composes a package that consists of his tentative requirements along with any information that may help the prospective supplier to make his bid. This additional documentation may take any form and may comprise statistics, plans, bidding terms, original policy documentation, etc. This 'package' is transmitted to selected potential suppliers for a first bidding round. This sub-process is closed off upon reception of the bids from the suppliers. It is generally referred to as the 'quotation stage'.
Bidding round 2: the buyer has at this point two options: either he has received one or more firm bids that fulfil his requirements, in which case he confirms the acceptability of the bids to the relevant supplier(s); or else he uses the received bids to re-formulate his requirements, thus initiating a second bidding round.
This second round - generally referred to as the 'order' stage
The process is closed off when the order offer is either accepted or rejected - possibly after more bidding or negotiation rounds.
The process may consist of a double loop instead of a single one in case the buyer requests another party (broker) to perform the placing process on his behalf; again, there is no essential difference: the buyer will first select in an initial bidding process the party to which he wishes to confer this duty. Afterwards, the process continues as described above with an additional feed-back loop from the broker to the buyer.
The endorsement process
The endorsement process is the one that is used to agree any type of change to the originally agreed contract; this may range from simple period extensions or cancellations to quite complex process types such as mid-term market changes. The process may be such that one type of endorsement request leads to another type of endorsement (e.g. a request for change in conditions may lead to a market change).
The endorsement process largely follows the same pattern as the placing process: the buyer (or supplier) requests the change from the other party, who in one or more discussion rounds agrees or refuses.
Main parties involved
The insurance or reinsurance company that seeks protection against a risk in the form of reinsurance or retrocession buying; hence the term 'buyer' is sometimes equally used; where the cedent is a reinsurer who retrocedes (i.e. re-sells) accepted business, the term 'retroceding company' is more commonly used - but the flows are identical, and therefore both are considered in the underlying document.
Company supplying reinsurance protection for agreed terms and conditions (the terms 'underwriter' and 'assuming company' are equally covered by this definition); if the reinsurer protects risks coming from another reinsurer, the flow is called 'retrocession'. Apart from these terms, there is little or no difference between the flow for 'cession' or 'retrocession' placing.
Intermediary between cedent and reinsurer. His function in the placing flows is essentially to ensure that a contract or endorsement with acceptable terms and conditions for the required cover is established, and that acceptable reinsurers are found to take part. Additionally, he will establish and facilitate the communication between the parties involved in the placing process. In return, he is paid a part of the premium that the cedent pays to the reinsurer, called the 'brokerage'.
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.
A service segment starting and uniquely identifying a message. The message type code for the Reinsurance core data message is RECORD.
Note: Reinsurance core data messages conforming to this document must contain the following data in segment UNH, composite S009:
| Data element | 0065 | RECORD |
| 0052 | D | |
| 0054 | 02A | |
| 0051 | UN |
To indicate the type of message, its function and its identifying reference.
To specify dates and times relating to the transaction and to the process stage. The 'transaction creation date and time' and the 'contract version date and time' are required. The use of the other values depends on the type of transaction.
A segment primarily used to specify the placing stage (i.e. quotation, order, endorsement) and - in case of an endorsement - the endorsement type. It can also be used to give some high-level indicators regarding the nature of the risk (e.g. contract type).
The segment must be used to specify the risk reference: this is the key reference that the risk will carry from the start to finish throughout each of the cycles - supplemented with the placing stage type and the contract version date/time stamp which can both change. Other references that may be specified at this level include: the 'link reference' which links this specific placement to the placement of one or more other contracts (required to indicate that a previous contract is renewed as a set of linked contracts); the 'password access reference' which may be required in some implementations to access the risk data; the 'authorising market reference' which is required in some implementations of the endorsement process (London practice only).
Used to specify at header level whether information has been modified. If both underlying policy and contract have the same data, then there is no need to specify all the insurance policy data: they are simply listed under the reinsurance contract, and a flag here indicates this fact. The segment can equally be used to indicate - specifically for an endorsement - if the data need to be made available to the bureau members (London practice only). The 'reason for declining' can be specified here in a coded format. A further code can be used to identify the character of the transaction. Lastly, codes can be used to indicate the scope of the requested common account protection.
Mainly used to specify the reason of the transaction in textual format. Additionally, it can be used to specify the contract name and to explain the nature of the revision or the endorsement. Even though the message allows for text, it should be used sparsely.
This group must be used to specify sender and receiver. Additionally and when relevant, the information originator and third parties receiving a copy of the message can equally be specified.
To specify the sender and receiver of the transaction, and optionally third parties such as the information originator (in case the message is simply passed on) and courtesy copy receivers.
To describe the business function of the party named.
To specify contract references for the party named. In case of placement or endorsement of a single contract, the contract reference will be specified. In case of a process that involves a group of contracts (in reinsurance terms: set of layers or bouquet), the contract group reference will be specified. In case of renewal, the previous contract reference(s) need to be specified. The original policy reference will only be used in case of a facultative (i.e. individual risk) placement whereby the policy details are not given as they are a subset of the contract data. The parent contract reference is specified when a declaration is placed. A reference may equally be specified in a response flow to indicate the reference number of the transaction to which this RECORD is a reply or addition.
This group is used to specify contact persons or departments within the named party.
To specify the contact within the named party.
To specify the means of communicating with the named party contact.
SG14 This group is used to perform all basic reporting either at contract level or per section, i.e. - section criteria for sections;
- coverages, deductibles, premiums and deductions; - other types of provision (settlement terms, account submission terms, deposit use terms, etc.); - parties and their involvement. Clarification: The maximum of 99 repeats has been introduced for practical reasons, and is to be understood as an overall limit on the total number of sections and subsections in any one contract. Even though in theory some data could be provided at contract level (e.g. commission, brokerage) and others at section level (e.g. coverages, deductibles), it is strongly advised to provide coverage, deductible, deduction and premium data per section - even when this represents a certain amount of duplication - in order to ease treatment by computer systems.
To identify the contract and/or section level.
To indicate what type of general conditions apply and to what the amounts in the section relate (e.g. 100 % of policy, cedent share of original risk, ceded share of risk, etc.). The segment can also be used to indicate whether the primary source of the information is paper-based or electronic.
To describe the cover for the section.
To specify the contract reference in case a contract group reference was given in the header. It can also be used to indicate the layer/surplus number of the cover if relevant. The policy reference can be specified if a section is used to describe a policy.
To specify the class(es) of business, the type(s) of occupancy, the peril(s), the subject(s) of insurance and/or the origin of business that have been used as section or contract level criteria. The segment may also be used to specify the technical nature of the (part of the) contract within this section.
If all amounts in the section or contract are expressed in the same currency, the segment can be used to specify this by means of the reference currency; in case conversion agreements are pre-arranged, further repeats can also be used to specify original currencies (calculation base currency) and their exchange rate.
To specify the criterion used for the section or contract in textual form, and/or to give further cover details. It can equally be used to render a section heading.
This group is used to specify any period relating to the section or contract - in particular various coverage periods.
To identify any periods relating to this section or contract.
This group allows to specify dates or durations of the coverage period.
To indicate dates and/or duration for the contract coverage. The first repeat of the date/time/period segment will typically be used to render the 'start date' of the period. It can however also be used to specify the period duration. The second repeat is typically to be used to render the end date of the period. In case the first segment was used to specify the duration, then the second one will be used to specify the (estimated) end date and time.
To give date or period related indicators such as 'date included', 'date not known', etc.
This group allows to specify covered locations in terms of country and address or (additionally) in terms of longitude and latitude.
To identify the geographical scope(s) or specific coverage location(s) that are used as selection criteria for this section. In case the section is in respect of a voyage, the various ports may be specified here as well.
To express a location in terms of longitude and latitude.
To express the risk location in address format if more appropriate.
To specify clauses related to the section or contract and important related information.
To identify which clause(s) are related to the contract or policy.
To specify the applicability of the clause.
To express amounts for the clause.
To express the rates applicable for the clause.
To indicate the clause reference data (e.g. the date from which cancellation starts), and/or the clause duration. The exact meaning will depend on the type of clause, e.g. retroactive date (sunrise clause), cessation date (sunset clause), etc.
To indicate that full details are to be found in the contractual documentation.
To provide a clause description.
FTX-SG9-SG10-SG11-SG12-SG13 This group is used to render all the basic data that are involved in a contract or section: coverages, deductibles, deductions and premiums. Additionally, it can be used to specify other types of proviso such as settlement terms, bordereau and account submission terms etc.
To render proviso data of any nature.
To describe how the proviso applies.
To express the proviso and/or the proviso basis as an amount.
To express the proviso as a rate.
To express the proviso as a duration or period.
To express the proviso and/or proviso basis (mainly for premium) as a quantity. Additionally, it can be used to specify the total number of reinstatements if the proviso = 'reinstatement coverage'.
To specify the formula used in calculating the proviso.
To render original currencies and pre-arranged exchange rates.
To specify the clause(s) to which the proviso relates.
To indicate that full details are to be found in supporting documentation. It can also be used in case the proviso = reinstatement coverage to express that the number of reinstatements is unlimited, and/or that the reinstatement premiums need to be calculated in the loss currency. It may also be used to specify general indicators related to the proviso such as reserve deposit release method, proviso frequency, loss adjustment expenses modality, reserve deposit use, etc.
To provide textual details relating to the proviso.
A group of segments to provide details of the basis of the proviso and how the basis is applied.
To specify one basis for the proviso.
To specify how the basis is to be applied.
The group will be used to link specific perils, classes of business, subject of insurance amongst other to a proviso.
To specify the class of business, origin of business, subject of insurance, peril or type of occupancy that the proviso is in respect of.
To specify the percentage that the accounting class represents in the total reporting.
To specify one or more locations linked to the proviso.
To specify one location linked to the proviso.
To describe a location in terms of longitude and latitude.
To describe the location to which the coverage, deductible or premium relates as an address.
The group will typically be used to specify settlement terms when settlement terms or reserve is the proviso. The group can also be used if parts of the amounts due need to be settled using various methods (e.g. 20 % of loss reserve deposit via Letter of Credit, 80 % via bank transfer).
To specify settlement terms.
To specify the percentage of the total due that needs to be settled.
This group serves multiple purposes : Each proviso must be assigned a number in order to make identification easier. The group may also be used to indicate the reinstated cover number for which details are given. The group as such can be used to specify instalment details in case that settlement terms is the proviso. Finally, the group can also be used to render commission related tables - particularly when they are using variable steps.
To specify the relevant references.
To specify the amount of the instalment.
In case instalments are reported, the segment may be used to specify the percentage of the total amount to be settled in the instalment. The other usages are for commission tables as outlined in the group usage clarification.
To specify instalment related dates.
To specify parties involved in the contract or policy, their shares and conditions.
To identify the name of any party related to the reinsurance contract or policy.
To specify further attributes of the party.
To indicate one or more addresses of the party.
To specify the name of the authorising underwriter.
To identify means of communication with the authorising underwriter.
For responding parties to specify their quote reference or (previous) contract references.
This group is used to describe the share of the party in the section. This can either be the requested, the previous or the firm involvement or 'line', and it can either be attached to conditions or not.
To describe the involvement of the party.
To be used to indicate the line identification and when relevant the line number (the sequential number this specific line will have on the contract). Additionally, this segment may carry the 'broker system id', which is an identifying unique reference of the individual who accepted the reinsurers's conditions.
To indicate the authorisation period linked to the line. It may be used when the message is used as a market status report to specify the response date/time of each party on the list.
To express the involvement as an amount or to request it to be expressed in these terms.
To express the involvement as a percentage or to indicate that the line is expected in this format. Additionally, it can be used to report specific condition percentages attached to the party's line in a 'party involvement report'.
To express the line as a quantity, or to request the line to be written in such a format.
To give additional information regarding the format of the line. Additionally, it can be used to clarify the reason why a party declined interest in the risk.
Used to specify the condition(s) attached to the line.
To specify the general type of condition and its reference.
To render the condition in a textual form and optionally the description of the response (to be) given.
To specify the accounting class.
To specify the reference for the accounting requirements.
To specify the percentage split the underwriter wants to see for the specified accounting class.
Used to reference supporting information related to the contract, policy or a section of either.
To identify supporting documents in the widest sense of the term and details directly related to them.
To provide a reference to a password which enables access to supporting information.
To identify whether the information is related to the contract or to one of more specific sections, and if so, which ones.
To specify the (possibly various) means of communication by which the information can, will or should be put at the disposal of the other parties involved.
To specify the link of a non-EDI document to an UN/EDIFACT message.
To specify the originator of the supporting information.
To identify the date and time that the supporting information was created and put at the disposal of the partners.
A service segment ending a message, giving the total number of segments in the message (including the UNH & UNT) and the control reference number of the message.
| ADR | Address | |
| AGR | Agreement identification | |
| APP | Applicability | |
| ATT | Attribute | |
| BAS | Basis | |
| BGM | Beginning of message | |
| BUS | Business function | |
| CLA | Clause identification | |
| COM | Communication contact | |
| CTA | Contact information | |
| CUX | Currencies | |
| DOC | Document/message details | |
| DTM | Date/time/period | |
| EFI | External file link identification | |
| FOR | Formula | |
| FTX | Free text | |
| GEI | Processing information | |
| ICD | Insurance cover description | |
| IDE | Identity | |
| LOC | Place/location identification | |
| MEA | Measurements | |
| MOA | Monetary amount | |
| PCD | Percentage details | |
| PER | Period related details | |
| PNA | Party identification | |
| PRV | Proviso details | |
| PYT | Payment terms | |
| QTY | Quantity | |
| RCS | Requirements and conditions | |
| RFF | Reference | |
| RTE | Rate details | |
| STS | Status | |
| UNH | Message header | |
| UNT | Message trailer |
| ├─UNH Message header | ×1 | (M) |
| ├─BGM Beginning of message | ×1 | (M) |
| ├─DTM Date/time/period | ×9 | (M) |
| ├─AGR Agreement identification | ×9 | (M) |
| ├─RFF Reference | ×9 | (M) |
| ├─GEI Processing information | ×9 | (C) |
| ├─FTX Free text | ×9 | (C) |
| ├─Segment Group 1 | ×99 | (M) |
| │─├─PNA Party identification | ×1 | (M) |
| │─├─BUS Business function | ×1 | (C) |
| │─├─RFF Reference | ×9 | (C) |
| │─└─Segment Group 2 | ×9 | (C) |
| │───├─CTA Contact information | ×1 | (M) |
| │───└─COM Communication contact | ×9 | (C) |
| ├─Segment Group 3 | ×99 | (C) |
| │─├─IDE Identity | ×1 | (M) |
| │─├─GEI Processing information | ×9 | (C) |
| │─├─ICD Insurance cover description | ×1 | (C) |
| │─├─RFF Reference | ×9 | (C) |
| │─├─ATT Attribute | ×99 | (C) |
| │─├─CUX Currencies | ×9 | (C) |
| │─├─FTX Free text | ×9 | (C) |
| │─├─Segment Group 4 | ×9 | (C) |
| │─│─├─PER Period related details | ×1 | (M) |
| │─│─└─Segment Group 5 | ×2 | (C) |
| │─│───├─DTM Date/time/period | ×1 | (M) |
| │─│───└─GEI Processing information | ×1 | (C) |
| │─├─Segment Group 6 | ×99 | (C) |
| │─│─├─LOC Place/location identification | ×1 | (M) |
| │─│─├─MEA Measurements | ×2 | (C) |
| │─│─└─ADR Address | ×1 | (C) |
| │─├─Segment Group 7 | ×99 | (C) |
| │─│─├─CLA Clause identification | ×1 | (M) |
| │─│─├─APP Applicability | ×1 | (C) |
| │─│─├─MOA Monetary amount | ×9 | (C) |
| │─│─├─PCD Percentage details | ×9 | (C) |
| │─│─├─DTM Date/time/period | ×9 | (C) |
| │─│─├─GEI Processing information | ×1 | (C) |
| │─│─└─FTX Free text | ×1 | (C) |
| │─├─Segment Group 8 | ×999 | (C) |
| │─│─├─PRV Proviso details | ×1 | (M) |
| │─│─├─APP Applicability | ×9 | (C) |
| │─│─├─MOA Monetary amount | ×9 | (C) |
| │─│─├─RTE Rate details | ×9 | (C) |
| │─│─├─DTM Date/time/period | ×9 | (C) |
| │─│─├─QTY Quantity | ×9 | (C) |
| │─│─├─FOR Formula | ×1 | (C) |
| │─│─├─CUX Currencies | ×9 | (C) |
| │─│─├─CLA Clause identification | ×99 | (C) |
| │─│─├─GEI Processing information | ×9 | (C) |
| │─│─├─FTX Free text | ×9 | (C) |
| │─│─├─Segment Group 9 | ×9 | (C) |
| │─│─│─├─BAS Basis | ×1 | (M) |
| │─│─│─└─APP Applicability | ×1 | (C) |
| │─│─├─Segment Group 10 | ×99 | (C) |
| │─│─│─├─ATT Attribute | ×1 | (M) |
| │─│─│─└─PCD Percentage details | ×1 | (C) |
| │─│─├─Segment Group 11 | ×99 | (C) |
| │─│─│─├─LOC Place/location identification | ×1 | (M) |
| │─│─│─├─MEA Measurements | ×2 | (C) |
| │─│─│─└─ADR Address | ×1 | (C) |
| │─│─├─Segment Group 12 | ×9 | (C) |
| │─│─│─├─PYT Payment terms | ×1 | (M) |
| │─│─│─└─PCD Percentage details | ×1 | (C) |
| │─│─└─Segment Group 13 | ×99 | (M) |
| │─│───├─RFF Reference | ×1 | (M) |
| │─│───├─MOA Monetary amount | ×1 | (C) |
| │─│───├─PCD Percentage details | ×9 | (C) |
| │─│───└─DTM Date/time/period | ×9 | (C) |
| │─└─Segment Group 14 | ×999 | (C) |
| │───├─PNA Party identification | ×1 | (M) |
| │───├─ATT Attribute | ×9 | (M) |
| │───├─ADR Address | ×9 | (C) |
| │───├─CTA Contact information | ×1 | (C) |
| │───├─COM Communication contact | ×9 | (C) |
| │───├─RFF Reference | ×9 | (C) |
| │───└─Segment Group 15 | ×99 | (C) |
| │─────├─STS Status | ×1 | (M) |
| │─────├─RFF Reference | ×9 | (C) |
| │─────├─DTM Date/time/period | ×9 | (C) |
| │─────├─MOA Monetary amount | ×9 | (C) |
| │─────├─PCD Percentage details | ×9 | (C) |
| │─────├─QTY Quantity | ×9 | (C) |
| │─────├─FTX Free text | ×9 | (C) |
| │─────└─Segment Group 16 | ×999 | (C) |
| │───────├─RCS Requirements and conditions | ×1 | (M) |
| │───────├─FTX Free text | ×9 | (C) |
| │───────├─ATT Attribute | ×1 | (C) |
| │───────├─RFF Reference | ×1 | (C) |
| │───────└─PCD Percentage details | ×1 | (C) |
| ├─Segment Group 17 | ×99 | (C) |
| │─├─DOC Document/message details | ×1 | (M) |
| │─├─RFF Reference | ×9 | (C) |
| │─├─IDE Identity | ×1 | (C) |
| │─├─COM Communication contact | ×1 | (C) |
| │─├─EFI External file link identification | ×1 | (C) |
| │─├─PNA Party identification | ×1 | (C) |
| │─└─DTM Date/time/period | ×9 | (C) |
| └─UNT Message trailer | ×1 | (M) |