# XML - Managing Data Exchange/acord

+--------------------------------------------------------------------+
| **Learning objectives**                                            |
|                                                                    |
| -   get to know insurance industry\'s standardization organization |
| -   understand how XML is used in the insurance industry           |
| -   realize why industry standards are so important                |
| -   comprehend the main aspects of the ACORD XML standard          |
| -   learn about the advantages of using ACORD XML                  |
+--------------------------------------------------------------------+
|                                                                    |
+--------------------------------------------------------------------+

## Introduction

ACORD is the **A**ssociation for **C**ooperative
**O**perations **R**esearch and **D**evelopment.

### Organization

## ACORD

ACORD was founded in 1970 as a standards-setting organization for the
insurance industry. As a global non-profit organization, they develop
and provide cost saving digital standards for data interchange to reduce
paperwork. The goals of their standards are to minimize redundant work
and maximize data accuracy; making life far easier for all companies,
agents and policyholders \[1\].

### Work

The standards are the result of the work of all members, synchronized by
ACORD working groups. Finally the ACORD Steering Committees will decide,
which results would end up as public standards, in coordination with
other standardization organizations and governments.

One of the recent standards incorporates the use of XML as a frame for
flexible data transmission and interchange. In 2001 XML for P&C and
Surety Version 1.0 was approved, in 2002 Version 1.2 was approved
\[1\].

### XML

XML provides an open standard, with easy to be
made connectivity between
ERP
systems, managment systems, web services, web applications and other
related systems. It can be used in business-to-business,
customer-to-business and business-to-customer applications.

## Benefits of ACORD XML

Usually the benefits of XML are across all industries and domains of
similar type, but that does not apply to the insurance industry. There
you can find unique benefits like \[6\]:

### Partner to Partner Integration

Common data elements and definitions are necessary to deal with external
business partners in this industry. So you need a common language to
share data with all actors from the value chain, e.g. reinsurers or
intermediaries. By involving this actors in the process of development
ACORD designed this common language and data standards.

### Internal Integration

The Insurance industry requires the separation of communication systems
to complete a business process. Furthermore a claim adjuster, who wants
to verify coverage or to ensure that the claim\'s code is correct, needs
a system that offers accurate transfer of the claim or policy number.
ACORD XML standards are essential to transfer such items from system to
system.

### Electronic Data Sharing

Moreover the data should have a high quality and transparency. Without
that it is not possible for carriers to get exposure information in
disparate and incompatible formats in order to identify aggregation of
exposure across customers and lines of business in an effective way.
Reinsurers need high visibility into cedent risk portfolios for
extensive exposure analyses. ACORD data standards support a format that
captures and analyzes information and data in multiple formats across
partners.

### Web Services

By reason of Web Services are required for real time integration
througout the transaction processing cycle, ACORD standards realise
processes like the integration of back-end systems with an agent portal.

### Document Repository Standards

A single repository for all risk related information is in general not
possible. Due to the fact that consistency across data repositories is
very important, ACORD XML standards were established to allow trading
partners to share structured and unstructured documents and data also in
a variety of third party systems. Therefore Document Repository
Interface Standards exist to guarantee access to free format
documentation for improving decisions.

### Improved Cash Flow

By using ACORD XML standards transaction processing is accelerated.
Consequently there is a faster access to money or other types of
payments.

## Standards

Following standards allows different companies along the value chain of
a market to exchange data with less \"frictional losses\" that are
usually generated by the usage of incompatible data formats. A standard
serves as a common communication method to increase efficiency - a
lowest common denominator. It is a set of rules and guidelines that
provide a common framework for
communication.1 The set of ACORD
standards consists of subsets for the 3 main segments of insurance
industry. These are:

-   Life, Annuity and Health
-   Property and Casualty
-   Reinsurance and Large Commercial

By implementing and following ACORD\'s standard definitions, member
companies can achieve \...

-   competitive advantages
-   end-to-end process support
-   easier access to markets
-   lower costs, which lead to more profit
-   better market acceptance
-   higher performance and enhanced credibility.

As seen in the previous chapters (esp. in \"Introduction to
XML\")
using XML as a means of data exchange is a suitable base for a standard
like ACORD. It\'s flexible enough to be tailored for the usage within
different insurance segments but it also offers methods to ensure data
quality and the stability of the standard.

## Technical Standardization

The ACORD standard describes different concepts that can be implemented
by a member. The access to the standard\'s descriptions is partly free,
partly limited to ACORD members. It can be found here: ACORD Standard
Descriptions.

### XML structures

To ensure the correct form of the transferred data, ACORD provides XML
schemas and DTDs for its members. Companies implementing the standard
can validate their data against those definitions. The ACORD XML
standard is strongly based upon the United Nations
EDIFACT standard and expands the standard XML
data types with the financial data types used by the **I**nteractive
**F**inancial
**E**xchange (IFX).

ACORD\'s data types consist partly of those definitions but also expand
them with own data types. The data types are used as building blocks for
larger entities within the specification:

**Exhibit 1: XML entities used within the ACORD XML standard**

  Entity      Description
  ----------- ------------------------------------------------------------------
  Element     a base element, based on one or more of the described data types
  Aggregate   a collection of corresponding elements, entities or aggregates
  Entity      aggregate with the same structure
  Message     an aggregate that is used as one entity for communication
  Service     a collection of corresponding messages
  Document    a collection of messages that are sent together at the same time

A detailed description of the technical XML related aspects of the ACORD
standard can be obtained for Property &
Casualty and for
Life, Annuity & Health.

### XML messages

The before mentioned data types and structures are used to define
messages that can be interchanged between companies implementing the
ACORD standard. Different message types are defined within the data
model for each insurance segment. The following example shows the
messages used within the Reinsurance & Large Commercial segment:

**Exhibit 2: ACORD XML message types for RLC business**

  Message           Description
  ----------------- -----------------------------------------------------------------------------------------------
  Placing           message for placing obligatory or facultative business
  Bordereau         message between primary insurance and reinsurance company with information about signed risks
  ClaimMovement     message for a claim notification
  TechAccount       message to exchange accounting data for a treaty
  Settlement        message to exchange settlements
  Acknowledgement   message to confirm other messages or to request information

### ACORD message service

ACORD messages can be exchanged between implementing companies as plain
XML files. Additionally the ACORD standard defines a specialized message
exchange service. It is based on the **W**eb **S**ervice
**D**escription
**L**anguage (WSDL)
to implement the concepts of web services. The messages are send using
the **S**imple **O**bject **A**ccess
**P**rotocol (SOAP) standard. Following this
protocol a message consists of an envelope with the XML root element, a
header and a body which both are direct child elements of the envelope.
The SOAP envelope only contains structural information, not the message
itself. The actual SOAP messages are send as attachments with the
message and are referenced within the message body.

Therefore it\'s possible to enrich the ACORD messages with additional
information in PDF or DOC format.

**Exhibit 3: ACORD message service structure**

![](ACORD_Messages.jpg "ACORD_Messages.jpg")

### Examples

To provide an impression of the complexity of ACORD\'s XML standard
definitions, following a small excerpt (only some lines of more than
5.000 per XML schema file / DTD) of the Reinsurance & Large Commercial
segment\'s XML schema and DTD files are presented:

**Exhibit 4: Excerpt from the RLC XML schema**

    <nowiki>
    <?xml version="1.0" encoding="UTF-8"?>
    <!--

    This is the ACORD Reinsurance and Large Commercial Business Message specification's 

    **** version 2007-1 Schema **** 

    Generated: May 10, 2007                                                        

    COPYRIGHT NOTICE:
    (c) 2001-2007 ACORD.  All Rights Reserved.

    IMPORTANT NOTE:  Please be advised that this document and your use of it is governed, and 
    you are bound, by the Terms and Conditions of Use accessible at [http://legal.acord.org/terms.pdf].

    -->
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2007-1" 
    xmlns:ac="http://www.ACORD.org/Standards/AcordMsgSvc/1" targetNamespace="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2007-1" 
    elementFormDefault="qualified" attributeFormDefault="unqualified" version="2007-1">
            <xs:import namespace="http://www.ACORD.org/Standards/AcordMsgSvc/1" schemaLocation="Acord-Repository_v-1-3-0-RLC-Slice.xsd"/>
        <!--******************-->
        <!--2007-1 MRs applied-->
        <!--******************-->
        <!--MR1: Add CedentBuildReference, BrokerBuildReference, ReinsurerBuildReference, InsurerBuildReference, 
             ServiceProviderBuildReference and PlacingExchangeBuildReference elements to Contract -->
        <!--MR10: Change DeductibleNumberOfLines, CoverageNumberOfLines, ReinsurerShareNumberOfLines, InsurerShareNumberOfLines, 
             ReinsurerWrittenNumberOfLines, InsurerWrittenNumberOfLines to become decimal numbers instead of integers-->
        <!--MR11: Add ExpenseIndicator element to IndividualClaimAmtItem-->
        <!--MR20: Add ProcessingInstructions/SettlementChannel to ContractMarket-->
        <!---->
        <!--******************************************************-->
        <!--Start of Jv-Ins-Reinsurance base data types -->
        <!--******************************************************-->
        <!--Character is equated to the xs:string Schema base type-->
        <!--URL is equated to the xs:anyURI Schema base type-->
        <!--Attributes are validated against the xs:NMTOKEN Schema base type-->
        <xs:simpleType name="FlexibleDate_Type">
            <xs:annotation>
                <xs:documentation>JAG type</xs:documentation>
            </xs:annotation>
            <xs:union memberTypes="xs:date xs:gYearMonth xs:gYear"/>
        </xs:simpleType>
        <xs:simpleType name="FlexibleDate1_Type">
            <xs:annotation>
                <xs:documentation>JAG type restriction 1 : Year only not admitted - Default in RLC</xs:documentation>
            </xs:annotation>
            <xs:union memberTypes="xs:date xs:gYearMonth"/>
        </xs:simpleType>
        <xs:simpleType name="FlexibleDateTime_Type">
            <xs:annotation>
                <xs:documentation>JAG type</xs:documentation>
            </xs:annotation>
            <xs:union memberTypes="xs:date xs:dateTime xs:gYearMonth xs:gYear"/>
        </xs:simpleType>
        <xs:simpleType name="FlexibleDateTime1_Type">
            <xs:annotation>
                <xs:documentation>JAG type restriction 1 : Year only not admitted</xs:documentation>
            </xs:annotation>
            <xs:union memberTypes="xs:date xs:dateTime xs:gYearMonth"/>
        </xs:simpleType>
        <xs:simpleType name="FlexibleDateTime2_Type">
            <xs:annotation>
                <xs:documentation>JAG type restriction 2 : Year only and YearMonth only not admitted</xs:documentation>
            </xs:annotation>
            <xs:union memberTypes="xs:date xs:dateTime"/>
        </xs:simpleType>
        <xs:complexType name="StartDateType">
            <xs:simpleContent>
                <xs:extension base="FlexibleDate1_Type">
                    <xs:attribute name="DateIndicator" type="xs:NMTOKEN"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
        <xs:complexType name="EndDateType">
            <xs:simpleContent>
                <xs:extension base="FlexibleDate1_Type">
                    <xs:attribute name="DateIndicator" type="xs:NMTOKEN"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
        <xs:complexType name="StartDateTimeType">
            <xs:simpleContent>
                <xs:extension base="FlexibleDateTime2_Type">
                    <xs:attribute name="DateIndicator" type="xs:NMTOKEN"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
        <xs:complexType name="EndDateTimeType">
            <xs:simpleContent>
                <xs:extension base="FlexibleDateTime2_Type">
                    <xs:attribute name="DateIndicator" type="xs:NMTOKEN"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>

    .
    .
    .

        <xs:element name="WrittenDateTime" type="FlexibleDateTime2_Type"/>
        <xs:element name="XplClauseIndicator" type="XplClauseIndicatorType"/>
        <!--**************************************************************-->
        <!--End of Jv-Ins-Reinsurance elements-->
        <!--**************************************************************-->
        <!--The Message aggregates included in this schema are generic and contain the child elements allowed in each message.  
             Where a child element is itself an aggregate, this does NOT mean that ALL elements of that child aggregate are 
             available for use in a particular message.

             The ACORD RLC Data dictionary and Implementation guides give details of the restrictions placed on the use of all 
             elements and further information can also be found in the individual templates for each message. These templates are 
             XML files listing all tags available for each message and can be viewed with any XML editor or viewer. 
     
             The respective message aggregates are as shown in the section "Jv-Ins-Reinsurance root and transaction elements" 
             table below.  The templates themselves can be downloaded from the ACORD web site www.ACORD.org along with the standard 
             documentation.-->
        <!-- 
    *****************************************************************
    *  Jv-Ins-Reinsurance root and Message elements   *
    *****************************************************************
    -->
        <xs:element name="Jv-Ins-Reinsurance" type="Jv-Ins-ReinsuranceType"/>
        <xs:element name="Acknowledgement" type="AcknowledgementType"/>
        <xs:element name="Bordereau" type="BordereauType"/>
        <xs:element name="ClaimMovement" type="ClaimMovementType"/>
        <xs:element name="Codes" type="CodesType"/>
        <xs:element name="Placing" type="PlacingType"/>
        <xs:element name="Settlement" type="SettlementType"/>
        <xs:element name="TechAccount" type="TechAccountType"/>
        <!--End of Jv-Ins-Reinsurance root and transaction elements-->
    </xs:schema>
    </nowiki>

**Exhibit 5: Excerpt from the RLC DTD**

    <nowiki>
    <?xml version="1.0" encoding="UTF-8"?>
    <!-- edited with XMLSpy v2006 rel. 3 sp2 (http://www.altova.com) by Serge Cayron (ACORD Corp.) -->
    <!--
    This is the ACORD Reinsurance and Large Commercial Business Message specification's 

    **** version 2007-1 DTD **** 

    Generated: May 10, 2007                                                        

    COPYRIGHT NOTICE:
    (c) 2001-2007 ACORD.  All Rights Reserved.

    IMPORTANT NOTE:  Please be advised that this document and your use of it is governed, and you are bound, by the Terms 
    and Conditions of Use accessible at [http://legal.acord.org/terms.pdf].
       
    *******************************************************************************************
    *                                Formal Public Identifier                                               
    *                                                                                                                
    *      "-//ACORD//DTD JV Ins-Reinsurance Version 2007-1//EN"                       
    ********************************************************************************************

    IMPORTANT NOTE: From the 2005-2 release, the RLC XML Schema is able to validate messages that include custom extensions, 
    using a standard method. The DTD file does NOT support the same functionality.  The user of a DTD should be aware that 
    it will not be possible to use the DTD to validate messages that use the standard extension method. -->
    <!--******************-->
    <!--2007-1 MRs applied-->
    <!--******************-->
    <!--MR1: Add CedentBuildReference, BrokerBuildReference, ReinsurerBuildReference, InsurerBuildReference, 
     ServiceProviderBuildReference and PlacingExchangeBuildReference elements to Contract -->
    <!--MR10: Change DeductibleNumberOfLines, CoverageNumberOfLines, ReinsurerShareNumberOfLines, InsurerShareNumberOfLines, 
     ReinsurerWrittenNumberOfLines, InsurerWrittenNumberOfLines to become decimal numbers instead of integers-->
    <!--MR11: Add ExpenseIndicator element to IndividualClaimAmtItem-->
    <!--MR20: Add ProcessingInstructions/SettlementChannel to ContractMarket-->
    <!--
    ************************************************
    *  Common Entities in alphabetical order *
    ************************************************
     -->
    <!ENTITY % PARTY "Party, Contact?, Address?">
    <!ENTITY % PARTYXT "((Party, FullNameAndAddress?) | FullNameAndAddress), Contact?, Address?, OperationsDescription?">
    <!ENTITY % PERILS "Peril+">
    <!ENTITY % PERIOD "StartDate?, EndDate?, TimeDuration?">
    <!ENTITY % REPORTING "Description?, ReportDue?, ProvisionFrequency?, AnnualAsOfDate?">
    <!-- 
    *****************************
    *  Data typing elements  *
    *****************************
     -->
    <!-- Currency amount -->
    <!ELEMENT Amt (#PCDATA)>
    <!ATTLIST Amt
        Ccy NMTOKEN #REQUIRED
        Share (cedent_share | contract_ceded | hundred_percent | receiver_share | reinsurer_share) #IMPLIED
        CcyIndic (reference_currency | target_currency | original_currency) #IMPLIED
    >
    <!-- Integer -->
    <!ELEMENT Count (#PCDATA)>
    <!ELEMENT StartDate (#PCDATA)>
    <!ATTLIST StartDate
        DateIndicator NMTOKEN #IMPLIED
    >
    <!ELEMENT EndDate (#PCDATA)>
    <!ATTLIST EndDate
        DateIndicator NMTOKEN #IMPLIED
    >
    <!-- Date and time -->
    <!ELEMENT StartDateTime (#PCDATA)>
    <!ATTLIST StartDateTime
        DateIndicator NMTOKEN #IMPLIED
    >
    <!ELEMENT EndDateTime (#PCDATA)>
    <!ATTLIST EndDateTime
        DateIndicator NMTOKEN #IMPLIED
    >
    <!-- Decimal -->
    <!ELEMENT Dec (#PCDATA)>
    <!-- Period identification - Integer-->
    <!ELEMENT PeriodNbr (#PCDATA)>
    <!ATTLIST PeriodNbr
        PeriodIndicator NMTOKEN #REQUIRED
    >
    <!-- Rate -->
    <!ELEMENT Rate (#PCDATA)>
    <!ATTLIST Rate
        RateUnit NMTOKEN #REQUIRED
    >
    <!-- Time duration -->
    <!ATTLIST TimeDuration
        PeriodType NMTOKEN #IMPLIED
        PeriodIndicator NMTOKEN #IMPLIED
    >

    .
    .
    .

    <!ATTLIST TimeDuration
        PeriodType NMTOKEN #IMPLIED
        PeriodIndicator NMTOKEN #IMPLIED
    >
    <!ELEMENT TimeRelation (#PCDATA)>
    <!ELEMENT TimeZone (#PCDATA)>
    <!ELEMENT TotalLossIndicator (#PCDATA)>
    <!ELEMENT Townclass (#PCDATA)>
    <!ATTLIST Townclass
        Agency NMTOKEN #IMPLIED
    >
    <!ELEMENT TransactionReasonDescription (#PCDATA)>
    <!ELEMENT TransactionResponseReason (#PCDATA)>
    <!ELEMENT TreatyFac (#PCDATA)>
    <!ELEMENT URL (#PCDATA)>
    <!ELEMENT UUId (#PCDATA)>
    <!ELEMENT UnderwritingManager (%PARTY;)>
    <!ELEMENT UnderwritingManagerRiskReference (#PCDATA)>
    <!ELEMENT UnderwritingYear (#PCDATA)>
    <!ELEMENT UnearnedPremiumCalculationPeriod (%PERIOD;)>
    <!ELEMENT UnearnedPremiumReserveProfitCommissionPercentage (Rate)>
    <!ELEMENT USARiskClassification ((RiskClass, RiskClassDescription?) | RiskClassDescription)>
    <!ELEMENT UserId (#PCDATA)>
    <!ELEMENT ValueAddedTaxRating (#PCDATA)>
    <!ELEMENT ValueDate (#PCDATA)>
    <!ELEMENT VesselName (#PCDATA)>
    <!ELEMENT VesselOrConveyanceDescription (#PCDATA)>
    <!ELEMENT Voyage (DepartureDateTime?, LoadingOrEmbarkationDate?, DepartureLocation?, DestinationLocation?)>
    <!ELEMENT WebApplication (URL?, UserId?)>
    <!ELEMENT WebSiteURL (#PCDATA)>
    <!ELEMENT WholesaleBrokerageAmount (Amt+)>
    <!ELEMENT WholesaleBrokeragePercentage (Rate)>
    <!ELEMENT WithdrawalDate (#PCDATA)>
    <!ELEMENT WithdrawalPercentage (Rate)>
    <!ELEMENT WorkersCompensationState (Subentity)>
    <!ELEMENT WorkersCompensationStateDescription (#PCDATA)>
    <!ELEMENT WrittenDateTime (#PCDATA)>
    <!ELEMENT XplClauseIndicator (#PCDATA)>
    </nowiki>

### Certification

To ensure data quality and member\'s compliance with the proposed
standards ACORD offers a special certification program. ACORD members
can send their XML messages to ACORD. There the messages are validated
in 2 steps:

1.  Automatic Validation against the standard\'s XML schema and DTD
    files
2.  Validation of the sent data by a human for plausibility which goes
    beyond the automatical, technical consistency check

## Members

World\'s largest insurance companies and insurance related businesses
are ACORD members: \"Over 70% of the top 10 and 60% of the top 25 Life &
Annuity carriers; Over 75% of the top 50 Property & Casualty carriers;
and 70% of the top 10 Reinsurers, as well as the Top 5 reinsurance
brokers representing 80% of the top 20\'s gross
revenue.\"2 The following list
shows just some of them:

-   Allianz Insurance
-   Allstate
-   Hannover Re
-   AXA
-   Benfield
-   ING Group
-   MetLife
-   Munich Re
-   Zurich Insurance Group

For a complete list have a look at the ACORD
Memberlist.

## References

Sources:

-   \[1\] ACORD Website
-   \[2\] Market Reform Group
-   \[3\] IFX Forum
-   \[4\] University of
    Leipzig
-   \[5\] SAP
    INFO
-   \[6\] ACORD White
    Paper

## Summary

+----------------------------------------------------------------------+
| In the previous chapter you have learned about the insurance         |
| industry\'s standard for electronical data exchange. It\'s           |
| maintained by a nonprofit organization called ACORD and defines data |
| models for the main insurance segments. The main concepts of the     |
| ACORD XML standard are:                                              |
|                                                                      |
| -   a set of XML schemas and DTDs to ensure the content, structure   |
|     and \"quality\" of the sent XML streams                          |
| -   a set of XML messages for different business cases               |
| -   the ACORD message service for exchanging enriched XML data based |
|     on WSDL and SOAP                                                 |
+----------------------------------------------------------------------+
|                                                                      |
+----------------------------------------------------------------------+

