Directory   Messages   Segments   Composites   Data elements   Codes Meaning of the change indicators
  UN/EDIFACT  D.03A (Batch) Syntax version 3 Issue date 2003-06-23  
  Message type specification LREACT
 
 
LREACT 2 Life reinsurance activity message  
  Date:
2003-06-10

Source:
TBG8 Insurance

0. INTRODUCTION
This specification provides the definition of the Life reinsurance activity message (LREACT) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.

1. SCOPE

1.1 Functional definition
The LREACT message is used by companies to exchange insured and policy coverage detail for reinsurance purposes. The message will be used for both ceded and assumed reinsurance.

The trading partners utilizing the Life reinsurance activity message will be direct companies, reinsurance companies, reinsurance intermediaries and retrocessionaires. The message will be used to transmit data required by ceding and assuming companies to maintain the records on reinsured cessions. This data supports the reinsurer's ability to appropriately account for, manage, study, value (reserve) and complete their financial reporting. It also facilitates the reconciliation of the reinsurance records in order to maintain the integrity of the data between the trading partners.

1.2 Field of application
The Life reinsurance activity 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.

1.3 Principles
- The Life reinsurance activity message contains information about reinsured individual life insurance policies, reinsured disability insurance policies and reinsured annuity contracts administered under the terms and conditions of a treaty.

- This message provides the reinsurance information about the base policy, the insureds and the coverages of a single policy or group of policies.

- This message is only used to communicate information of policies from the time of reinsurance issue to the time of reinsurance termination.

- The partners exchange data based on trading partner agreements defining the use of the data segments contained within the Life reinsurance activity message.

- The message can be sent for purposes of confirming the details of a policy or group of policies and the associated insureds and coverages under a specific agreement.

- The message can be used to communicate information regarding the status of the policy, the changes to the policy and the valuation of a policy or group of policies.

- The message structure is generalised by specifying several conditional segments and segment groups. Only a subset of the conditional segments may be needed to meet particular requirements. Users intending to use the message for their particular requirements should study the message structure to identify the segments and segment groups required to meet their needs.

- The intent of the structural design of this message is to allow for optimal efficiency of transmission. The business function has the complex "many to many" relationship of insureds to coverages. This message allows the flexibility to structure the data in order to optimize transmission costs or optimize clarity.

- The message flows among partners; the partners may change roles in the transmission. That is to say, that the cedent may be the originator of the transmission, or may be the recipient of the transmission (from the reinsurer).

- The message is not intended to bear any relation to any particular paper report that trading partners may have used.
However, the proprietary nature of the data in the message is the same as when it is sent on a paper report or magnetic media.

- A "claim status" is included to allow for active policies with disability claims. There is no intention to communicate any other claims information using this message.

- The value contained in the GEI segment indicates whether the parent segment group contains policy, insured, coverage or relationship data. If the parent group contains policy data, then it can also contain a policy segment group. If the parent segment group contains insured data then it can also contain an insured segment group. If the parent segment group contains coverage data, then it can also contain a coverage segment group. If the parent segment group contains relationship data, then it can contain no other segment groups.

- Coverages can apply to one or more insureds. The relationship between insureds and coverages can either be defined implicitly or explicitly.

When no relationship groups are defined for a policy, the relationship is implicit:

- coverage segment group(s) immediately following an insured segment group and before the next policy or insured segment group is related to that insured;

- insured segment group(s) immediately following a coverage segment group and before the next policy or coverage segment group is related to that coverage.

For joint life cases, this method can introduce considerable redundancy in the message. To explicitly define the relationship between the insureds and the coverages, the relationship segment group is used. A policy would then be structured as a policy segment group followed by one or more insured segment groups, then one or more coverage segment groups, then one or more relationship segment groups. Each relationship segment group would contain the insured sequence number and the related coverage sequence number.

2. REFERENCES
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.

3. TERMS AND DEFINITIONS

3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.

4. MESSAGE DEFINITION

4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.

The following guidelines and principles apply to the whole message and are intended to facilitate the understanding and implementation of the message:

- All specified dates should include the century unless all parties involved in the transaction agree that there is a functional requirement for an alternative format.

- Where a choice of code or text is given only the code element should be used wherever possible.
 
  Generated by GEFEG.FX  
  http://www.gefeg.com