跳转到内容

XML - 数据交换管理/acord

Add links
来自维基教科书，开放世界中的开放书籍


上一章 下一章
← Google 地球 词汇表 →


学习目标
  • 了解保险行业的标准化组织
  • 了解 XML 在保险行业中的应用
  • 认识到行业标准为何如此重要
  • 理解 ACORD XML 标准的主要方面
  • 学习使用 ACORD XML 的优势


简介

[编辑 | 编辑源代码]

ACORD 是Association for Cooperative Operations Research and Development 的缩写。

组织

[编辑 | 编辑源代码]

ACORD

[编辑 | 编辑源代码]

ACORD 成立于 1970 年，是保险行业的标准制定组织。作为一家全球性的非营利组织，他们开发并提供节省成本的数字数据交换标准，以减少文书工作。其标准的目标是最大程度地减少重复工作并最大程度地提高数据准确性；让所有公司、代理人和保单持有人更轻松 [1].

工作

[编辑 | 编辑源代码]

这些标准是所有成员共同努力的结果，由 ACORD 工作组协调。最终，ACORD 协调委员会将决定哪些结果将最终成为公共标准，并与其他标准化组织和政府协调。

最近的标准之一将 XML 纳入框架，用于灵活的数据传输和交换。2001 年，财产及意外险和保证保险 XML 版本 1.0 获得批准，2002 年，版本 1.2 获得批准 [1].

XML

[编辑 | 编辑源代码]

XML 提供了一个开放标准，在 ERP 系统、管理系统、网络服务、网络应用程序和其他相关系统之间轻松建立连接。它可用于企业对企业、客户对企业和企业对客户的应用。

ACORD XML 的优势

[编辑 | 编辑源代码]

通常，XML 的优势跨越所有行业和类似类型的领域，但这不适用于保险行业。在那里，你可以找到独特的优势，例如 [6]

合作伙伴之间的集成

[编辑 | 编辑源代码]

在该行业中，需要使用共同的数据元素和定义来处理外部业务合作伙伴。因此，您需要使用一种通用语言来与价值链中的所有参与者共享数据，例如再保险公司或中介机构。通过让这些参与者参与开发过程，ACORD 设计了这种通用语言和数据标准。

内部集成

[编辑 | 编辑源代码]

保险行业要求分离通信系统才能完成业务流程。此外，想要验证承保范围或确保理赔代码正确的理赔员，需要一个能够准确传输理赔或保单号的系统。ACORD XML 标准对于将此类项目从一个系统传输到另一个系统至关重要。

电子数据共享

[编辑 | 编辑源代码]

此外，数据应该具有高质量和透明度。没有这些，承运人无法以不同的、不兼容的格式获取风险敞口信息，从而无法有效地识别跨客户和业务线的风险敞口聚合。再保险公司需要对让步人风险组合进行深入的风险敞口分析，因此需要对其有很高的可见性。ACORD 数据标准支持一种格式，该格式可以捕获和分析跨合作伙伴的多种格式的信息和数据。

网络服务

[编辑 | 编辑源代码]

由于在整个交易处理周期中都需要网络服务进行实时集成，因此 ACORD 标准实现了诸如将后端系统与代理门户集成之类的流程。

文档库标准

[编辑 | 编辑源代码]

通常无法为所有与风险相关的信息建立单一存储库。由于数据存储库之间的一致性非常重要，因此建立了 ACORD XML 标准，以允许交易伙伴在各种第三方系统中共享结构化和非结构化文档和数据。因此，存在文档存储库接口标准，以保证对自由格式文档的访问，从而改善决策。

现金流改善

[编辑 | 编辑源代码]

通过使用 ACORD XML 标准，交易处理速度加快。因此，可以更快地获得资金或其他类型的付款。

标准

[编辑 | 编辑源代码]

遵循标准可以让价值链中不同的公司在交换数据时减少“摩擦损失”，这些损失通常是由使用不兼容的数据格式造成的。标准充当一种通用的通信方法，以提高效率 - 最低公分母。它是一套规则和指南，为通信提供一个共同的框架。 [1] ACORD 标准集包含保险行业三个主要细分的子集。它们是

  • 人寿、年金和健康
  • 财产及意外险
  • 再保险和大商业


通过实施和遵循 ACORD 的标准定义，会员公司可以实现...

  • 竞争优势
  • 端到端流程支持
  • 更容易进入市场
  • 降低成本，从而带来更多利润
  • 更好的市场接受度
  • 更高的绩效和增强的信誉。


如前几章（特别是在"XML 简介"中）所述，使用 XML 作为数据交换的方式是像 ACORD 这样的标准的合适基础。它足够灵活，可以根据不同保险领域的应用进行定制，但也提供了一些方法来确保数据质量和标准的稳定性。

技术标准化

[编辑 | 编辑源代码]

ACORD 标准描述了会员可以实施的不同概念。标准描述的访问权限部分免费，部分仅限于 ACORD 会员。可以在这里找到：ACORD 标准描述。

XML 结构

[编辑 | 编辑源代码]

为了确保传输数据的正确形式，ACORD 为其成员提供 XML 架构和 DTD。实施该标准的公司可以根据这些定义验证其数据。ACORD XML 标准基于联合国EDIFACT 标准，并使用Interactive Financial Exchange (IFX) 中使用的财务数据类型扩展了标准 XML 数据类型。

ACORD 的数据类型部分由这些定义组成，但也通过自己的数据类型进行扩展。数据类型用作规范内较大实体的构建块。


图 1：ACORD XML 标准中使用的 XML 实体

实体 描述
元素 基于一个或多个描述的数据类型的基本元素
聚合 对应元素、实体或聚合的集合
实体 具有相同结构的聚合
消息 用作通信单个实体的聚合
服务 对应消息的集合
文档 同时发送的消息的集合


有关 ACORD 标准的 XML 相关技术方面的详细描述，可以从财产及意外险和人寿、年金及健康险获得。

XML 消息

[编辑 | 编辑源代码]

前面提到的数据类型和结构用于定义可以在实施 ACORD 标准的公司之间交换的消息。数据模型中为每个保险领域定义了不同的消息类型。以下示例显示了再保险和大商业领域中使用的消息。


图 2：RLC 业务的 ACORD XML 消息类型

消息 描述
投保 用于投保强制性或自愿性业务的消息
分保单 承保公司与再保险公司之间关于已签署风险的信息的消息
索赔移动 用于索赔通知的消息
技术账户 用于交换条约会计数据的消息
结算 用于交换结算的消息
确认 用于确认其他消息或请求信息的消息

ACORD 消息服务

[编辑 | 编辑源代码]

ACORD 消息可以在实施的公司之间以纯 XML 文件的形式交换。此外，ACORD 标准定义了一种专门的消息交换服务。它基于Web Service Description Language (WSDL) 来实现 Web 服务的概念。消息使用Simple Object Access Protocol (SOAP) 标准发送。按照此协议，一条消息包含一个信封，其中包含 XML 根元素、一个标头和一个正文，它们都是信封的直接子元素。SOAP 信封只包含结构信息，而不是消息本身。实际的 SOAP 消息作为附件与消息一起发送，并在消息正文中引用。

因此，可以使用 PDF 或 DOC 格式的附加信息来丰富 ACORD 消息。


图 3：ACORD 消息服务结构

示例

[编辑 | 编辑源代码]

为了提供对 ACORD XML 标准定义复杂性的印象，以下展示了再保险和大商业领域 XML 架构和 DTD 文件的一小段摘录（每个 XML 架构文件/DTD 中 5,000 多行的几行）。


图 4：RLC XML 架构摘录 

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


图 5：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)>

认证

[编辑 | 编辑源代码]

为了确保数据质量和会员对拟议标准的遵守，ACORD 提供了专门的认证计划。ACORD 会员可以将其 XML 消息发送给 ACORD。在那里，消息会经过两个步骤验证。

  1. 根据标准的 XML 架构和 DTD 文件进行自动验证
  2. 由人工验证发送的数据的合理性，这超出了自动的技术一致性检查

会员

[编辑 | 编辑源代码]

全球最大的保险公司和保险相关企业都是 ACORD 会员：“超过 70% 的前 10 家和 60% 的前 25 家人寿及年金承保公司；超过 75% 的前 50 家财产及意外险承保公司；以及 70% 的前 10 家再保险公司，以及代表前 20 家公司 80% 的毛收入的前 5 家再保险经纪公司。”[2] 以下列表仅列出其中一些。

  • 安联保险
  • 全美保险
  • 汉诺威再保险
  • 安盛
  • 奔富
  • ING 集团
  • 大都会人寿
  • 慕尼黑再保险
  • 苏黎世保险集团

有关完整列表，请查看ACORD 会员列表。

参考文献

[编辑 | 编辑源代码]

来源

摘要

[编辑 | 编辑源代码]
在上一章中，您学习了保险行业电子数据交换的标准。它由一个名为 ACORD 的非营利组织维护，并为主要保险领域定义了数据模型。ACORD XML 标准的主要概念是
  • 一组 XML 架构和 DTD，以确保发送的 XML 流的内容、结构和“质量”
  • 一组用于不同业务用例的 XML 消息
  • 基于 WSDL 和 SOAP 的 ACORD 消息服务，用于交换丰富的 XML 数据
检索自 "https://wikibooks.cn/w/index.php?title=XML_-_Managing_Data_Exchange/acord&oldid=4321333"
华夏公益教科书