Project Genesis Data Capture Service Customer Requirements v1.7, January 2014
Change History Version Date Description 1.7 Jan 2014 Second published version to clarify BIPAR requirement, change service working hours to end at 17:30 GMT and note 98% service level in respect to 6 hour delivery of data output. 1.6 July 2013 First published version. Genesis Customer Requirements v1.7 Page 2 of 11
1. Background The London insurance market is continuing to modernise its business processes. In particular, major change to the market's core central processing services is being contemplated and significant developments are being explored regarding electronic support for the interaction between brokers and underwriters. We are seeing increasing use of electronic support for placing (and endorsements) by brokers. These developments create opportunities for insurers to derive benefit. However, many of these benefits cannot be realised at present due to deficiencies in the process and data, or the absence of certain process components or services. This Data Capture Service (DCS) lies at the heart of, and is the starting point for a package of measures to enable insurers to realise more of the potential benefits from this changing landscape. 2. Service Definition 2.1. Service Description The DCS will receive input of information in the form of an MRC and other documents supporting the placement of a risk (in a variety of formats such as scanned images, electronic documents, structured templates, ACORD data messages, etc) from insurers. It will turn this into rich structured ACORD standard data (based on a defined data set) to be made available to insurers' back-office systems in a timely fashion. The service will include the query and resolution of information and data items. DCS aims to achieve: the capture and transformation of information from a variety of input formats into ACORD structured data (or other agreed format) once on behalf of all insurers subscribing to an MRC (or for an insurer writing a risk 100%), the supplementary capture and transformation of any bespoke data items required by a particular subscribing insurer, a pre-defined data quality check once on behalf of all insurers subscribing to an MRC (or for an insurer writing a risk 100%), the clarification, through query and resolution, of data once on behalf of all insurers subscribing to an MRC, the creation of a central record of the captured data, including versions of this where changes have occurred. For risks which will be subsequently processed via insurers' central processing services (XIS), the DCS will be integrated with central processing through provision of the output data file to XIS. This aims to facilitate service improvements and efficiency gains in downstream processing and add to the benefits of a central service. However, such changes are beyond the scope of this service. The service will also be available for risks which will not be subsequently processed through central processing. The DCS will interact with a central document repository (anticipated to be the IMR) to store a copy of the contract documentation and the data set. Genesis Customer Requirements v1.7 Page 3 of 11
The DCS will be expected to utilise any existing data in order to maximise the efficiency of the capture service. For example, over time, data capture for risks which are renewals of previous contracts might draw down a previous data set from the central repository to avoid unnecessary rekeying. The service will provide a base off which to explore the introduction of other shared services such as data cleansing and single market submission of data to modelling services, Lloyd's reporting or capture of pre-bind data. However, these are aspirational and do not form part of this service definition. It is envisaged that further service and technology components might be developed to enhance the input information available to DCS, such as increased provision of ACORD information as opposed to scanned MRC images. However, as above, these are aspirational and do not form part of this service definition. The service must comply with UK and European competition law. In line with BIPAR s high level principles entitled Placement of a risk with multiple insurers, premium terms of the leader and any following insurers may differ. Where the premium terms on a DCS submission differ between the lead and / or any following insurers, then the service will ensure that those different terms will not be included on DCS output files sent to other parties subscribing to that risk. The intention is to position the DCS as an insurer-side service requiring no involvement by brokers. Where the DCS may inevitably have to interact with brokers (such as to deal with a query which cannot be answered by insurers) the intention is that this interaction will be no more than exists today. However, the intention is to use the DCS as a vehicle to minimise these interactions with brokers. In the example cited, DCS will be able to raise queries once with brokers on behalf of all insurers (rather than individual insurers raising separate queries) and DCS will first raise queries with insurers, rather than brokers, wherever possible. The DCS is viewed as a discrete service utilising an IT application layer that is not tightly integrated to, or dependent upon, the service provider's other IT applications and services. 2.2. Scope This document describes the end-state customer requirements of the DCS. Early implementation phases will be undertaken based on limited scope. Details of this implementation phasing and the scope of each phase are set out in Appendix A. The following is included in the scope of the DCS: New business and contract renewals at firm order Endorsements All Classes of Business Placement Type: All risks requiring individual signing through central processing e.g. open market, lineslip declarations requiring underwriter agreement, consortia placements, and binder contracts Both bureau and non-bureau business Both subscription and singleton risks, including vertical placements The following is excluded: Placement types: delegated authority arrangements where there is no single risklevel signing through central processing Document comparison capability Document collaboration capability. Genesis Customer Requirements v1.7 Page 4 of 11
It is envisaged that opportunities may exist to extend the DCS beyond the scope set out above, such as to capture data at quotation stage and from risk schedules. 2.3. Service Deliverables The service will deliver the following: Service Item A. Data output - delivery of a data file to: each insurer participating in the service and/or their BPO service provider central processing (XIS) B. Outwards queries - raise queries with insurer as necessary on information received in order to deliver service item A. C. Inwards queries - review queries received from insurer on data output; resolve query to insurer's satisfaction. D. Corrections - delivery of a replacement data file to each insurer participating in the service following provision of late data under service item B or an inwards query of data under item C above. E. Document load to repository - loading of insurer supplied MRC plus supporting documentation and structured output data Service Conditions Service Levels Input information from insurers to meet minimum entry criteria (see 'Inputs') The DCS is expected to make use of skilled resources who understand the structure of the MRC and the placement process. Insurer to respond within 9 Working Hours of receipt by them of the query. Quality - output data file to be in accordance with a data set defined from time to time (see Section 2.7 'Outputs') Accuracy - 98% of all data fields correct on first output Timing - 98% of all output files within 6 Working Hours of receipt of input information (see note below re Queries) Availability - receipt of input information from insurers and output of data files may occur at any time. (see Section 2.4 below re queries) Timing - within 6 Working Hours of receipt of input information Availability - receipt of inwards queries via portal at any time. Quality - output data file to be in accordance with a data set defined from time to time Accuracy - 100% of replaced data fields correct Timing - within 3 Working Hours of receipt of data under service item B or resolution of query under service item C Availability - output of data files may occur at any time. Accuracy - 100% of all MRCs and supporting documents and data files loaded correctly Timing - to be loaded to repository concurrently with dispatch of data to Genesis Customer Requirements v1.7 Page 5 of 11
in a document of the agreed format to a central document repository F. Support - manned helpdesk for service and data queries. customers. Availability - during Working Hours. Notes: Working Hours are defined as 09:00 to 17:30 GMT or BST as applicable. Where 'Availability' is noted as 'at any time', this recognises that the technology handling inputs and outputs is unlikely to be time dependent. Whilst not separately measurable, the provision of the service implies a requirement for the DCS service provider (the 'supplier') to make arrangements to receive data (see 'Inputs'), to capture data, to transform data, and arrangements for the transmission of data to recipients (see 'Outputs'). The details of how these aspects of service provision are handled should be available for review in order for customer representatives to satisfy themselves as to the efficiency and suitability of those arrangements. In particular, customers will wish to ensure that the service is independent of proprietary software and technology. Similarly, arrangements for the raising of queries with and receipt of queries from insurers should be available for review. The service is expected to cope with seasonal trends, such as the January renewal season in the London market. 2.4. Workflow and Query Management The service will provide transparency that enables customers to access information in respect of individual transactions as well as summaries of volumes and SLA measurement. The DCS will provide web service links to allow this information to be accessed from insurer' own workflow systems. A means of tracking individual transactions displaying current progression status will be available. Rules will be established and implemented so that alert emails are triggered where factors such as SLA targets are not met at individual transaction level. Outwards queries will be raised with the leading insurer through this mechanism if relating to the common set of risk data or with the relevant insurer for any bespoke data item. Although it may be necessary to raise a query with a broker, this should be the exception. The DCS supplier is expected to be proactive in raising and following up queries. The timing of the service from an SLA point of view will be halted whilst a query is underway. 2.5. Service Triggers and Progression The service will be triggered by receipt by the supplier of risk information from an insurer. The service will be available for risks written 100% by an insurer and in this case triggering the service, dealing with queries, and delivery of an output data file are conceptually simple. For subscription risks, the following process will be followed: Genesis Customer Requirements v1.7 Page 6 of 11
the first insurer on the slip which participates in the DCS (referred to above as the 'leading insurer' - although clearly this has a slightly different meaning to the traditional use of the term) will trigger the service by submitting an information set to the DCS data capture will commence and a data file will be delivered to the insurer within the defined service level any insurer subsequently writing a line will notify the service providing sufficient information to allow the DCS to identify the information set submitted by the leading insurer (e.g. UMR), plus information specific to that insurer (e.g. references) the capture of any bespoke data for any insurer, beyond the set of common risk data, will be captured concurrently with the common data set and a data file will be delivered to the insurer within a service level to be negotiated. Data Capture Service Process Flow Unstructured Information Capture, Analysis and Transformation Structured Data Carrier Enter skeleton entry in system to get references Assemble document package for DCS (MRC, front sheet, other) Yes No Respond to query Correction needed? Receive into Inbox Create/update risk record Receive into MMT Review & confirm record for use Receive into Inbox Receive query response Email Prepare query ACORD message Trigger workflow Close query Log query Assemble XML Log on to carrier system to update risk records Data Capture Service Search for UMR in database Unique UMR? No Associate with existing subscription record in database Yes Create new subscription record in database Yes Query? Quality control checks Extract information into structured data items (using OCR or Smart Forms or other technology) No No Manual carrier input needed? Load documents into central repository Pass data to Bureau Yes DCS DCS or BPO BPO Hand off to BPO 2.6. Inputs The input into the DCS will be provided by insurers as described above. It will be the responsibility of each insurer submitting input information to the service to ensure that the information set is complete (i.e. capable of generating the defined data output) according to their role as 'leader' or 'follower' in the service. For the leader, this must include the MRC and any relevant supporting documents. Each following insurer must provide sufficient information to allow the DCS to identify the information set submitted by the leading insurer (e.g. UMR), plus information specific to that insurer (e.g. references). Where input information is unclear or incomplete, the DCS will raise queries as necessary. Genesis Customer Requirements v1.7 Page 7 of 11
2.7. Outputs The output data file will have the following characteristics: it will contain the data elements defined in the 'DCS Data Requirements' document (as amended from time to time) that accompanies these requirements it will be compliant in all respects with the ACORD GLRC standard in use in the London market. The Data Requirements contain generic data fields common to all insurers and all classes of business as well as risk data common to all insurers but specific to certain classes (these class-specific data items may be out of scope for early implementation phases). The output data file will be provided to each insurer (and/or their nominated BPO) participating in the DCS which subscribes to the risk in question. It will be provided in the format requested by the insurer. The available formats are: an ACORD structured data message using the ACORD message a CSV format file an Excel spreadsheet The outputs may be sent individually or in bulk (batched) to the insurer according to their preference. An insurer might wish to use the DCS to enter data directly into their own systems. In this case, the insurer would not require an output file. This would be subject to separate negotiation and is beyond the scope of this service. The MRC plus supporting documentation and the structured output data in a document of the agreed format will be loaded to a central document repository. Ideally, this will be the IMR but this has not yet been determined or negotiated. 2.8. Support The supplier will provide reasonable assistance to an insurer which engages with the system including connection and testing. The supplier will provide a manned help desk to: act as the point of contact for insurers into the service provide help and assistance to insurers regarding the service provide a contact point for the handling of queries with insurers. Access to the help desk will be by designated telephone number or email address. 2.9. Charging Customer representatives will wish to have reasonable insight into the cost base underpinning the service to ensure fair pricing and fair remuneration of the supplier. Costs of the service, and the way these are charged, will be for the supplier to propose. However, the following should be considered: service costs should be shared between insurers participating in the service. Service charging could be based on the creation of the output data file. Alternatively, charging might be for the data capture and for the output message. However, other aspects of the service should be built into this single charging structure. i.e. there should not be a separate charge for queries, corrections, or support. the cost of the service for non-bureau insurers is to be included in the pricing model. Genesis Customer Requirements v1.7 Page 8 of 11
2.10. Metrics and Reporting The supplier will build a measurement and reporting regime sufficient to enable it to demonstrate compliance with service levels. Customer representatives will wish to review this regime and the resultant output. Genesis Customer Requirements v1.7 Page 9 of 11
Appendix A - Implementation Phasing and Scope Section 2.2 describes the end-state customer requirements of the DCS. Early implementation phases will be undertaken based on a limited scope and service delivery. Details of this implementation phasing and the scope of each phase are set out below. Scope Item Pilot Phase Post Pilot phase Future phases 1 New business and renewals at firm order In scope In scope In scope Endorsements Out of scope Out of scope In scope Quotations and pre-bind data Out of scope Out of scope In scope Classes of Business Risk data common to all insurers and all classes of business Class-specific data fields Classes to be agreed All classes All classes In scope In scope In scope Classes to be agreed All classes All classes Carrier-specific data fields Out of scope In scope but subject to separate negotiation if required Placement Type In scope 2 In scope 2 In scope 2 1 2 Bureau risks In scope In scope In scope Non-bureau risks In scope In scope In scope Subscription risks including vertical placements In scope In scope In scope Singleton risks In scope In scope In scope Volumes Up to 3000 MRCs during the pilot No limitation No limitation Risk Schedules Out of scope Out of scope In scope Future phases are subject to Xchanging and market agreement. Placement Type = All open market risks, lineslip declarations requiring underwriter agreement, consortia placements, excluding delegated authority arrangements where there is no single risklevel signing through central processing e.g. binder contracts. Service Item Pilot Phase Post pilot phase Future phases Data output to insurers In scope In scope In scope Document stored in repository In scope In scope In scope Queries In scope In scope In scope Corrections In scope In scope In scope Support In scope In scope In scope Genesis Customer Requirements v1.7 Page 10 of 11
1 Other Service Deliverables Pilot Phase Post pilot phase Future phases Data integration to bureau Out of scope In scope In scope processing 1 Billing Model In scope In scope In scope Customer Registration In scope In scope In scope Service Monitoring In scope In scope In scope Whilst this item is out of scope for the pilot phase, Xchanging will produce a design for integration of the DCS output with downstream central processing, for review by Genesis Steering Group and other stakeholders. Genesis Customer Requirements v1.7 Page 11 of 11