XML/ACORD

Obiettivi di apprendimento

Conoscere gli standard del settore assicurativo
Capire come XML viene utilizzato nel settore assicurativo
Comprendere il motivo per cui gli standard del settore sono così importanti
Comprendere gli aspetti principali dello standard ACORD XML
Scoprire i vantaggi dell'uso di ACORD XML

ACORD^[1] è la sigla con cui è nota la Association for Cooperative Operations Research and Development. È stata fondata nel 1970 come organizzazione per la definizione degli standard per il settore assicurativo. In qualità di organizzazione no-profit attiva a livello globale, sviluppa e fornisce standard digitali allo scopo di risparmiare sui costi per l'interscambio dei dati e per ridurre le scartoffie, cercando di ridurre al minimo i lavori ripetitivi e di massimizzare l'accuratezza dei dati. Ciò rende la vita molto più facile a tutte le aziende, agli agenti e ai clienti (titolari di polizze).^[2]

Gli standard

Gli standard sono il risultato del lavoro di tutti i membri, organizzati nei gruppi di lavoro ACORD. Alla fine, sono i comitati direttivi dell'ACORD a decidere quali risultati finiscono come norme pubbliche, in coordinamento con altre organizzazioni per la standardizzazione.

Uno degli standard incorpora l'uso di XML come frame per la trasmissione flessibile dei dati. Nel 2001 è stato approvato XML for P&C and Surety Version 1.0, e nel 2002 è stata approvata la versione 1.2.

XML fornisce uno standard aperto, con una facile connettività tra sistemi ERP, sistemi di gestione, servizi web, applicazioni web e altri sistemi correlati. Può essere utilizzato in applicazioni business-to-business, customer-to-business e business-to-customer.

Vantaggi di ACORD XML

Di solito i vantaggi di XML sono comuni a tutti i settori e domini, ma diverso è il caso del settore assicurativo. Per questo si possono trovare particolari benefici:

Integrazione partner-to-partner. Elementi e definizioni di dati comuni sono necessari per trattare con partner commerciali esterni. È quindi necessario un linguaggio comune per condividere i dati con tutti gli attori della catena, ad esempio riassicuratori o intermediari. Coinvolgendo questo attori nel processo di sviluppo, ACORD ha progettato questo linguaggio comune e gli standard di dati.
Integrazione interna. Il settore assicurativo richiede la separazione dei sistemi di comunicazione per completare un processo aziendale. Inoltre, un regolatore dei sinistri che vuole verificare la copertura o assicurarsi che il codice del reclamo sia corretto, ha bisogno di un sistema che offra un trasferimento accurato del credito o del numero di polizza. Gli standard ACORD XML sono essenziali per trasferire tali elementi da sistema a sistema.
Condivisione elettronica dei dati. I dati dovrebbero avere un'elevata qualità e trasparenza. I riassicuratori hanno bisogno di un'elevata visibilità nei portafogli di rischio dei clienti per effettuare analisi approfondite dell'esposizione. Gli standard di dati ACORD supportano un formato che acquisisce e analizza informazioni e dati in più formati tra i partner.
Servizi Web. Per i servizi web che necessitano dell'integrazione in tempo reale attraverso il ciclo di elaborazione delle transazioni, gli standard ACORD realizzano processi come l'integrazione di sistemi back-end con un portale di agenti.
Document Repository Standard. Non è in generale possibile avere un unico archivio per tutte le informazioni relative al rischio. Poiché la coerenza tra i repository dei dati è molto importante, sono stati stabiliti standard ACORD XML per consentire ai partner commerciali di condividere documenti e dati strutturati e non strutturati anche in una varietà di sistemi di terze parti. Pertanto esistono i Document Repository Interface Standards per garantire l'accesso alla documentazione in formato libero.
Miglior flusso di cassa. Utilizzando l'elaborazione delle transazioni degli standard ACORD XML, questo viene accelerato. Di conseguenza vi è un accesso più rapido al denaro o ad altri tipi di pagamenti.

Standard

I seguenti standard consentono a diverse aziende di scambiare dati che di solito vengono generati utilizzando formati di dati incompatibili. Uno standard serve come metodo di comunicazione comune per aumentare l'efficienza. Si tratta di un insieme di regole e linee guida che forniscono un quadro comune per la comunicazione. L'insieme degli standard ACORD è costituito da sottoinsiemi per i tre principali segmenti del settore assicurativo:

Life, Annuity and Health (vita, rendita e salute)
Property and Casualty (proprietà e infortuni)
Reinsurance and Large Commercial (riassicurazione e commerciale di grandi dimensioni)

Implementando e seguendo le definizioni standard di ACORD, le aziende aderenti possono raggiungere

vantaggi competitivi,
supporto dei processi end-to-end,
più facile accesso ai mercati,
costi più bassi, che portano a maggiori profitti,
migliore accettazione del mercato,
prestazioni più elevate e una maggiore credibilità.

L'utilizzo di XML come mezzo di scambio di dati è una base adatta per uno standard come ACORD. È abbastanza flessibile da essere adattato all'utilizzo in diversi segmenti assicurativi, ma offre anche metodi per garantire la qualità dei dati e la stabilità dello standard.

Standardizzazione tecnica

Lo standard ACORD descrive diversi concetti che possono essere implementati. L'accesso alle descrizioni dello standard è in parte gratuito, in parte limitato ai membri ACORD.^[3]

Strutture XML

Per garantire la forma corretta dei dati trasferiti, ACORD fornisce schemi XML e DTD per i relativi membri. Le aziende che implementano lo standard possono convalidare i propri dati in base a tali definizioni. Lo standard ACORD XML è fortemente basato sullo standard EDIFACT delle Nazioni Unite ed espande i tipi di dati XML standard con i tipi di dati finanziari utilizzati dall'IFX (Interactive Financial Exchange).

I tipi di dati di ACORD sono costituiti in parte da tali definizioni, ma li espandono attraverso tipi di dati personalizzati. I tipi di dati vengono utilizzati come blocchi predefiniti per le entità più grandi all'interno della specifica.^[4]

Entità	Descrizione
`Element`	un elemento di base, basato su uno o più dei tipi di dati descritti
`Aggregate`	una raccolta di elementi, entità o aggregati corrispondenti
`Entity`	aggregato con la stessa struttura
`Message`	un aggregato che viene utilizzato come un'unica entità per la comunicazione
`Service`	una raccolta di messaggi
`Document`	una raccolta di messaggi inviati insieme contemporaneamente

Messaggi XML

Le strutture e i tipi di dati e le strutture precedenti vengono utilizzati per definire i messaggi che possono essere intercambiati tra società che implementano lo standard ACORD. All'interno del modello di dati per ogni segmento assicurativo vengono definiti tipi di messaggio diversi. L'esempio seguente mostra i messaggi utilizzati all'interno del segmento Riassicurazione e Commerciale di grandi dimensioni:

Messaggio	Descrizione
`Placing`	messaggio per l'inserimento di attività obbligatorie o facoltative
`Bordereau`	messaggio tra l'assicurazione primaria e la società di riassicurazione con informazioni sui rischi firmati
`ClaimMovement`	messaggio per una notifica di reclamo
`TechAccount`	messaggio per lo scambio di dati contabili per una trattativa
`Settlement`	messaggio per scambiare le liquidazioni
`Acknowledgement`	messaggio per confermare altri messaggi o per richiedere informazioni

Servizio messaggi ACORD

I messaggi ACORD possono essere scambiati tra società di implementazione come file XML semplici. Inoltre, lo standard ACORD definisce un servizio specializzato di scambio di messaggi. Si basa sull'escrizione L anguage (WSDL) di Web Service language (WSDL) per implementare i concetti dei servizi web. I messaggi vengono inviati utilizzando lo standard SOAP (Simple Object Access Protocol). Seguendo questo protocollo un messaggio è costituito da un elemento radice contenitore, e come elementi figli un'intestazione e un corpo. Il contenitore SOAP ha solo informazioni strutturali, non il messaggio vero e proprio. I messaggi SOAP vengono inviati come allegati con il messaggio e vi si fa riferimento all'interno del corpo del messaggio. Pertanto è possibile arricchire i messaggi ACORD con informazioni aggiuntive in formato PDF o DOC.

Esempi

Per dare un'idea della complessità delle definizioni standard ACORD XML, di seguito c'è un piccolo estratto (solo alcune righe delle oltre 5.000 che compongono lo schema XML) dello schema XML e dei file DTD del segmento Reinsurance & Large Commercial vengono presentate.

Estratto dallo schema XML RLC:

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

Estratto dalla DTD RLC:

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

Certificazione

Per garantire la qualità dei dati e la conformità dei membri agli standard proposti, ACORD offre un programma di certificazione. I membri ACORD possono inviare i propri messaggi XML ad ACORD. I messaggi vengono convalidati in due passaggi:

convalida automatica rispetto allo schema XML e ai file DTD dello standard;
convalida dei dati inviati da un essere umano per la plausibilità, caratteristica che va oltre il controllo di coerenza tecnica e automatica.

Note

↑ http://www.acord.org
↑ Per un elenco completo date un'occhiata alla Memberlist ACORD.
↑ ACORD Standard Descriptions
↑ Una descrizione dettagliata degli aspetti tecnici XML correlati allo standard ACORD può essere ottenuta per Property & Casualty e per Life, Annuity & Health

[1] ttp://www.acord.org

[2] Per un elenco completo date un'occhiata alla Memberlist ACORD.

[3] ACORD Standard Descriptions

[4] Una descrizione dettagliata degli aspetti tecnici XML correlati allo standard ACORD può essere ottenuta per Property & Casualty e per Life, Annuity & Health

[1]

[2]

[3]

[4]