Get documents about "ACORD_DRI_Customer_Pack230307
Shared by: yaofenjin
-
Stats
- views:
- 27
- posted:
- 8/28/2011
- language:
- English
- pages:
- 60
Document Sample
ACORD DOCUMENT REPOSITORY INTERFACE
(DRI)
CUSTOMER USER GUIDE
Version 8.2
Revision Summary of Changes Changes
date marked
02/01/06 Version 1.0 – Initial implementation None
30/03/06 Version 2.0 – Broadened to cover broker EPA & Policy Submission. Yes
15/03/06 Version 3.0 – Broadened to cover carrier DRI Yes
31/03/06 Version 4.0 – Revisions Yes
14/04/06 Version 5.0 – Further revisions Yes
28/04/06 Version 6.0 – Further revisions Yes
19/05/06 Version 6.1 – Incorporating broker premium processing procedures Yes
20/06/06 Version 7.0 – Incorporating market feedback Yes
04/08/06 Version 7.1 – Incorporating MRPO feedback Yes
11/12/06 Version 8.0 – Revisions at December Release of A & S Yes
15/12/06 Version 8.1 – Version 8.0 incorporating feedback Yes
09/03/07 Version 8.2 – Amendments No
DRI Customer pack – Version 8.2 Page 1 of 60 Date: 09/03/07
Author – Graham Sheppard
Contents
1. Purpose of the document ..................................................................................................................... 4
2. Scope ................................................................................................................................................... 4
3. Background .......................................................................................................................................... 5
4. 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 Page 2 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 3 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 4 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 5 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 6 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Co-
ordinator, 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 Page 7 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 8 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 9 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 10 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 11 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 12 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 13 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 14 of 60 Date: 09/03/07
Author – Graham Sheppard
- 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 Page 15 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Co-
ordinator with an update to the status of the Issue / Problem
DRI Customer pack – Version 8.2 Page 16 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 17 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 18 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 19 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 20 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 21 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 22 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 23 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 24 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 25 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 26 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 27 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 28 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 29 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 30 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 31 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 32 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 33 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 34 of 60 Date: 09/03/07
Author – Graham Sheppard
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
Description ACORD Version
type
ACORD DRI Message Version:-
V1.2.0 (Y/N)
ACORD Messaging Service (AMS) Version:-
ACORD DRI V1.4.0 (Y/N)
UploadRq
Upload Request
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
ACORD DRI Message Version:-
V1.2.0 (Y/N)
ACORD Messaging Service (AMS) Version:-
ACORD DRI
NotifyRq
Notify Request V1.4.0 (Y/N)
…………………………………………………………………
Test URL _______________________________
Production URL _________________________
ACORD DRI Message Version:-
ACORD DRI
SearchRq
Search Request
V1.2.0 (Y/N)
DRI Customer pack – Version 8.2 Page 35 of 60 Date: 09/03/07
Author – Graham Sheppard
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
V1.4.0 (Y/N)
UploadRq Download
Request
Test URL:- _______________________________
Production URL:- __________________________
ACORD DRI Message Version:-
ACORD DRI V1.2.0 (Y/N)
NotifyRq
Notify Request
ACORD Messaging Service (AMS) Version:-
V1.4.0 (Y/N)
DRI Customer pack – Version 8.2 Page 36 of 60 Date: 09/03/07
Author – Graham Sheppard
…………………………………………………………………
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 Page 37 of 60 Date: 09/03/07
Author – Graham Sheppard
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:- / /
Production
Start Date of Digital Certificate:- / /
Expiry Date of Digital Certificate:- / /
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 Page 38 of 60 Date: 09/03/07
Author – Graham Sheppard
Mobile:- +44 (0)7917 423308
Facsimile:- +44 (0)1634 887510
DRI Customer pack – Version 8.2 Page 39 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 40 of 60 Date: 09/03/07
Author – Graham Sheppard
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) (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)
Premium FDO (For Declaration Only)
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)
AP / RP Premium Endorsement
Endorsement (showing underwriter authorisation) (M)
DRI Customer pack – Version 8.2 Page 41 of 60 Date: 09/03/07
Author – Graham Sheppard
Calculations/Supporting Information
LPAN(s) (M)
AP/RP Premium Adjustment
Endorsement (showing underwriter authorisation) (M)
Calculations/Supporting Information
LPAN(s) (M)
AP/RP Nil Adjustment
Endorsement (showing underwriter authorisation) (M)
Calculations/Supporting Information
LPAN(s) (M)
Non Premium Endorsement
Endorsement (showing underwriter authorisation) (M)
Risk Market Change
Endorsement (showing underwriter authorisation) (M)
Scanned/Imaged Slip Attachments
Calculations/Supporting Information.
LPAN(s) (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 Page 42 of 60 Date: 09/03/07
Author – Graham Sheppard
Lineslip
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)
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 Page 43 of 60 Date: 09/03/07
Author – Graham Sheppard
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: ___ No: Pseud:
Broker _______________________________________ Broker ________________________
E mail: ____ Tele No: __
UMR B
Class of ______ (M = Marine, N = Non-Marine, A = Aviation)
Business
Type of ______ (B = Binding Auth, D = Direct, F = Fac RI, X = Excess of Loss, L = Lineslip, P =
Contract Prop Tty)
Type of ______ (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 Page 44 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 45 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 46 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 47 of 60 Date: 09/03/07
Author – Graham Sheppard
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 REPOSITORY
FOLDER
acknowledgement Acknowledgement Miscellaneous
acknowledgement_first_notice_client First Notice Client Acknowledgement Miscellaneous
acknowledgement_inquiry_loss_market Market Inquiry Acknowledgement Miscellaneous
acknowledgement_loss_market Market Acknowledgement Miscellaneous
advice_claim_movement Claim movement advice
advice_claim_movement_seen Claim movement advice, seen
advice_commission Commission advice Miscellaneous
advice_deposit_premium Deposit Premium advice Miscellaneous
advice_premium Premium advice Miscellaneous
attorney_info_complaint Complaint Miscellaneous
attorney_info_correspondence Attorney Correspondence Miscellaneous
attorney_info_coverage_counsel_correspondence Coverage Counsel Correspondence Miscellaneous
attorney_info_defense_counsel_report Defense Counsel Report Miscellaneous
attorney_info_pleadings Pleadings Miscellaneous
attorney_related_info_trial_report Trial Report Miscellaneous
booklet Booklet Policy
booklet_insurance_policy Policy Policy
booklet_insurance_policy Booklet: Insurance Policy Policy
booklet_product Booklet: Product Policy
booklet_reinsurance_contract Booklet: Reinsurance Contract Policy
bordereau_catastrophe_report Catastrophe Report Miscellaneous
bordereau_line_of_business_detail Line of Business Detail US general classification Miscellaneous
breakdown
bordereau_outstanding_loss_and_loss_adjustment_expens Outstanding Loss and Loss Adjustment Expense Miscellaneous
e_reserve (LAE) Reserve Bordereau
bordereau_paid_loss_and_lae_and_outstanding_loss_and_l Paid Loss and LAE and Outstanding Loss and Miscellaneous
ae_reserve LAE Reserve Bordereau
bordereau_paid_loss_and_loss_adjustment_expense Paid Loss and Loss Adjustment Expense (LAE) Miscellaneous
Bordereau
bordereau_premium Premium Bordereau Miscellaneous
bordereau_premium_and_loss Premium and Loss Bordereau Miscellaneous
bordereau_unearned_premium Unearned Premium Bordereau Miscellaneous
calculation Calculation Miscellaneous
calculation_adjustment_premium Adjustment Premium calculation Miscellaneous
calculation_aggregate_deductible Aggregate deductible calculation Miscellaneous
calculation_claim_reserve Claim Reserve calculation Miscellaneous
calculation_experience_adjustment Experience Adjustment Calculation Miscellaneous
calculation_manual Miscellaneous
calculation_profit_commission Profit Commission calculation Miscellaneous
calculation_reinstatement Reinstatement calculation Miscellaneous
calculation_reinstatement_premium Reinstatement premium calculation Miscellaneous
calculation_term_adjustment Term Adjustment Calculation Miscellaneous
DRI Customer pack – Version 8.2 Page 48 of 60 Date: 09/03/07
Author – Graham Sheppard
ACORD LONGCODE DESCRIPTION REPOSITORY
FOLDER
claim_close_aggregate_deductible Claim Close Aggregate Deductible Miscellaneous
claim_close_notice Claim Closing Notice Miscellaneous
correspondence_bank Bank Correspondence Miscellaneous
correspondence_claim Claim, correspondence Miscellaneous
correspondence_client Client Correspondence Miscellaneous
correspondence_cobroker Co-broker correspondence Miscellaneous
correspondence_general_cedent General Correspondence Cedent Miscellaneous
correspondence_general_reinsurer General Correspondence Reinsurer Miscellaneous
correspondence_premium Premium Correspondence Miscellaneous
correspondence_previous_documentation Previous Documentation Miscellaneous
correspondence_reinstatement_of_premium Reinstatement of Premium Miscellaneous
correspondence_reinsurer_status_update Reinsurer Status Update Miscellaneous
correspondence_settlement_documentation Settlement Documentation Miscellaneous
correspondence_underwriter Underwriter correspondence Miscellaneous
document Other Documentation Miscellaneous
document Document Miscellaneous
document_account_information General Account Information Miscellaneous
document_binder Document: Binder Policy
document_broker_account Broker Account Miscellaneous
document_broker_invoice Broker invoice Miscellaneous
document_certificate Document: Certificate Policy
document_claims_paid_breakdown Claims paid breakdown Miscellaneous
document_company_closing Company closing Miscellaneous
document_cover_note Document: Cover Note Miscellaneous
document_cover_note_addenda Document: Cover Note Addenda Miscellaneous
document_file_note File note document Miscellaneous
document_information_sheet Information Sheet Miscellaneous
document_market_presentation Market Presentation Miscellaneous
document_operations_description Description of Operations Miscellaneous
document_photographs Photographs Miscellaneous
document_placing_endorsement_agreed Agreed Placing Endorsement Slip
document_placing_endorsement_signed Signed placing endorsement Slip
document_placing_slip Placing Slip Slip
document_placing_slip_agreed Agreed Placing Slip Slip
document_placing_slip_signed Signed placing slip Slip
document_reservation_of_rights Reservation of Rights Miscellaneous
document_slip Document: Slip Slip
document_various_loss_breakdown Document various loss breakdown Miscellaneous
document_void Void Miscellaneous
form Form Miscellaneous
form_declaration Form: Declaration Policy
form_insurance_policy Form: Insurance Policy Policy
form_insurance_policy_endorsement Insurance policy endorsement form Policy
form_policy_control Policy Control Form Miscellaneous
form_quotation_request Form: Quotation Request Miscellaneous
form_reinsurance_contract Form: Reinsurance Contract Policy
form_statutory_declaration Form: Statutory declaration Policy
form_work_order Work Order Miscellaneous
DRI Customer pack – Version 8.2 Page 49 of 60 Date: 09/03/07
Author – Graham Sheppard
ACORD LONGCODE DESCRIPTION REPOSITORY
FOLDER
inquiry_collection Collection Inquiry Miscellaneous
inquiry_loss_client Claim Inquiry Client Miscellaneous
inquiry_loss_market Inquiry Miscellaneous
inquiry_loss_response Inquiry Response Miscellaneous
inquiry_specific_request_reinsurer Reinsurer – Specific Request Miscellaneous
inquiry_status_request_reinsurer Reinsurer Status Request Miscellaneous
instructions_client_quote Client quote instructions Miscellaneous
letter_of_credit Letter of credit Miscellaneous
lm_bureau_endorsement Bureau endorsement London Market Slip
lm_claim_collection_form LCCF London Claim Collection Form Miscellaneous
lm_lpo_208 LPO 208 London Market Slip
lm_premium_advice_note London Premium advice note (LPAN) Miscellaneous
loc_oca_acknowledgement LOC/OCA Acknowledgment Miscellaneous
loc_oca_draw_request LOC/OCA Draw Request Miscellaneous
loss_billing Subsequent Proof of Loss Miscellaneous
loss_billing_aggregate_deductible Billing/Aggregate Deductible Miscellaneous
loss_billing_attorney_recommendation Attorney‟s Billing Recommendation Miscellaneous
loss_billing_cash_loss_advance Cash Loss Advance Billing Miscellaneous
loss_billing_declaratory_judgement DJ - Declaratory Judgement Billing Miscellaneous
loss_billing_excess_of_policy_limit XPL – Ecess of Policy Limit Billing Miscellaneous
loss_billing_extra_contractual_obligations ECO - Extra Contractual Obligations Billing Miscellaneous
loss_billing_final Final Billing Proof of Loss Miscellaneous
loss_billing_first_and_final First/Final Billing Miscellaneous
loss_billing_initial Billing/Initial Proof of Loss Miscellaneous
loss_billing_partial Billing Partial Proof of Loss Miscellaneous
loss_billing_salvage Salvage Billing Miscellaneous
loss_billing_subsequent Billing/Subsequent Miscellaneous
loss_billing_subsequent_aggregate_deductible Billing/Subsequent/Aggregate Deductible Miscellaneous
loss_non_billing_first_and_final_notice First/Final Notice Miscellaneous
loss_non_billing_initial_notice Initial Notice Miscellaneous
loss_non_billing_initial_notice_precautionary Initial Notice – Precautionary Miscellaneous
loss_non_billing_re_open_notice Re-open Notice Miscellaneous
loss_non_billing_reversal_notice Reversal Notice Miscellaneous
loss_non_billing_subsequent_precautionary Subsequent Precautionary Miscellaneous
plan Plan Miscellaneous
plan_building Plan: Building Miscellaneous
plan_maintenance Plan: Maintenance Miscellaneous
plan_product_recall Plan: Product Recall Miscellaneous
plan_project Plan: Project Miscellaneous
portfolio_split Portfolio Split Slip
portfolio_split_per_catastrophe_zone Portfolio Split: per Catastrophe Zone Slip
portfolio_split_per_geographical_zone Portfolio Split: per Geographical Zone Slip
questionnaire Questionnaire Miscellaneous
questionnaire_protection_devices Questionnaire: Protection Devices Miscellaneous
questionnaire_quality_control_procedures Questionnaire: Quality Control Procedures Miscellaneous
questionnaire_security_measures Questionnaire: Security Measures Miscellaneous
DRI Customer pack – Version 8.2 Page 50 of 60 Date: 09/03/07
Author – Graham Sheppard
ACORD LONGCODE DESCRIPTION REPOSITORY
FOLDER
reinsurance_contract_endorsement Reinsurance contract endorsement Slip
report Report Miscellaneous
report_adjuster Adjuster Report Miscellaneous
report_balance_sheet Report: Balance Sheet Miscellaneous
report_contingent_liability Contingent Liability Report Miscellaneous
report_credit_rating Report: Credit Rating Miscellaneous
report_income_statement Report: Income Statement Miscellaneous
report_inspection Report: Inspection Miscellaneous
report_life_care_plans Life Care Plans Miscellaneous
report_medical Report: Medical Miscellaneous
report_outstanding_loss Report: Outstanding Loss Miscellaneous
report_pass_alongs Passalongs Miscellaneous
report_portfolio Portfolio report Miscellaneous
report_projected_medical_cost Projected Medical Cost Reports Miscellaneous
report_soil_analysis Report: Soil Analysis Miscellaneous
report_summary Summary Report Miscellaneous
report_survey Report: Survey Miscellaneous
report_surveyor Surveyor Report Miscellaneous
reserve_change_notice Reserve Change Notice Miscellaneous
reserve_initial Initial Reserve Miscellaneous
reserve_initial_aggregate_deductible Initial Reserve - Aggregate Deductible Miscellaneous
reserve_status_supplemental_notice_no_change Status Supplemental Notice No Reserve Change Miscellaneous
reserve_subsequent Subsequent Reserve Miscellaneous
reserve_subsequent_aggregate_deductible Subsequent Reserve - Aggregate Deductible Miscellaneous
salvage_subrogation_notice Salvage Notice Miscellaneous
salvage_subrogation_refund_notification Salvage/Subrogation Refund Notification Miscellaneous
salvage_subrogation_request_for_payment Salvage/Subrogation Request for Payment Miscellaneous
schedule Schedule Slip
schedule_insurance_policy Schedule: Insurance Policy Policy
schedule_maintenance Schedule: Maintenance Miscellaneous
schedule_project Schedule: Project Miscellaneous
schedule_reinsurance_contract Schedule: Reinsurance Contract Policy
schedule_values ACORD Statement/Schedule of values Miscellaneous
statistics Statistics Miscellaneous
statistics_claim Claim statistics Miscellaneous
statistics_per_accounting_year Statistics: per Accounting Year Miscellaneous
statistics_per_underwriting_year Statistics: per Underwriting Year Miscellaneous
statistics_triangular Statistics: Triangular Miscellaneous
table_of_limits Table of limits Slip
wording Wording Policy
wording_addenda Wording addenda Policy
wording_agreed Agreed wording Policy
wording_construction_contract Wording: Construction Contract Policy
wording_insurance_policy Wording: Insurance Policy Policy
wording_maintenance_contract Wording: Maintenance Contract Policy
wording_reinsurance_contract Wording: Reinsurance Contract Policy
DRI Customer pack – Version 8.2 Page 51 of 60 Date: 09/03/07
Author – Graham Sheppard
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" Mandatory
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"
<TechAccount Sender="broker" Receiver="serviceprovider"> Mandatory
<UUId></UUId> Mandatory
<BrokerReference>-</BrokerReference> Mandatory
<CreationDate>-<CreationDate> Mandatory Format: CCYY-MM-DDThh:mm:ss*hh:mm
<AccountTransactionType>-</AccountTransactionType> Mandatory 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'
<Explanation>-</Explanation> Optional Optional text to provide any additional details or
requirements - e.g. reason for a correction
<Reinsurer> Conditonal
<Party> Conditonal
<Name>-</Name> Conditonal For reinsurance, used to distinguish between Lloyd's and
company market business. Either "Lloyd's", "Companies" or
"Mixed"
</Party> Conditonal
</Reinsurer> Conditonal
<Insurer> Conditonal
<Party> Conditonal
<Name>-</Name> Conditonal For insurance, used to distinguish between Lloyd's and
company market business. Either "Lloyd's", "Companies" or
"Mixed"
</Party> Conditonal
<Insurer> Conditonal
<Broker> Mandatory
<Party> Mandatory
<Id Agency="-">-</Id> Mandatory Agency must be 'lloyds'. Id will contain the Lloyd's broker
code
</Party> Mandatory
<Contact> Mandatory
<Description>-</Description> Mandatory Broker technician name
<Telephone>-</Telephone> Mandatory Broker technician phone
<Email>-</Email> Mandatory Broker technician email
</Contact> Mandatory
</Broker> Mandatory
<ServiceProvider> Mandatory
<Party> Mandatory
<Name>-</Name> Mandatory XIS
</Party> Mandatory
<Contact> Optional
<Description>-</Description> Optional XIS technician name. Include for a re-submission following a
business rejection.
</Contact> Optional
</ServiceProvider> Optional
DRI Customer pack – Version 8.2 Page 52 of 60 Date: 09/03/07
Author – Graham Sheppard
<ReferenceCurrency> Mandatory
<Ccy>-</Ccy> Mandatory Use any currency code. This will be ignored.
</ReferenceCurrency> Mandatory
<AmtShareIndicator>-</AmtShareIndicator> Mandatory Set to "receiver_share"
<CorrectionIndicator>-</CorrectionIndicator> Conditonal 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.
<Contract> Mandatory
<TreatyFac>-</TreatyFac> Mandatory Applicable value from Acord code table A29. One of:
'treaty' 'facultative' or 'direct'
<ContractNature>-</ContractNature> Mandatory 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.
<BrokerReference>-</BrokerReference> Mandatory UMR
</Contract> Mandatory
<Subaccount> Mandatory
<SequenceNbr>1-</SequenceNbr> Mandatory Set to 1
<ContractSection> Mandatory
<HighLevelReference>1-</HighLevelReference> Mandatory Set to 1
<CoverType>-</CoverType> Conditonal Conditional. Set to 'lm_facility' when declaration from a
lineslip. Set to 'lm_balanced_binding_authority' where a
Binding Authority Account. Else exclude.
</ContractSection> Mandatory
<JvClassOfBusiness>-</JvClassOfBusiness> Mandatory One of "aviation", "marine" or
"nonmarine_general_and_miscellaneous_liability"
<ac:SupportingDocument> Mandatory At least one document must be referenced.
<ac:DocumentId>-</ac:DocumentId> Conditonal UUID of document. One of <DocumentId> or <Reference>
must be provided. Mutually exclusive with <Reference>.
<ac:DocumentReference>-</ac:DocumentReference> Conditonal Broker's reference to supporting information. One of
<DocumentId> or <Reference> must be provided. Mutually
exclusive with <DocumentId>.
<ac:DocumentVersion>-</ac:DocumentVersion> Conditonal
<ac:DocumentTypeCd>-</ac:DocumentTypeCd> Mandatory Value from codeset A54
</ac:SupportingDocument> Mandatory
<TechAccountAmtItem Type="premium"> Mandatory Always use this value. This element is not used in
construcutung the Work Order, but is a mandatory ACORD
element.
</TechAccountAmtItem> Mandatory
</Subaccount> Mandatory
<Paymentmeans>london_central_settlement</PaymentMeans> Mandatory Always use this value. This element is not used in
construcutung the Work Order, but is a mandatory ACORD
element.
</TechAccount> Mandatory
</Jv-Ins-Reinsurance> Mandatory
DRI Customer pack – Version 8.2 Page 53 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Description Error message
Is Xchanging meant The receiver party ID for all messages Incorrect receiver partyid
to be the receiver? coming into XDH should have the PartyId of
'urn:duns:236196817'. This is held as a
registry setting on each of our servers
Are there any Each SOAP message should have at least No attachments found
attachments? one attachment
Is it a valid message Allowed values are 'Jv-Ins-Reinsurance' for Invalid ApplicationCd supplied
type? A&S and 'ACORD-Repository' for DRI (ECF)
messages
Is the sender or The sender PartyId & PartyRoleCd (Broker, Either the Owner or the Sender
owner valid? ServiceProvider etc) must be registered on is not a valid trading partner
our tables for the message type (Upload,
Notify etc) that they are sending in.
Is the third party valid If the sender PartyId is not valid, was it sent The sender is not registered to
to send for the trading by a ServiceProvider who are authorised to send on behalf of the owner
partner? send on behalf of the Owner of the
message?
Is business message Is the DRI message in a valid XML format? The business message was not
valid? well formed XML
Does Business The sender, receiver and owner party details The business message (Sender
Message match are duplicated in the SOAP and DRI PartyId, Owner PartyRoleCd,
SOAP message? messages. They must be the same in both. etc) differs from SOAP message
(Sender PartyId, Owner
PartyRoleCd, etc)
Do Soap and The amount of attachments that the SOAP Soap message and business
business message message and DRI message refer to must be message document counts do
document counts the same. not match
match?
Was SOAP body All incoming DRI messages have ACORD The soap message was not
signed with valid key? minimal security applied which means that signed with a valid certificate for
they must have been signed with a valid the partyid
certificate. The public version of this
certificate needs to be registered on each
server.
Are all supporting Are all the messages referred to in the DRI The business message refers to
messages present? message present? a document that has not been
received
DRI Customer pack – Version 8.2 Page 54 of 60 Date: 09/03/07
Author – Graham Sheppard
Validation Description Error message
Is the business The namespace notified in the SOAP The business message has a
message namespace message differs from the namespace of the different namespace than
the expected one? business message. expected
Is the business MsgId The MsgId is not a valid GUID in the The MsgId is not a valid GUID
in the valid format? business message
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 Description Error message
Is the Component Each DRI message that comes in must have Duplicate Component UUID
UUID unique? a unique MsgId.
Does the message Each DRI message must conform to the Schema validation
conform to the ACORD schema.
ACORD Schema?
Additional validation that is specific to each message type is shown below.
Inward ACORD DRI NotifyRq
Validation Description Error message
Is the aggregate of If one document or the combination of all the Notified attachments exceed
the File Size fields too documents adds up to more than the size limit
great? attachment size limit, reject.
Inward ACORD DRI DownloadRs
The following error is returned to the sender in the NotifyRs (Smart Notify scenario)
Validation Description Error message
Does response Each DRI download response message that The DownloadRs refers to
contain requested comes in we check that all documents in the different documents from the
documents? response match those requested in the DownloadRq
request.
DRI Customer pack – Version 8.2 Page 55 of 60 Date: 09/03/07
Author – Graham Sheppard
Inward ACORD DRI DownloadRq
Validation Description Error message
Is one of the If one documents attachment size is greater Aggregate message size
Documents too large? than the limit, reject. exceeded (by single document)
Is the aggregate of If the combination of all the documents adds Aggregate message size
the File Size fields too up to more than the attachment size limit, exceeded
great? reject.
DRI Customer pack – Version 8.2 Page 56 of 60 Date: 09/03/07
Author – Graham Sheppard
19. APPENDIX H – CORRECTION FORM
Failure to complete this form may result in Xchanging being unable to process the correction fully.
CORRECTION REQUEST
Broker _______________________________________ Broker _______ Broker _______
Contact: No: Pseud:
Broker ______________________________________ Broker _________________________
E-mail: Tele
No:
UMR B
Correctiv _____________________________________________________________________
e Action ________________________________________________________________________
Required ________________________________________________________________________
Previous (Please quote all original signing reference information i.e. OSND(s) to which the correction
Signing relates)
History _________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
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 Page 57 of 60 Date: 09/03/07
Author – Graham Sheppard
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 FILE.
DATA RECORD 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 Page 58 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Field Definition
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 Page 59 of 60 Date: 09/03/07
Author – Graham Sheppard
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 Page 60 of 60 Date: 09/03/07
Author – Graham Sheppard
