ACORD DOCUMENT REPOSITORY INTERFACE
(DRI)
CUSTOMER USER GUIDE
Version 8.2
Revision
date
02/01/06
30/03/06
15/03/06
31/03/06
14/04/06
28/04/06
19/05/06
20/06/06
04/08/06
11/12/06
15/12/06
09/03/07
Summary of Changes
Version 1.0 – Initial implementation
Version 2.0 – Broadened to cover broker EPA & Policy Submission.
Version 3.0 – Broadened to cover carrier DRI
Version 4.0 – Revisions
Version 5.0 – Further revisions
Version 6.0 – Further revisions
Version 6.1 – Incorporating broker premium processing procedures
Version 7.0 – Incorporating market feedback
Version 7.1 – Incorporating MRPO feedback
Version 8.0 – Revisions at December Release of A & S
Version 8.1 – Version 8.0 incorporating feedback
Version 8.2 – Amendments
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 1 of 60
Changes
marked
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Date: 09/03/07
Contents
1.
2.
3.
4.
Purpose of the document ..................................................................................................................... 4
Scope ................................................................................................................................................... 4
Background .......................................................................................................................................... 5
Roll-Out Process .................................................................................................................................. 6
4.1.
Registration .................................................................................................................................... 6
4.2.
Integration Testing ......................................................................................................................... 6
4.3.
Production Roll-out ........................................................................................................................ 6
5.
Registration Procedures ....................................................................................................................... 7
5.1.
New DRI Registration: ................................................................................................................... 7
5.2.
Amending existing registration details: .......................................................................................... 8
5.3.
DL 5079 Report of unmatched items ............................................................................................. 8
6.
Technical Requirements .................................................................................................................... 10
6.1.
ACORD Compliance .................................................................................................................... 10
6.2.
Ports ............................................................................................................................................. 11
6.3.
Digital Certificates ........................................................................................................................ 11
6.4.
Technical / Development Requirements ...................................................................................... 11
6.5.
Technical Standards .................................................................................................................... 12
7.
Integration testing ............................................................................................................................... 14
7.1.
Objectives / Scope ....................................................................................................................... 14
7.2.
Entry Criteria ................................................................................................................................ 14
7.3.
Exit Criteria .................................................................................................................................. 15
7.4.
Responsibilities ............................................................................................................................ 15
7.5.
Support & Problem Management ................................................................................................ 15
8.
Production roll-out .............................................................................................................................. 17
9.
Sign-off procedures ............................................................................................................................ 18
10.
ACORD DRI Functions....................................................................................................................... 19
10.1.
Introduction .................................................................................................................................. 19
10.1.1.
Functions Supported ........................................................................................................... 19
10.1.2.
Submissions for Electronic Premium Accounting ............................................................... 19
11.
Accounting and settlement PROCESSING PROCEDURES ............................................................. 22
11.1.
Scope ........................................................................................................................................... 22
11.2.
Exclusions .................................................................................................................................... 22
11.3.
Business Process Rules .............................................................................................................. 22
11.4.
Letter of Indemnity (LOI) .............................................................................................................. 23
11.5.
Further Information and Contact Details ...................................................................................... 24
11.6.
Document Creation ...................................................................................................................... 24
11.7.
Document Naming ....................................................................................................................... 24
11.8.
Legacy Processing ...................................................................................................................... 25
11.9.
Policy Type Processing ............................................................................................................... 25
11.10.
Correction Processing ............................................................................................................. 26
11.11.
Nil / Non Premium Endorsements (NPEs) Processing ........................................................... 26
11.12.
Submissions in Error ............................................................................................................... 26
11.13.
Broker Mid Term Changes ...................................................................................................... 27
11.14.
Completion of Items ................................................................................................................ 27
11.14.1.
Signing Number and Date Extract and Load ...................................................................... 27
11.14.2.
Package View User Interface .............................................................................................. 27
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 2 of 60
Date: 09/03/07
11.14.3.
EPA Signings Advice to Brokers ......................................................................................... 28
11.14.4.
Updated Package Status .................................................................................................... 29
11.15.
Advice of de-linked items ........................................................................................................ 30
11.15.1.
De-linked Signings Advice - EDI message ......................................................................... 30
11.16.
Query and Rejection Processing ............................................................................................. 31
11.17.
The Tracker Process ............................................................................................................... 31
11.17.1.
The email address............................................................................................................... 31
11.17.2.
The email subject ................................................................................................................ 32
11.17.3.
The email content................................................................................................................ 32
11.17.4.
Accessing the query sheet .................................................................................................. 33
11.18.
Process for Urgent Resubmissions of queried items .............................................................. 33
12.
Appendix A – DRI Registration Form ................................................................................................. 35
13.
Appendix B – Business Rules (Business Decision Logic) for Electronic Claims File-ECF DRI
Messages ...................................................................................................................................................... 40
14.
Appendix C – DOCUMENTS BY TRANSACTION TYPES ................................................................ 41
Policy ............................................................................................................................................................. 43
15.
Appendix D – POLICY CONTROL FORM ......................................................................................... 44
15.1.
Introduction .................................................................................................................................. 45
15.2.
Background .................................................................................................................................. 45
15.3.
Completion Instructions ............................................................................................................... 46
16.
Appendix E – document types available in the ACORD A54 Code List ............................................ 48
17.
Appendix F – DRI Work Order Completion ........................................................................................ 52
18.
APPENDIX G – DRI MESSAGE VALIDATION .................................................................................. 54
19.
APPENDIX H – CORRECTION FORM.............................................................................................. 57
20.
APPENDIX J – BROKER EPA SIGNINGS ADVICE (DL5089) ......................................................... 58
Record ........................................................................................................................................................... 58
Quantity ......................................................................................................................................................... 58
Notes ............................................................................................................................................................. 58
Header Record .............................................................................................................................................. 58
1 .................................................................................................................................................................... 58
This is the first record in the file. ................................................................................................................... 58
Column Header Record ................................................................................................................................ 58
1 .................................................................................................................................................................... 58
This is the second record in the file. ............................................................................................................. 58
Data Record .................................................................................................................................................. 58
Many.............................................................................................................................................................. 58
These follow the column header record. The first field of each data record will be the group identifier. ...... 58
Footer Record ............................................................................................................................................... 58
1 .................................................................................................................................................................... 58
This is the last record in the file. ................................................................................................................... 58
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 3 of 60
Date: 09/03/07
1. PURPOSE OF THE DOCUMENT
This document details the main steps required for a Customer (Broker or Carrier) to
establish and maintain access to the Market Repository utilizing Xchanging’s
implementation of the ACORD Document Repository Interface (DRI) standards.
This document supports Accounting & Settlement (A&S) Release 2 as documented in the
A&S Functional Specification V2.0. dated 31/07/06
This document should be read in conjunction with the DRI Technical Interface
Specification v3 (September Release).
2. SCOPE
This document is with regard to Release 1 and 2 only. The document will be amended for
subsequent releases but it is expected that changes to the content and structure will be
minimal.
This Customer User Guide will provide a Broker or Carrier with sufficient information or
references to design and put in place all the necessary components to enable it to
exchange documents with the Market Repository.
It also details the end-to-end process to be followed from receipt of an initial DRI enquiry
from the Broker or Carrier to rollout into Production, as well as what interim information
and system components are needed by whom and when.
It also details the processing procedures for transactions once submitted by DRI.
This document does not intend to duplicate any information found in the following
documents:

Technical Information for London Market Implementation of ACORD DRI Messages
V1.0

LM ACORD DRI Completion and Validation Rules V1.0

Section 5 of the Technical & Other Information to Support the A&S Detailed Business
Design
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 4 of 60
Date: 09/03/07
3. BACKGROUND
DRI is the method by which documents can be exchanged electronically between
document repositories and is the method supported by the Market Repository.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 5 of 60
Date: 09/03/07
4.
ROLL-OUT PROCESS
4.1. Registration
The registration process involves the Broker or Carrier (or their third party supplier)
completing the DRI Registration Form, provided in Appendix A of this document. This
form holds various details including customer / third party provider contacts, message
types to be used, planned dates for testing and production roll-out and security
information.
Once the form has been received and validated, Xchanging will take the necessary steps
to set up the customer for DRI use.
The registration process will typically take 1 to 2 working weeks. This is conditional on
certification being complete.
4.2. Integration Testing
Upon completion of the registration and certification process, a period of testing will be
undertaken to ensure that the customer and Xchanging can process the exchange of the
required message types and documents successfully.
Integration Testing can take up to 2 working weeks.
4.3. Production Roll-out
Upon completion and sign-off of Integration Testing, the DRI service will be made
available in the Production environment.
Production Roll-out will take up to 1 working week.
The above process is sequential. Each stage needs to be completed as entry criteria for the
next step.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 6 of 60
Date: 09/03/07
5. REGISTRATION PROCEDURES
This section describes the processes and procedures to be followed in respect of new DRI
Registrations.
5.1. New DRI Registration:
To establish registration for the DRI service the Customer should contact Xchanging’s DRI Coordinator, Graham Sheppard on 01634 887742 or 07917 423308 or at
graham.sheppard@xchanging.com .
The DRI Co-ordinator will set-up a meeting to provide high level information and discuss
customer requirements in more detail. The meeting will cover the following areas:
-
Overview of registration process
-
DRI co-ordinator’s role
-
Other points of contact within Xchanging
-
Overview of scope of testing
-
Technical requirements
-

ACORD compliance

Message Types

Digital Certificate from a Trusted Certification Authority
Customer status and plans
The DRI Co-ordinator will need to secure the following information from the Customer
 Is a Service Provider likely to be used to host the ACORD Messaging Service?
 Customer Contact details (i.e. name, postal address, telephone number, email
address, fax number)
 Broker or Carrier number(s)
 Customer expectations re rollout timetable
The customer will need to complete the DRI Registration form (see Appendix A for example form)
as follows:
 Message Types
Details of the message types and versions can be found in the document Technical
Information for London Market Implementation of ACORD DRI Messages Version 1
 Preferred Effective Start Dates for the following environments:

Integration Testing

Production
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 7 of 60
Date: 09/03/07
 Customer contact details

Name

Address

Contact details

Signature of Authorised person within Customer Organisation
 Broker or Carrier numbers
 Details of Sender / Receiver of messages
For each environment, the following configuration details of the Sender(s) are required
before Testing / Production can start:

Party Id (i.e. relevant Broker No / Duns No, as appropriate)

Party Name

ACORD Messaging Service URL

Digital Certificate details (Public Key) from Trusted Certification Authority
The Customer may choose to appoint a Service Provider to host the sending and receiving of
DRI messages on their behalf. The Service Provider may be used to host the operation of the
DRI messaging service for Integration Testing and/or Production.
The Customer should return the completed and appropriately authorised DRI Registration form to
the DRI Co-ordinator. The DRI Co-ordinator will provide assistance with completing the DRI
Registration form as required and will then liaise with the Xchanging technical team responsible
for establishing the registrations on behalf of the customer.
5.2. Amending existing registration details:
Note that for all amendments to existing registration details, an updated DRI Registration form
should be delivered to the DRI Co-ordinator.
It is possible that an element of integration re-testing may be required depending on the impact of
amending the existing DRI registrations and on which elements have changed. This will be
managed by the XIS DRI Co-ordinator upon request.
5.3. DL 5079 Report of unmatched items
DRI claims submissions are referenced by UMR and UCR and will attach documents to
previously created workspaces generated from the CLASS submission. Where the UMR / UCR
combination cannot be found on the Market Repository immediately the process will continue to
attempt to match records for a period of 24 hours. If this is still not successful a report, identified
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 8 of 60
Date: 09/03/07
as report number ‘DL5079’, will be emailed to brokers using GENESYS (Generic Email System).
This is an established XIS production service for delivery of reports by email. The file will be in
CSV format and will conform to the standard layout required by GENESYS. The report will
include information including Senders ID, UMR, UCR, TR and details of each document including
time and date sent, and the document ID.
Brokers will need to be registered for this report which will be referenced by the Broker Number
or Print Sort Code. The registration form for this report forms part of the DRI registration form at
Appendix A and should be completed with the remainder of the DRI registration form. The XIS
DRI Co-ordinator will ensure this is processed to the appropriate registration team.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 9 of 60
Date: 09/03/07
6. TECHNICAL REQUIREMENTS
For full technical information please refer to the ‘London Market Implementation of ACORD DRI
Messages’ document available from the market reform website at:
http://www.marketreform.co.uk/electronicclaims_pubs1.htm
6.1. ACORD Compliance
Xchanging’s software supporting the DRI functionality has been developed in accordance
with the standards defined by ACORD. All software developed by, and on behalf of,
Customers must also have been developed in-line with those same standards. For that
reason, the compliance of all software with the relevant ACORD standard is an entry
requirement into the Testing phase between Xchanging and the Customer.
Compliance of software with the ACORD standard can only be secured from, and certified
by ACORD.
ACORD certification shows that your organisation implemented the ACORD data
standards accurately, met the technical requirements, and reported those achievements
to ACORD. Only ACORD members are eligible for certification.
With ACORD certification Xchanging can be sure that your DRI system follows ACORD
Standards before testing begins.
For further information about how your organisation can achieve ACORD certification,
contact details for ACORD include:
-
web-site www.ACORD.org
-
London office details :

London Underwriting Centre
Suite 1/3, 3 Minster Court
Mincing Lane
London EC3R 7DD

Phone 020 7617 6400

Fax 020 7617 6401
Public specifications and documentation can be downloaded from
http://www.acord.org/standards/reprop.aspx
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 10 of 60
Date: 09/03/07
6.2. Ports
All environments are firewall protected and therefore have restricted port access. If, due
to your local set up, you require a different port to the normal HTTPS port (443), please
use port 8443. However, please advise the DRI Co-ordinator before commencing use.
6.3. Digital Certificates
An x509 digital certificate is required to digitally sign the SOAP body of any SOAP request
message. The public key for this certificate must be given by the sender to the receiver
before the first transaction, in order to verify the signature. This is sent out of band (e.g.
by email).
A certificate is required by the receiver to enable SSL transactions with their server. The
same certificate can be used for both processes.
Digital certificates can be obtained from a number of certification authorities, such as
Verisign and Comodo. Whilst Xchanging does not recommend any particular company,
the Certification Authority of any certificate must be trusted by both parties in the
transaction.
Further information relating to the use of Digital Certificates can be found in the document
ACORD Security Profiles V 1.0.0
6.4. Technical / Development Requirements
SOAP Server
All SOAP servers partaking in DRI will need to be configured for HTTPS traffic.
Both the x509 certificate used for the digital signing and the server authentication
certificate required for SSL must have been issued by a certificate authority that is trusted
by both parties. Copies of these certificates will need to lodge with Xchanging. In
exchange, a copy of Xchanging’s certificate will be sent to the customer.
Attachments should not be Base64 encoded as Xchanging will not decode them and
therefore they will be presented on the repository in their encoded form.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 11 of 60
Date: 09/03/07
All Customer / Service Provider environments must support 128-bit encryption.
Xchanging as a Trading Partner
When sending to Xchanging, the following information is required from our trading
partners;

Xchanging’s PartyId is urn:duns:236196817

The URL of our External Integration Test (EIT) environment SOAP server is
https://epieitxdh.xchanging.com/AcordMsgSvc/Inbox.asmx

The IP address for the EIT environment is 195.11.222.20

The URL of our Production environment SOAP server is
https://xdh.xchanging.com/AcordMsgSvc/Inbox.asmx

The IP address for the Production environment is 193.195.180.84
It should be noted that this EIT environment also serves as the Disaster Recovery
environment. In the event DR is invoked this will immediately take precedence over any
integration testing. If you firewall connections into your servers, please ensure both of the
above environments are allowed access to your Production service.
HTTP Headers
POST /AcordMsgSvc/Inbox.asmx HTTP/1.1
Content-Length: #####
Content-Type: multipart/related;
boundary=MIME6DC137CD5C744E8D9A61CDC4CD7EA2E4; type="text/xml"
Host: epiuat.xchanging.com
SOAPAction: http://www.ACORD.org/Standards/AcordMsgSvc/Inbox#PostRq
6.5. Technical Standards
ACORD Standards Versions
Documents will be delivered by ACORD DRI messages. ACORD business messages (e.g.
Technical Account) will not be used to supply structured data.
The following combination of ACORD standards versions will be supported in the live
environment with effect from Mid September 2006:
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 12 of 60
Date: 09/03/07

ACORD Messaging Service (AMS) Version 1.4 framework standards, Inbox Post Function

ACORD 1.2 Document Repository Interface (DRI) message standards

ACORD 2005.2 Reinsurance and Large Commercial (RLC) message standards (see note
below)

ACORD 2005.2 Code lists
No other versions or combinations will be supported at this time.
For Accounting and Settlement (A & S) DRI submissions, the Work Order must be formatted as
an object based on the ACORD 2005.2 Technical Account (a.k.a. the ‘skinny TA’) and presented
as a DRI document attachment with a document type code of form_work_order.
Please note that the RLC 2005.2 standards only refer to this ‘Skinny TA’ for A & S and not to full
RLC messages.
Reference Sources
The following ACORD documentation contains details of these standards1:

ACORD Messaging Service Specification and SOAP Implementation Guide (version 1.4)

Security Profiles for the ACORD Messaging Service (Version 1.0)

Document Repository Interface (DRI) Reference Guide (Version 1.2)

Document Repository Interface (DRI) Implementation Guide (Version 1.2)

Repository Interface Data Requirements Matrix (Version 1.2.0)

Reinsurance and Large Commercial (RLC) Message Specification (Version 2005.2)

ACORD Code manual (Version 2005.2)
In addition to the above, please refer to the following documents for additional requirements that
are specific to the London Market2:

Technical Information for London Market Implementation of ACORD DRI Messages V1.0

LM ACORD DRI Completion and Validation Rules V1.0
Section 5 of the Technical & Other Information to Support the A&S Detailed Business
Design
1
These documents are available at the ACORD website at www.acord.org
2
These documents are available on request from Xchanging or at the Market Reform Programme Office website at
www.marketreform.co.uk/publications.htm
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 13 of 60
Date: 09/03/07
7. INTEGRATION TESTING
Before commencing integration testing Xchanging will assume that customers, or their software
suppliers, will have completed an element of testing using the ACORD Test Harness. This will
ensure a smooth transition through the integration test phase.
7.1. Objectives / Scope
The objective of the Integration Test stage is to ensure that:
-
Xchanging are able to demonstrate that the documents held on the Insurers’ Market
Repository are the exact documents that the customer supplied
-
Customer is able to demonstrate that the documents held on the Insurers’ Market
Repository are the exact documents that they delivered
-
Customer correctly processes the full set of requested message types
-
Customer is able to send the appropriate messages and receive and successfully process
the associated response message or download requests from Xchanging.
7.2. Entry Criteria
-
Customer’s DRI messages have been certified as being ACORD-compliant
-
Evidence of testing with ACORD Test Harness
-
Test Plans agreed by Customer / Service Provider and Xchanging
-
URLs for the Test environment(s) have been exchanged
-
Public Keys of Digital Certificates (issued by Trusted Certification Authority) have been
exchanged for the Test environment(s)
-
All Test environments support 128-bit encryption
-
Customer is aware of the points of contact to manage the testing cycle i.e. to resolve
problems or confirm a test has been successful
-
Customer User Ids have been set-up for all appropriate systems (i.e. on-line Repository
and DRI messaging upload / download) and are ‘current’ i.e. not expired
-
If a Service Provider is used to Host the send / receipt of messages, the Service
Provider’s Duns number has been supplied to Xchanging
-
Appropriate supporting test data has been set-up
-
Both Xchanging and Customer have the resources in place to support the planned test
cycle
-
Customer has migrated system components to the expected environments e.g. DB
Tables, Application Software, middleware etc
-
Xchanging has registered Customer details in the Test environment
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 14 of 60
Date: 09/03/07
-
Customer / Service Provider must ensure their system (i.e. firewall settings) allows them
to send and receive messages to / from Xchanging’s URL
-
Xchanging must ensure the firewall allows them to exchange messages with the new
Customer
7.3. Exit Criteria
-
Each individual Test Script has been executed and signed-off
-
Test stage Signed-off by Customer / Service Provider and Xchanging
7.4. Responsibilities
The following table details the main responsibilities of participants in Integration Testing:
Who
Responsible For
Customer
Creating Test plans and scripts
Creating Test data
Providing resources to carry out tests – this includes both customer internal
resource and 3rd party resource e.g. 3rd party supplier resource, document
supplier resource (broker to supply documents for carrier tests)
Migration of any system components
Monitoring of the success of tests & any issues
Xchanging DRI
Acting as first escalation point for any major issues
Co-ordinator
Ensuring the Xchanging environment is ready for testing
Acting as prime contact at Xchanging to field and help resolve any technical
problems and issues related to the testing
7.5. Support & Problem Management
The process to be followed in the event of a problem or issue occurring during testing is
as follows:
Who
Task
Customer
Customer / Service Provider contacts Xchanging’s DRI Test Co-ordinator
Xchanging DRI
Investigates the query using Internal Audit system. They will provide
Co-ordinator
information relating to;
 Messages in the DRI Audit system
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 15 of 60
Date: 09/03/07

DRI Co-ordinator has successfully located the relevant
DRI message / Function

Following an analysis / review by DRI Co-ordinator of the
lifecycle / history of the message(s) associated with the
DRI Function, the status of the DRI message / Function
can be described to the Customer / Service Provider to
their satisfaction.
 The strategy suggested by the DRI Co-ordinator to resolve is
acceptable to the Customer / Service Provider.
 DRI Co-ordinator updates Xchanging Issues / Problem Log
 DRI Co-ordinator sends the latest version of the Xchanging
Issues / Problem Log to the Customer and DRI Co-ordinator
XDH Development
If the DRI Co-ordinator is unable to resolve the problem to the satisfaction
Support / Network
of the Customer / Service Provider, the call is reassigned to the XDH
Support
Development support or XDH Network Support teams, as appropriate, for
further investigation. These type of queries include :
 Messages cannot be traced in the DRI Audit system i.e.
messages from Xchanging to Broker have not yet been received
and vice versa
 Or previous analysis of the messages processed to date reveals
unexpected behaviours
XDH Development / Network Support team(s) perform further
investigations to :
 understand the current status of DRI messages / Functions
 describe the status of the DRI message / Function to the
Customer / Service Provider to their satisfaction.
 The strategy suggested by XDH Development team to resolve is
acceptable to the Customer / Service Provider
 XDH Development / Network Support team(s) provides DRI Coordinator with an update to the status of the Issue / Problem
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 16 of 60
Date: 09/03/07
8. PRODUCTION ROLL-OUT
In order for roll-out to a Production service to commence, the following criteria must be met:
-
Production URLs exchanged
-
Production Public Keys of Digital Certificates (issued by Trusted Certification Authority)
have been exchanged
-
All Production environments support 128-bit encryption
-
Signed off Integration / Configuration Testing by Customer and Xchanging
-
Customer User Ids have been set-up for all appropriate systems and reports (i.e. on-line
Repository and DRI messaging upload / download, DL 5079)
-
Both Xchanging and Customer have the resources in place to support the rollout
-
Xchanging has registered Customer details in the Production environment
-
Customer has migrated system components to the Production environments e.g. DB
Tables, Application Software, middleware etc
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 17 of 60
Date: 09/03/07
9. SIGN-OFF PROCEDURES
Responsibility for written Sign-Off of each of the criterion into/out of the test stage and into
Production must be allocated to an appropriate individual within the Customer, Service Provider
and/or Xchanging.
Not only is each criterion allocated to an individual, but the written Sign-Off is expected to be
delivered to Xchanging’s DRI Co-ordinator by the planned date - defined as a milestone in the
Rollout plan for the Customer.
In addition, for Rollout to the Production environment for each Customer, regular meetings (which
could be done by phone) of stakeholders will take place prior to the target implementation date
(starting 1 week prior to target date) as necessary and as agreed.
Attendees of these meetings may include:

Xchanging’s DRI Co-ordinator (Chair)

Customer Business Manager

Customer / Service Provider Technical Manager

Xchanging’s DRI Project Implementation Manager
Attendees of the meetings will review status of testing for each Customer and assess the
likelihood of a ‘Go’ or ‘No-Go’ decision. If likely to be ‘No-Go’, consider what remedial action is
required, by when and by whom to change it to a ‘Go’?
Input for the final ‘Go No-Go’ meeting includes:

current status of testing etc

written Sign-Off of each ‘Live Entry’ criterion from the responsible individuals
Output from the final ‘Go_NoGo’ meeting is written confirmation of the decision delivered to each
of the attendees by Xchanging’s DRI Co-ordinator (Chair) one full workday prior to target
implementation date. That gives the technical teams at Customer, Service Provider and
Xchanging one full work day to prepare for rollout of all system components to the Production
environment.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 18 of 60
Date: 09/03/07
10. ACORD DRI FUNCTIONS
This section should be read in conjunction with the DRI Technical Interface Specification v3
September Release document, where detailed technical information can be found and the
following documents available on the Market Reform website:
a)
Technical Information for London Market Implementation of ACORD DRI Messages
(Version 1 31st march 2006) –
http://www.marketreform.co.uk/Documents/Claims_pubs/London_Market_Implementation_of_AC
ORD_DRI_Messages.pdf
b)
London Market ACORD DRI Completion and Validation Rules –
http://www.marketreform.co.uk/Documents/Claims_pubs/LM_ACORD_DRI_Completion_and_Val
idation_Rules.xls
In Release 1 Xchanging will apply SOAP-level and business message-level validation.
10.1.
Introduction
10.1.1. Functions Supported
The DRI Technical Interface Specification describes the DRI functionality that will be delivered to
the London Market in Release 1, in order to support the Electronic Premium Accounting process.
The DRI functionality included in Release 1 is:

Load Document (using either Upload or Notify and Download)

Search Local (restricted to UMR search)

Automated Transmission of Documents (using either Upload or Notify and Download)
10.1.2. Submissions for Electronic Premium Accounting
In the current release, which only allows documents to be submitted for Electronic Premium
Accounting (EPA), the sender will not be able to create folders in either the structured or
unstructured area of the Market Repository.
This section provides specific information about the submission requirements for EPA.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 19 of 60
Date: 09/03/07
Folder Creation
The repository will automatically create the necessary folder structures, based on the Unique
Market Reference (UMR) and the document type.
There are three folders to which premium related documents may be allocated within a UMR
container:

Slip Documents

Policy Documents

Miscellaneous Documents.
Documents will be allocated to one of these folders according to the document type (a value from
the ACORD A54 code list – see Appendix E – entered in DocumentTypeCd) that is sent with the
document.
The correlation between document type and UMR folder will need to be maintained (subject to
change control) if the ACORD code list is revised. If a document is received with a document
type that is not recognised it will be rejected.
Work Package Contents
A Work Package is formed of the necessary documents and supporting information to enable
Xchanging to carry out premium and/or policy processing activities on behalf of its customers.
The types of documents that Xchanging would expect to typically receive for each type of
premium and/or policy submissions are shown in Appendix C.
This does not form an exhaustive list and any type of document that is recognised in the ACORD
A54 code list may be submitted, if appropriate. A full list of the document types contained in the
ACORD A54 code list is given in Appendix E.
The Work Order
In addition to the documents listed above, if Xchanging processing is required a Work Order
document must be submitted within the work package in order to instruct Xchanging to carry out
the processing task, otherwise the documents submitted will merely reside in the repository
unprocessed. The Work Order is a key enabler of the EPA solution:
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 20 of 60
Date: 09/03/07

It gives the instruction to Xchanging to initiate the premium and/or policy processing on
behalf of member companies and Lloyd’s syndicates

It references the set of documents that, together with the Work Order, form the Work
Package

It defines the attributes of the Work Package (e.g. Lloyd’s, Marine, Binding Authority).
The Work Order must include the identification of all documents that form part of the Work
Package (excluding the Work order itself). Appendix C shows the types of document that would
be typically expected to be included for each type of transaction.
Where a policy request is submitted as a separate (Stage 2) Work Package this will also require
a Work Order to be included, to trigger the Xchanging system process to create a Tracker record
and generate an email notification to Logistics.
The Work Order must be formatted as an object based on the ACORD 2005.2 Technical Account
(a.k.a. the “skinny TA”) and presented as a DRI document attachment with a document type code
of form_work_order. Details of the completion of the Technical Account are contained in
Appendix F.
Work Order Guidelines for multi-bureau submissions
Where multiple markets closings are required, any one DRI package should contain separate
work orders for each bureau that documents included in the package need to refer to.
For Company business a single work order can be supplied to cater for both ILU and LIRMA, if
separate work orders are sent for ILU and LURMA the XIS operations have no means to
associate the two, running the risk that they will not be processed together.
The Work Order generated for any documents being re-submitted following a rejection should
also refer to all relevant documents submitted against the initial Work Order for the same bureau.
However, if a document is being replaced in a re-submission, the Work Order need not refer to
the original document.
If a document being re-submitted only refers to one bureau (e.g. if the Lloyd’s PAN was omitted
in the first package) then the re-submitted package need only contain a work order for that
bureau. Work Orders for the other bureau need not be re-submitted.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 21 of 60
Date: 09/03/07
11. ACCOUNTING AND SETTLEMENT PROCESSING PROCEDURES
This section describes the A & S Step 1 process for submission and processing of transactions
by DRI method. Details for processing ECF transactions will be found in the Systems Processes
and Procedures document produced by Market Reform Programme Office.
Additional documentation with regard to the Accounting and Settlement project can be found at
the Market Reform Programme Office (MRPO) website www.marketreform.co.uk. The Market
Reform Programme Office was established in 2000 and exists explicitly to define, deliver and
administrate Market Reform. The aim is to create a framework of standards for business
processes that enables firms to deliver services efficiently to customers at a cost and level of risk
comparable with other platforms. The venture is sponsored by Lloyd's, LMA, LMBC and IUA.
11.1.
Scope
The following transaction types are supported:
-
Original Premiums, FDO’s, Additional Premiums & Return Premiums including IUA
Company Reinstatements
-
Policies, including Slip Policies
-
Binding Authorities and Lineslips
-
Non Premium Endorsements
11.2.
Exclusions
The following business types cannot currently be supported, but will be in later releases:

Treaty statement processing

Simultaneous settlement items and Lloyds Reinstatements

Claims

LORS
All excluded business types will be available during 2007.
11.3.
Business Process Rules
IT IS NOT INTENDED THAT CURRENT PROCESSING RULES EXISTING IN THE PAPER
ENVIRONMENT WILL BE CHANGED. THE USE OF DRI FUNCTIONALITY IS REPLACING
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 22 of 60
Date: 09/03/07
PLASTIC ENVELOPES AS A DELIVERY METHOD OF PREMIUM ACCOUNTING
DOCUMENTATION.
Current Xchanging services levels will be applied.
Terms of trade will be measured as per current practise, i.e. an item will be on time if it is
received by Xchanging on or before the Settlement Due Date.
Business will be presented split over markets i.e. Lloyd’s, LIRMA and ILU as per current
instructions.

For all Excess of Loss and Facultative Reinsurance premium only (Stage 1) business
a single work order may be submitted with a 'Mixed' market type, however separate
LPANs should reflect the participations of the ILU, LIRMA and Lloyd's entities. These
can all be sent through in a single submission as separate attachments. Brokers
however need to understand that submissions that are sent in as a single work
order will likely be treated as an entire rejection should one element of the
submission fail.

For all other business separate work orders will be required with a market type of
either 'Companies' or 'Lloyd's' together with separate LPANs. These must be
submitted as separate submissions.
In all cases the slip only needs to be attached once, provided the entire market is displayed and
can be cross-referenced in each of the work orders.
LPANs will be submitted for each transaction to be processed and will be split for all fundamental
and non fundamental accounting splits.
Wherever possible, submissions should be presented as de-linked with PANs clearly marked
“DELINKED”.
Xchanging reserve the right to process items submitted at any of its processing centres.
11.4.
Letter of Indemnity (LOI)
A revised LOI will need to be signed by brokers using Direct Load to submit EPA. The revision
will cover the submission of documents in an electronic format rather than on paper.
The use of computer produced signed lines is already covered by the existing LOI.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 23 of 60
Date: 09/03/07
11.5.
Further Information and Contact Details
For further information regarding Accounting and Settlement please contact your Customer
Relationship Manager.
All technical issues and support should be directed to Xchanging Service Desk on 0870 380
0830 or email to ‘servicedesk@Xchanging.com’.
11.6.
Document Creation
Documents in the following formats are supported:
-
MS Word and Excel (XP and all previous versions),
-
JPEG, TIF, GIF picture formats,
-
Adobe Acrobat format (version 7 and all previous versions).
A first submission is an original premium (including FDO) Work Package that is submitted to
Xchanging for processing for the first time against a UMR for which Xchanging have no previous
record or reference.
For subsequent transmissions, e.g. APs and RPs, and corrections only new documentation
needs to be submitted assuming previous submissions have been electronic. Any documents
submitted in a previous transaction against a UMR, e.g. the slip sent at Stage 1 need not be sent
with the current submission.
LPANs can be aggregated and sent in a single document, although it is Xchanging’s
preference that, where possible, LPANs are submitted individually. For DRI submissions
the aggregating of LPANs will provide incorrect information in the ‘LPANs Count’ fields on
the Work Order.
11.7.
Document Naming
All documents should be named to clearly identify their purpose. (For example LPAN1, SLIP). A
list of the expected types of document is provided in Appendix B. This enables Xchanging to
undertake loading of the documents to the Market Repository and efficiently manage the
processing.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 24 of 60
Date: 09/03/07
There are no prescribed rules regarding document naming. XIS require a logical I.D., a
name that clearly identifies the content and purpose of the document. Dates are not
essential as the date of load is recorded.
A full audit trail will be maintained for every document loaded onto the Market Repository. The
document history is available from the Policy page. If previously sent documents are re-sent they
will become duplicates since version control is not applied within the repository for Release 1.
11.8.
Legacy Processing
Where XIS have already processed submissions on a contract using paper media, subsequent
submissions can be submitted, however a full and up to date copy of all previously submitted
paper needs to be included as part of the initial submission package3. The broker must also
provide a copy of the signed slip with all previously signed endorsements.
11.9.
Policy Type Processing
Policy documents may be submitted together with the premium documents (i.e. as an S&A
request), or separately after the premium accounting process (i.e. as a Policy only request).
In all cases a Policy Control Form (PCF) must be submitted to define the type of policy required
(Slip Policy, PPS or Broker-prepared Policy) and to give other instructions to Xchanging. The
PCF form completion instructions are enclosed in Appendix D, along with a sample form. An
Excel version of this, complete with macro driven validation, is available on request4. A correction
form is also enclosed in Appendix H.
If a slip policy is submitted, the slip document will be printed by Xchanging and, upon completion
of checking and signing, will be returned to the broker as a paper document.
If a broker-prepared policy is submitted, the broker must submit the policy document. This will be
printed by Xchanging and, upon completion of checking, signing and sealing, will be returned to
the broker as a paper document. An electronic signed copy will not be stored on the repository.
3
Contact Service Desk on 0870 380 0830 or ServiceDesk@xchanging.com
4
The Publisher of a document is the organisation that sets and retains control over content, versions, Access Control Lists and
metadata
4
Contact Service Desk on 0870 380 0830 or ServiceDesk@xchanging.com
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 25 of 60
Date: 09/03/07
The printing of policy documentation is a temporary solution pending the outcome of legal
discussions and development of a technical solution to producing electronic policies. This will be
addressed during 2007.
11.10. Correction Processing
All requests for correction processing, premium and policy, must be accompanied by a correction
form (see Appendix I). Failure to complete this form may result in Xchanging being unable to
process the correction fully.
11.11. Nil / Non Premium Endorsements (NPEs) Processing
Stand alone NPEs that do not require immediate action from XIS can be added to the
repository in isolation and therefore no work order should be added to the NPE. However, at
the next premium submission the relevant, previously loaded, NPEs should be associated to
the current package within the work order.
If no further premium submissions are expected or a NPE policy endorsement is required
immediately, the NPE may be submitted as a stand alone work package with a work order.
Policy endorsements should be referenced to a work order and contain a Policy Control
Form (see Appendix D).
11.12. Submissions in Error
If an EPA submission is made in error, or contains errors (for example documents or LPANs are
omitted) the broker should contact Xchanging Enquire Helpdesk urgently on 01634 887789 and
request the item is rejected. Once rejected the broker should then resubmit the entire work
package.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 26 of 60
Date: 09/03/07
Where individual documents are added in error the broker should contact Xchanging Service
Desk urgently on 0870 380 0830 to request the item be removed from view. There is no facility to
delete items from the Repository. Xchanging will check with every party to have already viewed
the document, or have been notified of the document by DRI, that they are in agreement to
remove viewing rights to the document. Xchanging will then amend the security to prevent the
document being further viewed by any party.
11.13. Broker Mid Term Changes
Where a contract transfers between brokers mid term UMR rules state that the UMR continues
throughout the life of the contract, however repository security will prevent the new broker
accessing the UMR on the repository. In these cases it will be necessary to revert the risk to a
paper submission.
11.14. Completion of Items
Brokers will continue to receive their BSM signing advice, except where existing business rules
dictate otherwise, e.g. for delinked items.
11.14.1.
Signing Number and Date Extract and Load
The Market Repository is updated each night with the EPA signing numbers and dates
(SN&Ds) and associated data, which is stored as standing data for the UMR.
11.14.2.
Package View User Interface
The Policy Page shows the original premium/FDO signings for the UMR. The data
elements for each original signing will be displayed on one line, in the following sequence:
o
Signing Number & Date
o
Market (LL=Lloyd’s, IL=ILU, or LR=LIRMA)
o
Slip Section (Lloyd’s only)
o
Entry Type Code
o
Risk Code
o
DTI Code
o
FIL Code (Lloyd’s only)
o
Country of Origin (Company market only)
o
Original Currency Code
o
100% Gross Premium Amount
o
Signing Status
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 27 of 60
Date: 09/03/07
The user is able to click on any Original Signing Number & Date to display the
subsequent signings that attach to it. There are also two icons at the right of the
information for each signing listed, to provide links to:
o
The Work package view for that signing. This screen will list the Work Packages
that have been received for the UMR. The Work Package with which the selected
signing is associated will be highlighted and its document set will be listed.
Selecting a different Work Package from the list displayed will cause the
documents for that work package to be displayed.
o
The market details for that signing. This screen will display the selected Signing
Number & Date and applicable market (Lloyd’s, ILU or LIRMA), and list the
Company Codes/Syndicate Numbers and the Underwriter’s References for each
risk participant.
Each signing number & date is associated with the work package in which it was
submitted. This is achieved by matching the UMR and work package reference contained
in the end-of-day extracts from POSH and LIDS with the details stored on the repository.
11.14.3.
EPA Signings Advice to Brokers
Completion of items are notified back to the Broker by sending an email to the registered
contact attaching a CSV file containing both Lloyd’s and Company market signings for
original premiums and FDOs submitted for EPA. The file structure of this report is
attached as Appendix J. The report will be identified as report number ‘DL5089’, which
will be emailed to brokers using GENESYS (Generic Email System). This is an
established XIS production service for delivery of reports by email. The file will be in CSV
format and will conform to the standard layout required by GENESYS.
A single message is output at the end of each day containing both Lloyd’s and company
market signings for all electronic risks submitted for EPA.
Brokers will need to register to receive this optional message5. A single registration will be
established for both Lloyd’s and Company market business, as these will be delivered
together in the same file. All queries concerning transmissions should be addressed to
the Xchanging Service Desk.
5
Contact the Service Desk (0870 3800830) if you wish to register to receive this message.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 28 of 60
Date: 09/03/07
Data is extracted from the Xchanging legacy systems at the end of each day, containing
Lloyd’s and company market signings for that day. Only signings that resulted from an
electronic submission will be included.
If Lloyd’s signings that have been corrected under the same SN&D (i.e. without a new
SN&D being allocated), they will be re-advised under a new version of the SN&D if any of
the advised data has been amended.
For cancellation signings the SN&D of the referred cancelled signing will be output. The
cancellation will not itself be output. Only the UMR, the SN&D, the Broker Contact and the
Signing Status Code will be output. All other fields will be empty.
When submitting subsequent paper Claims transactions to Xchanging Claims Services
(XCS) it will be necessary to add a filtered version of this file containing the relevant
signing(s) to the claims file.
If this file is not received when expected, or does not contain the expected results,
it is imperative that brokers contact Xchanging Service Desk (0870 380 0830)
immediately so that an investigation can be instigated.
11.14.4.
Updated Package Status
A ‘work package status’ will be available in the Market Repository, updated (in real time)
as the Tracker record is updated by Xchanging Logistics or Technicians. This will indicate
to users how far the package has progressed indicating by allocating a status of:
o
In Progress
o
Queried
o
Rejected
o
Completed
Where there is more than one transaction in a work package it is possible that not all will
have the same status value on Tracker. In this case an "aggregate" status for the Work
Package will need to be provided to the Repository. The following rules will be applied:
1. If any of the LPANs have been rejected then the Work Package Status will be set
to “Rejected”
2. If any of the LPANs have been queried (but none rejected) then the Work Package
Status will be set to “Queried”.
If any of the LPANs are in progress (but none have been queried or rejected) then the
Work Package Status will be set to “In Progress”.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 29 of 60
Date: 09/03/07
11.15. Advice of de-linked items
A daily advice of de-linked signings will be available for transmission to brokers. This will advise
of all de-linked signings, including those that were paper closed.
A choice of two output methods will be provided:

EDI messages, in the format of the current BSM message

A comma separated values (CSV) file.
11.15.1.
De-linked Signings Advice - EDI message
This will be identified as a new message type, called ‘IPCBSM’, for which brokers will
need to register to receive in addition to the normal BSM message. As today, separate
messages will be output for Lloyd’s and for the company market and each will require
separate registration.
Two separate batch extracts will be produced – one from POSH (for company market
signings) and one from LIDS (for Lloyd’s signings). Only de-linked signings will be
included and they are to be output on the date of signing and not again on the date of
release into settlement.
In most respects the new IPCBSM message will operate exactly as the existing BSM
message. However, the following differences between the new message and the current
BSM should be noted:

For convertible currency transactions, the Rate of Exchange and the Bureau
Share Settlement (both in the SGN segment) will be advised based on the
currency value at that time. These may be subject to change when the signing is
released for settlement.

The Actual Payment Date (in the SGN segment) will not be given, as this is not
known until the signing is released for settlement

The Terms of Trade Lateness and Terms of Credit Lateness (both in the SGN
segment) will not be given, as these are not known until the signing is released for
settlement

The SPT segments (given for company market signings) will not be provided, as a
company’s settlement details cannot definitely be advised until the signing is
released for settlement.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 30 of 60
Date: 09/03/07
It should also be noted that the BSM only allows for 12 characters to be presented in the
UMR field. For electronic submissions Xchanging will require that a fully formatted 17
character UMR be given. Therefore the UMR contained in the IPCBSM message will
represent characters 6-17 of the UMR. The originator type and code prefix (Bnnnn) will
not be output.
The existing EDI signing messages are sent to brokers and underwriters.
11.16. Query and Rejection Processing
Wherever possible, Xchanging will attempt to resolve queries by phone.
For queried items the Xchanging technician will contact the Broker by phone or email. If a
response is received by the end of the next working day which results in no amendment to
documentation, processing will continue without the need to produce a new Work Order.
Otherwise, the item will result in a rejection.
Xchanging have been asked not to amend any documentation that the Broker submits
using this method. This is in line with the A&S design principles agreed by the Market.
Any errors that prevent completion of the item will be rejected back to the Broker who will
need to amend the documentation and provide an electronic re-submission. For
guidelines to LPAN completion please refer to market communication 2004/076 dated 5th
August 2004.
Business queries and rejections raised by Xchanging Technicians during the checking process
will be recorded on Tracker and communicated to the Broker by email.
11.17. The Tracker Process
All broker technicians will need to be set up to access Tracker to retrieve and respond to queries
raised. This will be administered by Xchanging Service Desk and discussed during the
preparation and planning phase.
11.17.1.
The email address
Tracker will automatically generate the address to which the email will be sent, using the contact
email address that was provided by the broker on the Work Order.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 31 of 60
Date: 09/03/07
If the email cannot be delivered for any reason (e.g. the address has been incorrectly provided
on the Work Order) the technician will be notified. They will then be able to amend and re-send
as necessary.
11.17.2.
The email subject
Tracker will automatically generate the email subject, from information given by the broker on the
Work Order.
The subject field will contain the following elements, each of which will be separated by a forward
slash:
 The status being notified – either Query or Rejection
 The UMR
 An application identifier - a fixed value of A&S
 The processing requested – 1 (Premium only), 2 (Premium & Policy) or 3 (Policy only
including NPE)
 The class of business – M (Marine), A (Aviation) or N (Non-Marine)
 The type of contract – B (Binding Authority), D (Direct Insurance), E (Excess of Loss),
F (Facultative Reinsurance) or P (Proportional Treaty).
 The type of policy – 1 (Slip Policy), 2 (PPS) or 3 (Broker Policy)
For Example: Query/UMR/A&S/1/M/B/1
All broker technicians will need to be set up to access Tracker to retrieve and respond to queries.
11.17.3.
The email content
The following standard text will be presented in the email:
Xchanging have identified an issue within the submission detailed in the subject field
above, for details of the query please click on the link (below).
The email, subject will then be repeated, followed by the summary text that has been entered by
the technician.
A link to the Tracker sheet is included.
Further standard text will be presented as follows:
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 32 of 60
Date: 09/03/07
Please answer this query by replying to this email. If Xchanging does not receive a timely
response (before the end of the next working day) to the queries raised then the
documentation will be rejected. If you are having problems clicking on the link to the query
sheet above please paste the URL below into your browser
The URL of the Tracker query sheet is included.
11.17.4.
Accessing the query sheet
The Tracker query sheet will be accessed via the Xchanging Portal. The broker may click on the
Tracker link provided in the email, or cut and paste the URL into their browser.
Whichever of these options is used, the following process will be the same:
1. If the user is not logged on to the Xchanging Portal, the Portal Login Page will be
displayed and the user will be required to enter a recognised user name and Password. If
the user is already logged on to the Xchanging Portal this step will be bypassed.
2. The Tracker query sheet will be presented. This will contain full details of the reason(s) for
query or rejection.
N.B. Where an item has been queried, the broker should contact the Xchanging technician either
by telephone or email, to resolve the issue. If no response has been received from the broker by
the end of the following working day the queried item will be rejected. The Xchanging technician
will update the tracker status to “query rejected” and a further email will be sent to the broker to
advise them that the item has been rejected and will need to be re-submitted for processing.
11.18. Process for Urgent Resubmissions of queried items
The broker will use the DRI function to submit:
• Any additional and/or amended documents as necessary
• A work order referencing the complete set of documents for the Work Package
(including both new/amended documents and previously submitted unchanged
documents).
The work order will contain:
• A Submission Type of “Resubmission”
• The XIS Technician Name
• The words “URGENT RESUBMISSION” in the explanatory narrative. It is essential
that this is spelt correctly.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 33 of 60
Date: 09/03/07
The broker should also use phone or email to inform the XIS technician who raised the query to
advise that the resubmission is in progress. This is to prevent the original work package being
rejected.
When a technician queries a broker submission they will retain the original Work Order, pending
resolution of the query.
If the broker advises of the resubmission by the end of the next working day after the query was
raised the technician will:
• Locate the original Work Order and mark it as being re-submitted
• Await the delivery of the new Work Order for the resubmission
• Update the Tracker status of the original work package to “rejected”
• Process the re-submission work package as normal, entering the original Presentation
Date onto POSH/LIDS
If the broker’s email /phone call advising the re-submission is not received by end of next working
day after the query was raised, the technician will reject the original submission. The broker will
then need to resubmit as normal and the submission will receive a new Presentation Date.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 34 of 60
Date: 09/03/07
12. APPENDIX A – DRI REGISTRATION FORM
For Xchanging ACORD SOAP Messaging Service (DRI)
(Customer Registration)
Message Options as Sender
Please indicate below which messages you wish to transmit to Xchanging:
Message
type
Description
ACORD Version
ACORD DRI Message Version:V1.2.0 (Y/N)
ACORD Messaging Service (AMS) Version:-
UploadRq
ACORD DRI
V1.4.0 (Y/N)
Upload Request
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
ACORD DRI Message Version:V1.2.0 (Y/N)
ACORD Messaging Service (AMS) Version:-
NotifyRq
ACORD DRI
Notify Request
V1.4.0 (Y/N)
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
SearchRq
ACORD DRI
Search Request
DRI Customer pack – Version 8.2
Author – Graham Sheppard
ACORD DRI Message Version:V1.2.0 (Y/N)
Page 35 of 60
Date: 09/03/07
ACORD Messaging Service (AMS) Version:V1.4.0 (Y/N)
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
Accounting and Settlement (IMPORTANT)
If you wish to submit messages for Accounting and Settlement submissions to Xchanging please
note that you will need to send in a ‘Skinny TA’ as an attachment.
Message Options as Receiver
Please indicate below which messages you wish to receive from Xchanging. Please note that we
can only register you for either UploadRq or NotifyRq, not both:
Message type
Description
ACORD Version
ACORD DRI Message Version:V1.2.0 (Y/N)
ACORD Messaging Service (AMS) Version:-
ACORD DRI
UploadRq
Download
V1.4.0 (Y/N)
Request
Test URL:- _______________________________
Production URL:- __________________________
ACORD DRI Message Version:-
NotifyRq
ACORD DRI
V1.2.0 (Y/N)
Notify Request
ACORD Messaging Service (AMS) Version:V1.4.0 (Y/N)
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 36 of 60
Date: 09/03/07
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
Note:- SOAP Response Messages (i.e. PostRs) will be sent to the same URL from which the
equivalent Request Message is received.
Further Details
Preferred Effective Start Dates:
Integration Testing
Production
/
/
/
/
Organisation details
Contact name
Organisation
Position
Address
E-mail address
Fax no.
Tel no.
Signature and Date
Broker Numbers
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 37 of 60
Date: 09/03/07
Note: Please supply a list of broker numbers. The details entered above must apply to all Broker
Numbers issued.
N.B. This does not necessarily mean that ACORD Messages for numbers listed will be
transported within the same SOAP envelope.
Service Provider
If a Service Provider is to send/receive messages on your behalf, please specify their details:Party Id.
Party Name
Security
Digital Signatures - The Public Key should be e-mailed separately to the e-mail address at the
bottom of this form):Name of Certificate:-
_____________________
Integration Testing
Start Date of Digital Certificate:-
/
/
Expiry Date of Digital Certificate:-
/
/
Start Date of Digital Certificate:-
/
/
Expiry Date of Digital Certificate:-
/
/
Production
DL5079 email (Error message for documents loaded without UMR)
Please supply an email address to receive an error message after every 24 hours that a
document is loaded without associated UMR / UCR details:
____________________@______________
The completed form should be returned to:
Graham Sheppard,
Xchanging DRI Co-ordinator, Walter Burke Way, Chatham Maritime,
Chatham, Kent ME4 4RQ
E-mail:-
graham.sheppard@xchanging.com
Telephone:-
+44 (0)1634 887742
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 38 of 60
Date: 09/03/07
Mobile:-
+44 (0)7917 423308
Facsimile:-
+44 (0)1634 887510
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 39 of 60
Date: 09/03/07
13. APPENDIX B – BUSINESS RULES (BUSINESS DECISION LOGIC) FOR ELECTRONIC
CLAIMS FILE-ECF DRI MESSAGES
-
The total size of the SOAP message and any attachments cannot be more than 20MB
-
Duplicate documents (i.e. with the same ‘document name’) are valid and will be loaded to the
Market Repository
-
UMR, Sender and Receiver are all mandatory fields.
-
Any document that has only a UMR is assumed to be a slip related document and will be
stored in the folder referenced by the UMR. Any document that has a UMR and UCR is
assumed to be claim related document and will be stored in the folder referenced by the
UCR. (The UCR will be used to associate the document with a Class record and is therefore
essential for any claim related documents).
-
If a document is received with a UMR or UCR that does not already exist on the repository a
new folder will be created, but only the document sender will be able to see it. Once the Class
data is received with the UMR and UCR quoted, the folder details will be updated with the
Class data and the full market, XCS and the broker will have access to the folders and
documents. If no Class data is received to complete the folder within 24 hours the
document(s) will be reported.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 40 of 60
Date: 09/03/07
14. APPENDIX C – DOCUMENTS BY TRANSACTION TYPES
The following pages show the types of document that are typically expected to be provided for
each type of premium and/or policy submission, together with recommended naming conventions
for those documents.
The documents identified below as either optional or mandatory may not in some cases be
required where market practice differs from this, or slip provisions exist which negate the need for
certain documents to be produced. This table is provided for the assistance of market
practitioners and will not result in a any change to the documents that Xchanging expect to
receive when processing such items.
Original Premium

Slip (may include a schedule of items)

Slip Attachments (these will require underwriter authorisation
(M)
unless they are part of the placing slip)

Pre closing Endorsements (showing underwriter authorisation)

Calculations/Supporting Information:
o
LPO301 should be provided to distinguish differences in section
coverage, security, and/or where Lloyd’s coding requirements
change (e.g. multiple risk codes are identified)
o

LPO208 should be provided where multiple currencies are used
LPAN(s)
(M)
Premium FDO (For Declaration Only)

Slip

Slip Attachments (these will require underwriter authorisation
(M)
unless they are part of the placing slip)

Pre closing Endorsements (showing underwriter authorisation)

Calculations/Supporting Information:
o
LPO301 should be provided to distinguish differences in section
coverage, security, and/or where Lloyd’s coding requirements
change (e.g. multiple risk codes are identified)
o

LPO208 should be provided where multiple currencies are used
LPAN(s)
(M)
AP / RP Premium Endorsement

Endorsement (showing underwriter authorisation)
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 41 of 60
(M)
Date: 09/03/07

Calculations/Supporting Information

LPAN(s)
(M)
AP/RP Premium Adjustment

Endorsement (showing underwriter authorisation)

Calculations/Supporting Information

LPAN(s)
(M)
(M)
AP/RP Nil Adjustment

Endorsement (showing underwriter authorisation)

Calculations/Supporting Information

LPAN(s)
(M)
(M)
Non Premium Endorsement

Endorsement (showing underwriter authorisation)
(M)
Risk Market Change

Endorsement (showing underwriter authorisation)

Scanned/Imaged Slip Attachments

Calculations/Supporting Information.

LPAN(s)
(M)
(M)
Binding Authority

Binding Wording6
(M)

Slip
(M)

Slip Attachments (these will require underwriter authorisation
unless they are part of the placing slip)

Pre closing Endorsements (showing underwriter authorisation)

Calculations/Supporting Information:
o
LPO301 should be provided to distinguish differences in section
coverage, security, and/or where Lloyd’s coding requirements
change (e.g. multiple risk codes are identified)
o

LPO208 should be provided where multiple currencies are used
LPAN(s)
(M)
6
If the slip contains all details and the client does not wish a full wording to be issued then brokers need only attach a separate
schedule to the slip to constitute Contract Certainty
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 42 of 60
Date: 09/03/07
Lineslip

Slip

Slip Attachments (these will require underwriter authorisation
(M)
unless they are part of the placing slip)

Pre closing Endorsements (showing underwriter authorisation)

Calculations/Supporting Information:
o
LPO301 should be provided to distinguish differences in section
coverage, security, and/or where Lloyd’s coding requirements
change (e.g. multiple risk codes are identified)
o

LPO208 should be provided where multiple currencies are used
LPAN(s)
(M)
Endorsement on a Lineslip (Facultative/Bulking/Binding Authority)


Endorsement (showing underwriter authorisation unless otherwise
specified in the subscription agreement section)
(M)
LPAN(s)
(M)
Bordereau Declarations off of a Lineslip/Binding Authority

Endorsement (showing underwriter authorisation unless otherwise
specified in the subscription agreement section)
(M)

Bordereau Document
(M)

Calculations/Supporting Information

LPAN(s)
(M)
POLICY

Policy Control Form

Wording

Wording Addenda
Notes
– A Work Order must also be submitted with each Work Package
– Policy processing requests may be made with a premium submission (i.e. S&A) or as a
separate submission after premium processing (i.e. Stage 2)
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 43 of 60
Date: 09/03/07
15. APPENDIX D – POLICY CONTROL FORM
Policy Control Form
Failure to complete this form fully may result in Xchanging being unable to locate the originator of
this submission.
POLICY SUBMISSION/PREPARATION REQUEST
Broker
_______________________________________ Broker
______ Broker
Contact:
___
Broker
_______________________________________ Broker
________________________
E mail:
____
__
UMR
B
Class of
______ (M = Marine, N = Non-Marine, A = Aviation)
No:
Tele No:
________
Pseud:
Business
Type of
______ (B = Binding Auth, D = Direct, F = Fac RI, X = Excess of Loss, L = Lineslip, P =
Contract
Type of
Prop Tty)
______ (B = Broker Produced, P = LPSO Produced, S = Slip Policy, E = Policy
Policy
Endorsement, L = PPS Endorsement, T = Time On Risk)
Wording
________________________________________________ No of
_____________
Type
_ (Policy Form e.g. NMA1650, AVN1C, etc.)
__
Copies
PPS Submissions
Full Policy/
Renewing (if applicable) show last years
Wording
SN&D
*
Standard
Wording
Jacket
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 44 of 60
Date: 09/03/07
Countersignature Page
Yes / No
Required
Wording Wrapping Service
Standard
Special Instructions: (Please indicate here if contract was subject to a Xpresscheck)
15.1.
Introduction
This document provides instructions for Brokers on the completion of the Policy Control Form
(PCF) which is required to be presented as part of any electronic packages presented under
Accounting and Settlement (A&S) where a policy type action is required.
15.2.
Background
The ability for Brokers to make submission of policies to Xchanging via the A&S process has
introduced a series of business considerations to be addressed to enable the Broker to instruct
Xchanging on how the policy documents should be completed. As a result it has been agreed
that a PCF should accompany any policy submissions (including policy Endorsements and slip
policies).
The PCF serves the following purposes:

To inform XIS what policy action is required

To instruct how many original and copy policies are required

To provide PPS instructions to XIS

To note who the policy contact is for return of completed policies or in the event of queries

To assist in XIS work allocation in the absence of the paper document
The form is currently in use for paper submissions and its use has been adapted to be used for
electronic submission.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 45 of 60
Date: 09/03/07
15.3.
Completion Instructions
The PCF should accompany any A&S submission where there is a policy element to the
submission, e.g. Broker Policy, PPS, Slip policy to be signed, Policy endorsement required. As
part of the work package the Broker must provide the PCF.
Missing or incomplete PCFs may lead to the package being rejected.
Separate PCFs should be included in each work package where applicable on multi market risks
The attached sets out the guidelines:
Field
Instruction
Broker contact
The name of the Policy technician to who queries or the
completed document should be directed to
Broker No
Broker organisation number
Broker Pseud
Broker organisation pseudonym
Broker email
Email address for broker contact
Broker tele no
Telephone number for Broker contact
UMR
The Unique Market Reference for the slip
Class of Business
Complete with the letter to indicate the class of business covered
options as shown on the form
Type of contract
Complete with the letter to indicate the type of contract options as
shown on the form
Type of policy
Complete with the letter to indicate the type of policy being signed
options as shown on the form
Wording type
Information to denote the wording type or class of business, e.g.
Registration number if registered wording
Sub class of business i.e. PI, D&O, BB etc (alternatively the risk
code can be shown
Indication if wording is a to follow wording
No of copies
Used to denote how many copies of the policy are required to be
produced. (originals and copies)
Full policy/wording
Not required
Renewing….
Not required
Standard wording jacket
Not required
Countersigned page
Not required
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 46 of 60
Date: 09/03/07
Wording wrapping
Not required
service
Special instructions
This field should be used to provide any additional information
that is not covered above. In particular:

Notification if the item has already been subject to the
Xchanging Xpresscheck service prior to submission and is
now submitted agreed as sign as seen. The original bar
code must be shown

The policy is a to follow policy

Illinois. As information only. Normal business processing
rules apply.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 47 of 60
Date: 09/03/07
16. APPENDIX E – DOCUMENT TYPES AVAILABLE IN THE ACORD A54 CODE LIST
Document Storage in UMR Folders
The following pages shows the document types available in the ACORD A54 Code List (2005.2)
and describes the Market Repository folders in which each document type will be stored.
ACORD LONGCODE
DESCRIPTION
acknowledgement
Acknowledgement
acknowledgement_first_notice_client
First Notice Client Acknowledgement
acknowledgement_inquiry_loss_market
Market Inquiry Acknowledgement
acknowledgement_loss_market
Market Acknowledgement
advice_claim_movement
Claim movement advice
advice_claim_movement_seen
Claim movement advice, seen
advice_commission
Commission advice
advice_deposit_premium
Deposit Premium advice
attorney_info_complaint
attorney_info_correspondence
attorney_info_coverage_counsel_correspondence
attorney_info_defense_counsel_report
attorney_info_pleadings
attorney_related_info_trial_report
booklet
booklet_insurance_policy
booklet_insurance_policy
booklet_product
booklet_reinsurance_contract
bordereau_catastrophe_report
bordereau_line_of_business_detail
bordereau_premium
breakdown
Outstanding Loss and Loss Adjustment Expense
(LAE) Reserve Bordereau
Paid Loss and LAE and Outstanding Loss and
LAE Reserve Bordereau
Paid Loss and Loss Adjustment Expense (LAE)
Bordereau
Premium Bordereau
bordereau_premium_and_loss
Premium and Loss Bordereau
bordereau_unearned_premium
Unearned Premium Bordereau
calculation
Calculation
calculation_adjustment_premium
Adjustment Premium calculation
calculation_aggregate_deductible
Aggregate deductible calculation
calculation_claim_reserve
Claim Reserve calculation
calculation_experience_adjustment
Experience Adjustment Calculation
bordereau_outstanding_loss_and_loss_adjustment_expens
e_reserve
bordereau_paid_loss_and_lae_and_outstanding_loss_and_l
ae_reserve
bordereau_paid_loss_and_loss_adjustment_expense
calculation_manual
calculation_profit_commission
Profit Commission calculation
calculation_reinstatement
Reinstatement calculation
calculation_reinstatement_premium
Reinstatement premium calculation
calculation_term_adjustment
Term Adjustment Calculation
Author – Graham Sheppard
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Premium advice
Miscellaneous
Complaint
Miscellaneous
Attorney Correspondence
Miscellaneous
Coverage Counsel Correspondence
Miscellaneous
Defense Counsel Report
Miscellaneous
Pleadings
Miscellaneous
Trial Report
Miscellaneous
Booklet
Policy
Policy
Policy
Booklet: Insurance Policy
Policy
Booklet: Product
Policy
Booklet: Reinsurance Contract
Policy
Catastrophe Report
Miscellaneous
Line of Business Detail US general classification Miscellaneous
advice_premium
DRI Customer pack – Version 8.2
REPOSITORY
FOLDER
Page 48 of 60
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Date: 09/03/07
ACORD LONGCODE
DESCRIPTION
claim_close_aggregate_deductible
Claim Close Aggregate Deductible
claim_close_notice
Claim Closing Notice
correspondence_bank
Bank Correspondence
correspondence_claim
Claim, correspondence
correspondence_client
Client Correspondence
correspondence_cobroker
Co-broker correspondence
correspondence_general_cedent
General Correspondence Cedent
correspondence_general_reinsurer
General Correspondence Reinsurer
correspondence_premium
Premium Correspondence
correspondence_previous_documentation
Previous Documentation
correspondence_reinstatement_of_premium
Reinstatement of Premium
correspondence_reinsurer_status_update
Reinsurer Status Update
correspondence_settlement_documentation
Settlement Documentation
correspondence_underwriter
Underwriter correspondence
document
Other Documentation
document
Document
document_account_information
General Account Information
document_binder
Document: Binder
document_broker_account
Broker Account
document_broker_invoice
Broker invoice
document_certificate
Document: Certificate
document_claims_paid_breakdown
Claims paid breakdown
document_company_closing
Company closing
document_cover_note
Document: Cover Note
document_cover_note_addenda
Document: Cover Note Addenda
document_file_note
File note document
document_information_sheet
Information Sheet
document_market_presentation
Market Presentation
document_operations_description
Description of Operations
document_photographs
Photographs
document_placing_endorsement_agreed
Agreed Placing Endorsement
document_placing_endorsement_signed
Signed placing endorsement
document_placing_slip
Placing Slip
document_placing_slip_agreed
Agreed Placing Slip
document_placing_slip_signed
Signed placing slip
document_reservation_of_rights
Reservation of Rights
document_slip
Document: Slip
document_various_loss_breakdown
Document various loss breakdown
document_void
Void
form
Form
form_declaration
Form: Declaration
form_insurance_policy
Form: Insurance Policy
form_insurance_policy_endorsement
Insurance policy endorsement form
form_policy_control
Policy Control Form
form_quotation_request
Form: Quotation Request
form_reinsurance_contract
Form: Reinsurance Contract
form_statutory_declaration
Form: Statutory declaration
form_work_order
Work Order
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 49 of 60
REPOSITORY
FOLDER
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Policy
Miscellaneous
Miscellaneous
Policy
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Slip
Slip
Slip
Slip
Slip
Miscellaneous
Slip
Miscellaneous
Miscellaneous
Miscellaneous
Policy
Policy
Policy
Miscellaneous
Miscellaneous
Policy
Policy
Miscellaneous
Date: 09/03/07
ACORD LONGCODE
DESCRIPTION
inquiry_collection
Collection Inquiry
inquiry_loss_client
Claim Inquiry Client
inquiry_loss_market
Inquiry
inquiry_loss_response
Inquiry Response
inquiry_specific_request_reinsurer
Reinsurer – Specific Request
inquiry_status_request_reinsurer
Reinsurer Status Request
instructions_client_quote
Client quote instructions
letter_of_credit
Letter of credit
lm_bureau_endorsement
Bureau endorsement London Market
lm_claim_collection_form
LCCF London Claim Collection Form
lm_lpo_208
LPO 208 London Market
lm_premium_advice_note
London Premium advice note (LPAN)
loc_oca_acknowledgement
LOC/OCA Acknowledgment
loc_oca_draw_request
LOC/OCA Draw Request
loss_billing
Subsequent Proof of Loss
loss_billing_aggregate_deductible
Billing/Aggregate Deductible
loss_billing_attorney_recommendation
Attorney’s Billing Recommendation
loss_billing_cash_loss_advance
Cash Loss Advance Billing
loss_billing_declaratory_judgement
DJ - Declaratory Judgement Billing
loss_billing_excess_of_policy_limit
XPL – Ecess of Policy Limit Billing
loss_billing_extra_contractual_obligations
ECO - Extra Contractual Obligations Billing
loss_billing_final
Final Billing Proof of Loss
loss_billing_first_and_final
First/Final Billing
loss_billing_initial
Billing/Initial Proof of Loss
loss_billing_partial
Billing Partial Proof of Loss
loss_billing_salvage
Salvage Billing
loss_billing_subsequent
Billing/Subsequent
loss_billing_subsequent_aggregate_deductible
Billing/Subsequent/Aggregate Deductible
loss_non_billing_first_and_final_notice
First/Final Notice
loss_non_billing_initial_notice
Initial Notice
loss_non_billing_initial_notice_precautionary
Initial Notice – Precautionary
loss_non_billing_re_open_notice
Re-open Notice
loss_non_billing_reversal_notice
Reversal Notice
loss_non_billing_subsequent_precautionary
Subsequent Precautionary
plan
Plan
plan_building
Plan: Building
plan_maintenance
Plan: Maintenance
plan_product_recall
Plan: Product Recall
plan_project
Plan: Project
portfolio_split
Portfolio Split
portfolio_split_per_catastrophe_zone
Portfolio Split: per Catastrophe Zone
portfolio_split_per_geographical_zone
Portfolio Split: per Geographical Zone
questionnaire
Questionnaire
questionnaire_protection_devices
Questionnaire: Protection Devices
questionnaire_quality_control_procedures
Questionnaire: Quality Control Procedures
questionnaire_security_measures
Questionnaire: Security Measures
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 50 of 60
REPOSITORY
FOLDER
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Slip
Miscellaneous
Slip
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Slip
Slip
Slip
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Date: 09/03/07
ACORD LONGCODE
DESCRIPTION
reinsurance_contract_endorsement
Reinsurance contract endorsement
report
Report
REPOSITORY
FOLDER
reserve_status_supplemental_notice_no_change
Slip
Miscellaneous
Adjuster Report
Miscellaneous
Report: Balance Sheet
Miscellaneous
Contingent Liability Report
Miscellaneous
Report: Credit Rating
Miscellaneous
Report: Income Statement
Miscellaneous
Report: Inspection
Miscellaneous
Life Care Plans
Miscellaneous
Report: Medical
Miscellaneous
Report: Outstanding Loss
Miscellaneous
Passalongs
Miscellaneous
Portfolio report
Miscellaneous
Projected Medical Cost Reports
Miscellaneous
Report: Soil Analysis
Miscellaneous
Summary Report
Miscellaneous
Report: Survey
Miscellaneous
Surveyor Report
Miscellaneous
Reserve Change Notice
Miscellaneous
Initial Reserve
Miscellaneous
Initial Reserve - Aggregate Deductible
Miscellaneous
Status Supplemental Notice No Reserve Change Miscellaneous
reserve_subsequent
Subsequent Reserve
reserve_subsequent_aggregate_deductible
Subsequent Reserve - Aggregate Deductible
salvage_subrogation_notice
Salvage Notice
salvage_subrogation_refund_notification
Salvage/Subrogation Refund Notification
salvage_subrogation_request_for_payment
Salvage/Subrogation Request for Payment
schedule
Schedule
schedule_insurance_policy
Schedule: Insurance Policy
schedule_maintenance
Schedule: Maintenance
schedule_project
Schedule: Project
schedule_reinsurance_contract
Schedule: Reinsurance Contract
schedule_values
ACORD Statement/Schedule of values
statistics
Statistics
statistics_claim
Claim statistics
statistics_per_accounting_year
Statistics: per Accounting Year
statistics_per_underwriting_year
Statistics: per Underwriting Year
statistics_triangular
Statistics: Triangular
table_of_limits
Table of limits
wording
Wording
wording_addenda
Wording addenda
wording_agreed
Agreed wording
wording_construction_contract
Wording: Construction Contract
wording_insurance_policy
Wording: Insurance Policy
wording_maintenance_contract
Wording: Maintenance Contract
wording_reinsurance_contract
Wording: Reinsurance Contract
report_adjuster
report_balance_sheet
report_contingent_liability
report_credit_rating
report_income_statement
report_inspection
report_life_care_plans
report_medical
report_outstanding_loss
report_pass_alongs
report_portfolio
report_projected_medical_cost
report_soil_analysis
report_summary
report_survey
report_surveyor
reserve_change_notice
reserve_initial
reserve_initial_aggregate_deductible
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 51 of 60
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Slip
Policy
Miscellaneous
Miscellaneous
Policy
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Miscellaneous
Slip
Policy
Policy
Policy
Policy
Policy
Policy
Policy
Date: 09/03/07
17. APPENDIX F – DRI WORK ORDER COMPLETION
The following pages describe the completion of the Work Order for DRI submissions, which must
be presented in the form of an ACORD 2005.2 Technical Account.
Acord Tag/Element
XIS Required XIS Completion Notes
<Jv-Ins-Reinsurance Version="2005-2"
xmlns="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2005-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2005-2
Jv-Ins-Reinsurance-2005-2.xsd">
xmlns:ac="http://www.ACORD.org/Standards/AcordMsgSvc/1.4.0"
Mandatory
<TechAccount Sender="broker" Receiver="serviceprovider">
<UUId></UUId>
<BrokerReference>-</BrokerReference>
<CreationDate>-<CreationDate>
Mandatory
Mandatory
Mandatory
Mandatory
<AccountTransactionType>-</AccountTransactionType>
Mandatory
<Explanation>-</Explanation>
Optional
<Reinsurer>
<Party>
<Name>-</Name>
Conditonal
Conditonal
Conditonal
</Party>
</Reinsurer>
<Insurer>
<Party>
<Name>-</Name>
Conditonal
Conditonal
Conditonal
Conditonal
Conditonal
</Party>
<Insurer>
<Broker>
<Party>
<Id Agency="-">-</Id>
Conditonal
Conditonal
Mandatory
Mandatory
Mandatory
</Party>
<Contact>
<Description>-</Description>
<Telephone>-</Telephone>
<Email>-</Email>
</Contact>
</Broker>
<ServiceProvider>
<Party>
<Name>-</Name>
</Party>
<Contact>
<Description>-</Description>
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Optional
</Contact>
</ServiceProvider>
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Format: CCYY-MM-DDThh:mm:ss*hh:mm
One of 'premium', 'lm_additional_premium_ap' or
'lm_return_premium_rp'. For future use:
'lm_reinstatement_ap' 'lm_reinstatement_rp' 'lm_treaty_fdo'
'lm_treaty_statement_cr' and 'lm_treaty_statement_dr'
Optional text to provide any additional details or
requirements - e.g. reason for a correction
For reinsurance, used to distinguish between Lloyd's and
company market business. Either "Lloyd's", "Companies" or
"Mixed"
For insurance, used to distinguish between Lloyd's and
company market business. Either "Lloyd's", "Companies" or
"Mixed"
Agency must be 'lloyds'. Id will contain the Lloyd's broker
code
Broker technician name
Broker technician phone
Broker technician email
XIS
XIS technician name. Include for a re-submission following a
business rejection.
Optional
Optional
Page 52 of 60
Date: 09/03/07
<ReferenceCurrency>
<Ccy>-</Ccy>
</ReferenceCurrency>
<AmtShareIndicator>-</AmtShareIndicator>
<CorrectionIndicator>-</CorrectionIndicator>
Mandatory
Mandatory
Mandatory
Mandatory
Conditonal
<Contract>
<TreatyFac>-</TreatyFac>
Mandatory
Mandatory
<ContractNature>-</ContractNature>
Mandatory
<BrokerReference>-</BrokerReference>
</Contract>
<Subaccount>
<SequenceNbr>1-</SequenceNbr>
<ContractSection>
<HighLevelReference>1-</HighLevelReference>
<CoverType>-</CoverType>
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Conditonal
</ContractSection>
<JvClassOfBusiness>-</JvClassOfBusiness>
Mandatory
Mandatory
<ac:SupportingDocument>
<ac:DocumentId>-</ac:DocumentId>
Mandatory
Conditonal
<ac:DocumentReference>-</ac:DocumentReference>
<ac:DocumentVersion>-</ac:DocumentVersion>
<ac:DocumentTypeCd>-</ac:DocumentTypeCd>
</ac:SupportingDocument>
<TechAccountAmtItem Type="premium">
</TechAccountAmtItem>
</Subaccount>
<Paymentmeans>london_central_settlement</PaymentMeans>
</TechAccount>
</Jv-Ins-Reinsurance>
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Conditonal
Conditonal
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Use any currency code. This will be ignored.
Set to "receiver_share"
Conditional. Set to "replacement" for a re-submission
following a business rejection,
"reversal_to_be_replaced_later" or
"reversal_not_to_be_replaced" for a cancellation following
XIS signing, or "correction" for a correction following a
cancellation.
Applicable value from Acord code table A29. One of:
'treaty' 'facultative' or 'direct'
For Release 1 this will be limited to 'nonproportional' and
'excess_cession'. When proportional treaty business is
added as part of a subsequent release, then a value of
'proportional' will also be allowed.
UMR
Set to 1
Set to 1
Conditional. Set to 'lm_facility' when declaration from a
lineslip. Set to 'lm_balanced_binding_authority' where a
Binding Authority Account. Else exclude.
One of "aviation", "marine" or
"nonmarine_general_and_miscellaneous_liability"
At least one document must be referenced.
UUID of document. One of <DocumentId> or <Reference>
must be provided. Mutually exclusive with <Reference>.
Broker's reference to supporting information. One of
<DocumentId> or <Reference> must be provided. Mutually
exclusive with <DocumentId>.
Value from codeset A54
Always use this value. This element is not used in
construcutung the Work Order, but is a mandatory ACORD
element.
Always use this value. This element is not used in
construcutung the Work Order, but is a mandatory ACORD
element.
Mandatory
Mandatory
Page 53 of 60
Date: 09/03/07
18. APPENDIX G – DRI MESSAGE VALIDATION
DRI Validation
SOAP Level Validation
The following validation is carried out prior to the SOAP Post Response being returned to the sender. The
associated errors are therefore returned synchronously.
Validation
Is Xchanging meant
to be the receiver?
Are there any
attachments?
Is it a valid message
type?
Is the sender or
owner valid?
Is the third party valid
to send for the trading
partner?
Is business message
valid?
Does Business
Message match
SOAP message?
Do Soap and
business message
document counts
match?
Was SOAP body
signed with valid key?
Are all supporting
messages present?
Description
The receiver party ID for all messages
coming into XDH should have the PartyId of
'urn:duns:236196817'. This is held as a
registry setting on each of our servers
Each SOAP message should have at least
one attachment
Allowed values are 'Jv-Ins-Reinsurance' for
A&S and 'ACORD-Repository' for DRI (ECF)
messages
The sender PartyId & PartyRoleCd (Broker,
ServiceProvider etc) must be registered on
our tables for the message type (Upload,
Notify etc) that they are sending in.
If the sender PartyId is not valid, was it sent
by a ServiceProvider who are authorised to
send on behalf of the Owner of the
message?
Is the DRI message in a valid XML format?
The sender, receiver and owner party details
are duplicated in the SOAP and DRI
messages. They must be the same in both.
The amount of attachments that the SOAP
message and DRI message refer to must be
the same.
All incoming DRI messages have ACORD
minimal security applied which means that
they must have been signed with a valid
certificate. The public version of this
certificate needs to be registered on each
server.
Are all the messages referred to in the DRI
message present?
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 54 of 60
Error message
Incorrect receiver partyid
No attachments found
Invalid ApplicationCd supplied
Either the Owner or the Sender
is not a valid trading partner
The sender is not registered to
send on behalf of the owner
The business message was not
well formed XML
The business message (Sender
PartyId, Owner PartyRoleCd,
etc) differs from SOAP message
(Sender PartyId, Owner
PartyRoleCd, etc)
Soap message and business
message document counts do
not match
The soap message was not
signed with a valid certificate for
the partyid
The business message refers to
a document that has not been
received
Date: 09/03/07
Validation
Is the business
message namespace
the expected one?
Is the business MsgId
in the valid format?
Description
The namespace notified in the SOAP
message differs from the namespace of the
business message.
The MsgId is not a valid GUID in the
business message
Error message
The business message has a
different namespace than
expected
The MsgId is not a valid GUID
DRI Validation
Business Message level Validation
The following errors are carried out after the Post Response has been returned to the message sender.
Therefore, these errors are returned asynchronously in the DRI Upload Response.
All inbound messages go through the following validation
Validation
Is the Component
UUID unique?
Does the message
conform to the
ACORD Schema?
Description
Each DRI message that comes in must have
a unique MsgId.
Each DRI message must conform to the
ACORD schema.
Error message
Duplicate Component UUID
Schema validation
Additional validation that is specific to each message type is shown below.
Inward ACORD DRI NotifyRq
Validation
Is the aggregate of
the File Size fields too
great?
Description
If one document or the combination of all the
documents adds up to more than the
attachment size limit, reject.
Error message
Notified attachments exceed
size limit
Inward ACORD DRI DownloadRs
The following error is returned to the sender in the NotifyRs (Smart Notify scenario)
Validation
Does response
contain requested
documents?
Description
Each DRI download response message that
comes in we check that all documents in the
response match those requested in the
request.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 55 of 60
Error message
The DownloadRs refers to
different documents from the
DownloadRq
Date: 09/03/07
Inward ACORD DRI DownloadRq
Validation
Is one of the
Documents too large?
Is the aggregate of
the File Size fields too
great?
Description
If one documents attachment size is greater
than the limit, reject.
If the combination of all the documents adds
up to more than the attachment size limit,
reject.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 56 of 60
Error message
Aggregate message size
exceeded (by single document)
Aggregate message size
exceeded
Date: 09/03/07
19. APPENDIX H – CORRECTION FORM
Failure to complete this form may result in Xchanging being unable to process the correction fully.
CORRECTION REQUEST
Broker
Contact:
_______________________________________ Broker
No:
Broker
E-mail:
______________________________________
UMR
B
Correctiv
e Action
Required
_____________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Previous
Signing
History
(Please quote all original signing reference information i.e. OSND(s) to which the correction
relates)
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
Broker
Tele
No:
_______
Broker
Pseud:
_______
_________________________
Special Instructions: (Please indicate here any other additional information that could assist as
part of the corrections process)
Please Note:
Any additional entries that may require processing along with the correction(s) detailed above
should form part of the same Work Package/Work Order.
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 57 of 60
Date: 09/03/07
20. APPENDIX J – BROKER EPA SIGNINGS ADVICE (DL5089)
FILE STRUCTURE
There are 4 record types in the file:
RECORD
QUANTITY
NOTES
HEADER RECORD
1
THIS IS THE FIRST RECORD IN THE FILE.
COLUMN HEADER
1
THIS IS THE SECOND RECORD IN THE
RECORD
DATA RECORD
FILE.
MANY
THESE FOLLOW THE COLUMN HEADER
RECORD. THE FIRST FIELD OF EACH DATA
RECORD WILL BE THE GROUP IDENTIFIER.
FOOTER RECORD
1
THIS IS THE LAST RECORD IN THE FILE.
HEADER RECORD
Field Field Description
Field Value
No.
1
Record Identifier
‘HDR’
2
Report Number
‘DL5089’
3
Report Name
OSND Advice
4
Date of Work
e.g. DD/MM/CCYY
5
Sequence Number
XIS internal sequence number e.g. 1
6
Blank
blank
7
Recipient Email Address
Recipient Email Address(s)
8
File Created Date and Time
e.g. 29/06/2001 12:01
The following fields are added to the header record automatically by the software that creates
and sends the
e-mails:

Sequence Number
held and incremented for each Report Name/Despatch Group combination

Recipient Email Address
the email address to which, each individual email attachment is sent
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 58 of 60
Date: 09/03/07

File Created Date/Time
the date and time that the attachment was created
COLUMN HEADER RECORD
This record contains the text headings for the report columns.
Field No.
Field Value
1
‘GROUP IDENTIFIER’
2
‘BROKER CODE’
3
‘UNIQUE MARKET REF’
4
‘ORIG SIGNING NO. & DATE’
5
‘BUREAU’
6
‘DTI CODE’
7
‘RISK CODE’
8
‘COUNTRY’
9
‘FIL CODE’
10
‘ORIG CCY’
11
‘100% GROSS PREMIUM’
12
‘SIGNING STATUS’
13
‘SIGNING NO. & DATE’
14
‘ENTRY TYPE
15
‘BROKER CONTACT’
16
‘TREATY NO.’
DATA RECORD
Field No.
Field Description
1
Group Identifier
X(16)
2
Broker Number
X(04)
3
Unique Market Reference
X(17)
4
Original Signing Number & Date
X(15)
5
Bureau Identifier
X(02)
6
DTI Code
X(2)
7
Risk Code
X(4)
8
Country of Origin
X(02)
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Field Definition
Page 59 of 60
Date: 09/03/07
9
FIL Code
X(04)
10
Original Currency Code
X(03)
11
100% Gross Premium
Z(12)9.99
12
Signing Status Code
9(02)
13
Signing Number & Date
X(15)
14
Entry Type
X(03)
15
Broker Contact Name
X(15)
16
Treaty Number
X(09)
FOOTER RECORD
The footer record has the following format:
‘End Of Report – N Detail Lines.’
where N = number of data records in the file
DRI Customer pack – Version 8.2
Author – Graham Sheppard
Page 60 of 60
Date: 09/03/07