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