XML - Managing Data Exchange/acord

Introduction
ACORD is the Association for Cooperative Operations Research and Development.

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

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

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 

    JAG type      JAG type restriction 1 : Year only not admitted - Default in RLC   </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"/> <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"/> </xs:schema>

Exhibit 5: Excerpt from the RLC DTD <?xml version="1.0" encoding="UTF-8"?>

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

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

<!ELEMENT Count (#PCDATA)> <!ELEMENT StartDate (#PCDATA)> <!ATTLIST StartDate DateIndicator NMTOKEN #IMPLIED > <!ELEMENT EndDate (#PCDATA)> <!ATTLIST EndDate DateIndicator NMTOKEN #IMPLIED >

<!ELEMENT StartDateTime (#PCDATA)> <!ATTLIST StartDateTime DateIndicator NMTOKEN #IMPLIED > <!ELEMENT EndDateTime (#PCDATA)> <!ATTLIST EndDateTime DateIndicator NMTOKEN #IMPLIED >

<!ELEMENT Dec (#PCDATA)>

<!ELEMENT PeriodNbr (#PCDATA)> <!ATTLIST PeriodNbr PeriodIndicator NMTOKEN #REQUIRED >

<!ELEMENT Rate (#PCDATA)> <!ATTLIST Rate RateUnit NMTOKEN #REQUIRED >

<!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:


 * 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." 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.