EDIFACT message guide · Insurance

RECORD Reinsurance core data

The UN/EDIFACT message that conveys the core data forming the basis of negotiating and placing a reinsurance contract or endorsement.

Sent by
Cedent, broker or reinsurer
Received by
Other parties to the placement
Standard
UN/EDIFACT · Batch message
X12 equivalent
No direct equivalent

What is the EDIFACT RECORD message?

RECORD is the UN/EDIFACT reinsurance core data message. The directory describes it as conveying, in a structured format, all the core data required by partners involved in placing a reinsurance contract or endorsement, forming the basis of the negotiation and the resulting contract.

Core data includes the parties, the type of contract, the period, the territories and classes of business, the limits, retentions and premiums. Exchanging it in structure lets brokers and reinsurers load placement terms into their systems without rekeying slips.

How the EDIFACT RECORD message worksDiagram of the UN/EDIFACT RECORD Reinsurance core data message. Cedent, broker or reinsurer sends it to other parties to the placement. It usually starts the exchange. It is usually followed by RELIST. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message), DTM (Date/time/period), AGR (Agreement identification) and RFF (Reference) and body and segment groups: the required SG1 loop with PNA (Party identification). 3 conditional segment groups are listed by their trigger segment.How the EDIFACT RECORD message worksReinsurance core data: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeRECORDSENDERCedent, broker orreinsurerRECEIVEROther parties to theplacementCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYRELISTReinsured objects list2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage RECORDUNH … UNTSTART OF MESSAGEBGMBeginning of messageDTMDate/time/periodAGRAgreement identificationRFFReferenceBODY AND SEGMENT GROUPSMandatory group SG1 · repeats up to 99PNAParty identification+ 3 conditional groups, starting with:CTAIDEDOCBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for RECORD. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT RECORD message worksDiagram of the UN/EDIFACT RECORD Reinsurance core data message. Cedent, broker or reinsurer sends it to other parties to the placement. It usually starts the exchange. It is usually followed by RELIST. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message), DTM (Date/time/period), AGR (Agreement identification) and RFF (Reference) and body and segment groups: the required SG1 loop with PNA (Party identification). 3 conditional segment groups are listed by their trigger segment.How the EDIFACT RECORDmessage worksReinsurance core data: who sends it, where itfits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeRECORDSENDERCedent, brokeror reinsurerRECEIVEROther parties tothe placementCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYRELISTReinsured objects list2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message RECORD (UNH … UNT)START OF MESSAGEBGMBeginning of messageDTMDate/time/periodAGRAgreement identificationRFFReferenceBODY AND SEGMENT GROUPSMandatory group SG1 · repeats upto 99PNAParty identification+ 3 conditional groups, starting with:CTAIDEDOCBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for RECORD.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends RECORD, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around RECORD and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide, such as an industry subset or a partner’s own guide, usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Presenting a reinsurance placement to the market
  • Confirming agreed contract terms
  • Placing endorsements to existing contracts

Where it fits in the message flow

This message RECORD Reinsurance core data
Usually followed by RELIST Reinsured objects list

Structure

Mandatory segments in RECORD (directory D.21A)

In UN/EDIFACT directory D.21A, the RECORD message has 82 segment positions arranged in 17 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement, not your trading partner’s: each partner’s message implementation guide names the directory it uses, often an older one such as D.96A or D.01B where the structure can differ, makes some conditional segments mandatory and restricts the codes.

  • UNH
  • BGM
  • DTM
  • AGR
  • RFF
  • SG1 (PNA)
  • UNT

Practical example

RECORD in practice

A broker places a property catastrophe program for an insurer. It sends participating reinsurers a RECORD with the layers, limits, retentions, territories, period and premium terms. Each reinsurer loads the data into its underwriting system and responds with its share.

Implementation

Implementation considerations for RECORD

  • Keep core data consistent across all participants.
  • Version endorsements against the original placement.
  • Follow market data standards for placement messages.
  • Reconcile final terms with the signed contract.

Need help with RECORD?

ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.