Using ACORD Standards to take technology for granted

1
Using ACORD Standardsto take technology for
granted

• June 2007

2
Introduction

• Last time we met Drew gave an extensive
  explanation of ACORD DRI.
• This time we want to show you all the ACORD XML
  messages
• demonstrating the same foundations on which they
  are built
• showing the reference material available
• The aim is to get us all to the position where we
  can take for granted the technology used to move
  messages and documents around the market.
• it should become black box for end users.
• The added value comes from using this take for
  granted technology to enable business process
  improvement
• a much wider topic with many variations.
• For now we want to ensure that the transport
  mechanisms and the payloads that can be carried
  are understood
• and not seen in any way as threatening or
  confusing to users.

3
Agenda

• ACORD Business Messages
• The payload messages
• AcordMsgSvc
• The XML transport mechanism
• Message creation step by step
• What a message looks like
• Constructing a message step by step
• Responses
• What is checked and when
• Documentation available

4
ACORD RLC Business messages - overview

• Six messages
• Each business message fully self-contained it
  describes a complete transaction - and does not
  rely on any prior message
• Responses are given via another RLC message in a
  new transaction

5
ACORD RLC Business Messages (1)

• Placing
• Submission, Quotation, Bind, Endorse, Cancel
• Both broker and carrier-driven messages
• Function indicated by code inside message
• Combination of message function and role played
  by sender determines which XML fields are
  relevant
• All fields on MR slip can be included (including
  clauses)
• Claim Movement
• All claim events, including initial advice,
  payment request, reserve update, outstanding
  losses/expenses
• Broker-driven
• Function indicated by several yes/no codes inside
  message, for example
• Reserve Change Indicator / Initial or Subsequent
  Indicator etc
• Large number of data fields regarding cause of
  loss, claimant, claim and (original) policy
  details

6
ACORD RLC Business Messages (2)

• Technical Account
• Details of all payments due/owed premium/claim
  payment, treaty statements, reinstatements, etc
• Broker-driven
• Report several sub-accounts / breakdown of items
  within sub-account and provide final balance
• Allocate each monetary amount a specific reason
  code
• Financial Account
• Settlement details for one or more agreed
  technical accounts
• Small, standard message date(s) of settlement,
  method of payment etc.
• Allows netting off and currency conversion

7
ACORD RLC Business Messages (3)

• Bordereau
• For transmission of schedules etc as structured
  data
• Rarely used usually simpler to send as
  file/attachment via DRI
• Also could use extension mechanism to provide as
  structured data within another RLC message
• Acknowledgement
• Response message to all other messages only
  sent after another RLC message is received
• Potentially sent multiple times
• Acknowledge delivery / syntax
• Levels 1 2 - not sent if AcordMsgSvc used
• Acknowledge success or failure of import to
  back-office
• Levels 3 4 - all messages
• Does not indicate agreement to contents of
  original message
• Acknowledge agreement or rejection by recipient
• Level 5 Claim Movement/ Financial Accounts
  only

8
ACORD DRI Business Messages

• DRI two messages
• Request and Response message
• Function and valid message contents indicated by
  code in message
• Upload
• Download
• Search
• Notify
• ChangeAttributes
• CreateFolder
• DownloadFolder
• Covered in Aprils Solution Provider Forum
  presentation

9
Agenda

• ACORD RLC Business Messages
• The payload messages
• AcordMsgSvc
• The XML transport mechanism
• Message creation step by step
• What a message looks like
• Constructing a message step by step
• Responses
• What is checked and when
• Documentation available

10
AcordMsgSvc overview

• Provides a secure, reliable way to exchange RLC
  and DRI business messages.
• Eight functions, four ports, sixteen messages
• All defined as pairs of request and synchronous
  (immediate) response messages

11
AcordMsgSvc messages (1)

• Inbox port (push synchronous delivery response,
  but with asynchronous business response)
• Post push message directly to recipient
• delivery receipt sent immediately (synchronous)
• business response sent later in new transaction
• StatusIn request status of previously-sent
  message
• ListIn provide recipient advance notice of a
  list of messages about to be sent, and order in
  which they will be sent
• Call port (push synchronous, combined, delivery
  and business response)
• Call push message to recipient for immediate
  response
• Response message contains both delivery receipt
  and business response

12
AcordMsgSvc messages (2)

• Outbox port (pull, synchronous, combined delivery
  and business response)
• Retrieve recipient requests download of any new
  message(s)
• StatusOut acknowledges successful download and
  processing of retrieved message
• ListOut advises recipients of messages waiting
  for retrieval, if any, and the desired order of
  transfer
• Ping port (connectivity test)
• Ping basic handshake between sender receiver
• Only Call and Post have seen wide-scale use in
  London
• Some Outbox and Ping implementations have been
  reported

13
Agenda

• ACORD RLC Business Messages
• The payload messages
• AcordMsgSvc
• The XML transport mechanism
• Message creation step by step
• What a message looks like
• Constructing a message step by step
• Responses
• What is checked and when
• Documentation available

14
Message creation step by step

• An XML message is created according to the
• Domain standard for the type of transaction
• RLC standard (Reinsurance Large Commercial)
• DRI standard (Document repository
  Interoperability)
• Documents are attached to the message (if there
  are any)
• For example, they would be sent with an DRI
  Upload message, but not with a DRI Search
  message.
• They could be sent with an RLC message as an
  attachment but DRI is normally used here
• The message including any documents is then
  wrapped up and sent using the
• AcordMsgSvc standard (AMS)
• This requires a MIME-standard message to be
  created and sent via SOAP over HTTP

15
What does a message look like?

• All messages have the same layout
• HTTP used to send the message
• MIME used to separate different parts of the
  message
• SOAP Envelope in first MIME part
• AMS message inside body
• Business message in next MIME part
• Files then added, each in their own MIME part.

16
Sending a message the transport layer

• To establish the HTTP connection
• Make sure you know and can contact the remote
  servers IP address
• Use the recipients public key to encrypt the
  session
• Use HTTP POST (not GET)
• Add HTTP/MIME Headers
• Content-Type
• multipart/related type"text/xml
• boundary ltboundary stringgt
• startltcontent ID of AcordMsgSvc MIME partgt
• (mandatory if AcordMsgSvc is not first MIME part
  in message)
• Content-Length
• Length of entire message in bytes
• SOAP Action
• see ACORD AMS SOAP Guide, 6.6.2 9.3
• User-Agent, Host, Accept Connection (etc)
• Set by your web server

17
Sending a message the AcordMsgSvc MIME part

• Add the root MIME part to the message
• MIME boundary
• Use the string listed in the MIME header
• Content-Type (again)
• For XML, this must be set to text/xml
  charsetutf-8/16/32
• Content-Transfer-Encoding
• 8bit or binary for XML
• Content-ID
• Unique identifier free text, often but not
  always a GUID
• Should match that given in the ltStartgt parameter
  (previous slide)
• Content-Length
• Length of this part of the message
• Insert a SOAP Header
• Defines how the message should be processed
• Contains security signature information
• Insert a SOAP Body
• Contains AMS message defines
• Sender, Receiver, Roles (broker, insurer, service
  provider etc)

18
Sending a message the payload MIME part

• Add another MIME part to the message
• MIME boundary Content Length as before
• Content-ID
• This must be the ID listed in the AcordMsgSvc
  manifest
• Content-Type,
• This must again be set to text/xml
  charsetutf-8/16/32
• Content-Transfer-Encoding
• Again, 8bit or binary for XML
• Add the business message
• RLC message or DRI message.

19
Sending a message in-stream attachments

• DRI and RLC messages can carry attachments
  (documents).
• A document may even be another XML file
• For example, XIS send ACORD Technical Accounts as
  XML attachments via DRI
• The ACORD design treats each message as a single
  unit regardless of the number of MIME parts
• Add another MIME part to the message
• MIME boundary Content Length as before
• Content-ID
• This must be the ID listed in the AcordMsgSvc
  manifest
• Content-Type
• For XML, this must again be set to text/xml
  charsetutf-8/16/32
• Otherwise set it to the relevant file type e.g.
  application/pdf
• Charsets only need be declared for text MIME
  parts (XML, RTF, CSV etc)
• Content-Transfer-Encoding
• 8bit or binary for XML / text
• binary or base64 for files
• Add the document suitably encoded
• Then start a new MIME part for the next file if
  there is one

20
ACORD Messaging Service AMSAn XML message from
top to bottom
21
Agenda

• ACORD RLC Business Messages
• The payload messages
• AcordMsgSvc
• The XML transport mechanism
• Message creation step by step
• What a message looks like
• Constructing a message step by step
• Responses
• What is checked and when
• Documentation available

22
Responses

• Three level of responses
• All must be given in case of success otherwise
  stop at first failure
• HTTP (synchronous immediate response)
• HTTP 400/Bad Request or 500/Server Error if
  problem
• E.g. SSL failure, or message truncated
• Otherwise HTTP 200/OK
• SOAP/AMS (synchronous immediate response)
• Send SOAP Fault if severe failure
• E.g. MIME part missing, or SOAP/AMS XML not
  well-formed
• Send AMS rejected response if other problem
  with message
• E.g. Message failed schema validation, or sender
  not known
• Otherwise sent AMS received response
• Payload - DRI or RLC (either synchronous or
  asynchronous)
• Send rejected message if problem
• E.g. requested document not found, UMR not
  recognised, message inappropriate (e.g. asked to
  provide quotation on bound contract)
• Otherwise send acknowledged message
• Full list of checks and possible reasons for
  rejection given in ACORD AMS SOAP Guide 7.6.2

23
Agenda

• ACORD RLC Business Messages
• The payload messages
• AcordMsgSvc
• The XML transport mechanism
• Message creation step by step
• What a message looks like
• Constructing a message step by step
• Responses
• What is checked and when
• Documentation available

24
Documentation (introductory)

• DRI/RLC/AMS Integration Guide (draft)
• Guide to using DRI with RLC and AMS in London
  Market
• Connectivity Best Practice v1.0
• Guide to project managing ACORD implementations
• List of common mistakes

25
Documentation (detailed)

• AcordMsgSvc / Transport Layer
• AMS SOAP Guide v1.4 (latest version 1.5)
• Guide to using MIME, SOAP, HTTP and AcordMsgSvc
• RLC Messages
• Placing Implementation Guide Placing Reference
  Guide v2.0
• Placing message flows, definitions, core data and
  XML construction
• Accounting Claims Implementation Guide v2005.2
  (latest version 2007.1)
• Claim Movement, Technical Account and Financial
  Account flows and XML construction.
• DRI Messages
• DRI Reference Guide v1.2 (latest version 1.3)
• Guide to using DRI

26
World Headquarters Two Blue Hill Plaza 3rd
Floor Pearl River, NY 10965 USA
1 845 620 1700

SLIDE 26