XML

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 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 Interactive Financial Exchange (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 Web Service Description Language (WSDL) to implement the concepts of web services. The messages are send using the Simple Object Access Protocol (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

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

<?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>

Exhibit 5: Excerpt from the RLC DTD

<?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)>

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:

Automatic Validation against the standard's XML schema and DTD files
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:

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