跳轉到內容

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://wikibook.tw/w/index.php?title=XML_-_Managing_Data_Exchange/acord&oldid=4321333"
華夏公益教科書