Project Genesis Data Capture Service. Pilot Evaluation Report

Transcription

1 Project Genesis Data Capture Service Pilot Evaluation Report V1.0, September 2014

2 Contents 1. Executive Summary Introduction Pilot Purpose, Scope and Operation Purpose Scope Operation Participation in the Pilot Journey through the Pilot Evaluation of the Pilot hodology Delivery against Objectives Delivery Against Scope Market Feedback and Other Considerations Summary and Conclusions Recommendations and Next Steps Appendix A: Objectives, CSFs, KPIs and commentary Appendix B: Functional Requirements Appendix C: Insurers Checklist Appendix D: Provisional Development Roadmap Appendix E: Xchanging statement on scalability Document History Version Amendments 0.1 First draft 0.2 RG edits: circulated to selected market individuals for review. 0.3 Incorporating comments from selected market individuals and further input from LMA team. To Steering Group for review. 0.4 Following review by DCS Steering Group 1.0 Following DCS Steering Group sign-off DCS Pilot Evaluation Report v1.0 Page 2 of 30

3 1. Executive Summary Headlines The phase of the Data Capture Service (DCS) has confirmed that the service is fit-forpurpose and suitable for further development. Key lessons learnt were: Xchanging have demonstrated their capability to deliver data to quality and timeliness service levels DCS offers immediate benefit to some insurers but a number of enhancements and dependencies need to be addressed for benefits to be maximised for the majority of insurers These are more closely aligning the DCS output with the totality of insurers data requirements and insurers developing their ability to auto-submit to DCS and to automatically integrate DCS data into underwriting systems Due mainly to this dependency on system changes, the adoption of DCS by insurers is likely to be a more prolonged affair than had been originally anticipated Valuable progress has been made to evolve the definition of a risk data set which has wider implications for electronic placing, exposure data work, and binder risk reporting. During the course of the it became increasingly apparent that the adoption picture will be influenced by the data capture requirements of CSRP (which have yet to mature) and the need to align services to meet both CSRP s and insurers needs. This report makes several recommendations designed to drive the future development and adoption of DCS. Summary DCS is an outsourced, shared service which takes input from insurers of MRC information and turns it into structured ACORD data available to insurers back-office systems and to core central processes. The service captures and transforms information once on behalf of all insurers subscribing to an MRC and provides them collectively with a pre-defined data quality check and clarifies data through query and resolution. Xchanging were selected as the service provider and with the project s Steering Group launched DCS in January DCS commenced with a six-month controlled evaluation and ramp-up which was termed the phase the purpose of which was to solidify market buy-in and confidence in the service, by demonstrating delivery of customer requirements and service levels, and to gain experience of data capture as a shared service and to evolve the market s data requirements. Eighteen insurers participated in the which processed approximately 1,691 MRCs. Although this fell short of the planned levels the Steering Group concluded that volumes were adequate to evaluate the service. The achieved its stated objectives and showed that a centralised risk data capture service is feasible and attractive to insurers. Xchanging has shown that it is capable of delivering to the required service levels. The Steering Group with Xchanging and individual firms have developed a body of knowledge concerning the operation of the service, the processes which support it, the data, and the benefits which are available to insurers. This enables the market to move forward in enhancing the service. The DCS Pilot Evaluation Report v1.0 Page 3 of 30

4 strategic importance of early risk data capture in a future central processing model has been recognised. It was found that whilst DCS offers immediate benefit to some insurers, a number of enhancements and dependencies need to be addressed for benefits to be maximised for the majority of insurers. These are more closely aligning the DCS output with the totality of insurers data requirements and insurers developing their ability to auto-submit to DCS and to automatically integrate DCS data into underwriting systems. Due mainly to this dependency on system changes, the adoption of DCS by insurers is likely to be a more prolonged affair than had been originally anticipated. Also, the adoption picture will be influenced by the data capture requirements of CSRP (which have yet to mature) and the need to align services to meet both CSRP s and insurers needs. DCS was established as a service under managing agents and company insurers XIS service agreements which provide an efficient mechanism for building, enhancing and managing a shared service. However, the requirement for supplementary agreements dealing with TUPE and TMEL create a cumbersome contractual structure which some insurers have struggled with and requires further work. Through this report, the Steering Group confirms that the Data Capture Service provided by Xchanging is fit-for-purpose and suitable for further development. A number of recommendations are made including that: a roadmap be developed setting out future development for agreement by MPC and PEG; work continue to encourage insurers and system suppliers to develop and implement integration with systems; formal alignment be sought with CSRP s structured risk data capture service; alignment to be sought with the market s initiatives to support placing; the Steering Group to continue to engage with London market insurers to promote DCS. management of the DCS remains with the DCS Steering Group and its sub-groups. 2. Introduction The DCS has been designed as an outsourced, elective, shared service available to bureau or non-bureau insurer customers. DCS undertakes: the capture and transformation of risk information provided by insurers in a variety of input formats into ACORD structured data 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 (i.e. against the market s defined data definition) 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. DCS Pilot Evaluation Report v1.0 Page 4 of 30

5 Precise data on the number of MRC s placed in the London market is difficult to obtain but the project s working assumption (based on various data sources) was that, for 2012, there were 120,000 MRCs processed through Xchanging with an average of between 3 to 4 insurers subscribing to each MRC. Of course, DCS is not limited to bureau processed business. After evaluating the supplier marketplace the project s Steering Group selected Xchanging to provide the DCS. It was decided to undertake a controlled ramp-up of the service which was termed the phase. Pre- work included the definition, through a market group, of the initial data set to be captured by DCS, establishment of a contractual framework for insurers to engage with DCS, establishment of governance, project management and reporting mechanisms, and agreement of issues management and change control procedures. This report refers to the project document set available from the LMA website: DCS Systems Process and Procedures manual* Here Benefits statement v0.6 Here Insurer implementation options and related benefits v0.4 final Here [* Incorporating Data requirements specification, Data requirements details and Workflow requirements specification, previously published as separate documents.] 3. Pilot Purpose, Scope and Operation 3.1. Purpose The purpose of the was to solidify market buy-in and confidence in the service by demonstrating delivery of customer requirements and service levels. Pilot activity enabled the Steering Group to determine whether certain success criteria had been met and, thus, whether the objectives of the had been achieved. The desired outcome was: Well-developed technical, managerial, and production procedures Additional ideas for system development Evidence that validated or refuted benefits realized from implementing a DCS Confirmation that the objectives (shown in section 5.1) had been met An evaluation of the market s collective data requirements, as set out in the data specification, and experience on which to base the evolution of these. For some firms, this meant confirming the viability of a concept which they intuitively felt presented an opportunity to improve the efficiency of their own and the market s processes; for others, less involved in the early development of the original concept, it was an opportunity to gain an understanding of the possibilities presented by central data capture. DCS Pilot Evaluation Report v1.0 Page 5 of 30

6 3.2. Scope The scope of the included: New business and renewals All classes of business All contract types except Treaty Reinsurance contracts Both Bureau and non-bureau risks Subscription risks, singletons (100% placements), and vertical placements Document load to repository Query management Customer registration Service monitoring. The following were not included in the : Quotes and Endorsements Binder Declarations Risk Schedules Insurer-specific (bespoke) data Data integration to bureau processing Operation The commenced on 27 January 2014 for a planned six month period. Due to further unexpected work on the service s contractual arrangements, this period was extended by one month making the evaluation date 27 August. Although termed a, the service provided by Xchanging was and remains live and did not cease at the end of this phase. At the start of the daily submission volumes and in scope classes of business and MRC types were agreed with Xchanging to ensure that the live process was validated prior to being exposed to significant volumes. These restrictions were relaxed as confidence grew in the process and in Xchanging s ability to deliver quality and timely output. The exercised the following aspects of the process, as described more fully in the documentation: Insurer input to DCS Input query handling and management Data output from DCS Error handling and management. Another important role of the was to road-test the output data set and data rules in order to arrive at a position which met the collective expectations of DCS customers. The proved to be effective in this role although this process will continue under market governance as the service is exposed to further classes and business types. A change control process operated by Xchanging with escalation to the Steering Group was employed to manage changes to the defined process and where this impacted the service documentation this was reissued via the LMA website. Finally, experience gained during the has been used to develop a suite of reports to monitor performance. DCS Pilot Evaluation Report v1.0 Page 6 of 30

7 4. Participation in the Pilot Eighteen insurers participated in the with the majority involved across most of the seven month period. Eleven insurers used ACORD messaging - ten on a peer-to-peer basis and one via The Message Exchange (TMEL) - and seven used to submit MRCs to the service. The majority of participants were Lloyd s managing agents although nine of those agencies also have cross-market entities. The Steering Group felt this was a good level of participation and did not see the focus on managing agents as problematic as the DCS process is agnostic as to Lloyd s or company insurer and as regards subsequent bureau or non-bureau processing. It was anticipated that approximately 3,000 MRCs would be processed over the duration of the. By the end of the 1,691 MRCs had been processed (see section 6.2 for more analysis) but, despite this shortfall, the Steering Group concluded that volumes were adequate to evaluate the service. 5. Journey through the Pilot Based on customer specifications created during Q Xchanging completed analysis, design and build of the service. Market Acceptance Testing over December and January led into the start of the live at the end of January A requirement arose from TMEL, immediately prior to commencing the, for Xchanging to sign a contract to allow DCS messages to be transmitted across The Exchange. This issue did not surface during testing with TMEL and had a number of consequences. Firstly, considerable activity was required by Xchanging and insurers to switch to peer-to-peer messaging, redo testing, and re-establish connection into the live system. This proved difficult for some insurers (emphasising the value of TMEL). Some insurers opted to use to connect to the service. Secondly, it became necessary for Xchanging to issue supplementary conditions for signature by customers wishing to use TMEL. Both these issues delayed submissions to DCS and the was subsequently extended by one month as a result. Issues also arose in relation to transactions passing between insurers, gateway providers and Xchanging due to initial failed transactions. However, work has been undertaken to ensure seamless operation between all parties and this continues to be an area that is closely monitored. MRC submission volumes picked up over time. Atrium was first out of the blocks, processing the first message in January They were quickly followed by Ascot and Navigators in February and by Antares, Ark, Beazley, Canopius, Catlin, Channel and Hiscox in March. In the end sixteen insurers processed live MRCs through the service. The initial classes of business were Property, Terrorism and selected parts of Marine and Casualty. These were captured accurately and efficiently by Xchanging in the first few months and the service was soon able to move on to more complex classes without issue. The majority of insurers were comfortable that data capture was broadly fit for purpose across all classes and the steady increase in usage was matched by Xchanging training more technicians to meet demand. From the outset, Xchanging s data capture specialists demonstrated a level of expertise and understanding of the market that was beyond expectation. DCS Pilot Evaluation Report v1.0 Page 7 of 30

8 A full issues list was maintained throughout the so that problems raised were logged and actioned. It became clear early on that the market s data requirements specification required the service to capture large amounts of text for several data items but that insurers could not make use of this in an unstructured format. For the, it was agreed that the DCS would discontinue capturing this information, saving operational effort, and those specific data items are now the subject of a review to determine whether agreed code sets could be introduced that would make the data more consumable by insurers. Another early complication that emerged was that the DCS raised an inordinately high number of queries about MRC content. This arose because the DCS works to rules that were dictated by MRC guidelines concerning mandatory data and that, in fact, there were a surprising number of MRCs agreed by the broker and underwriter where this information was not present. The need to refer MRCs back to insurers to provide this data resulted in extra operational work by insurers in answering the queries. In many cases the answers were simply unavailable without going back to the broker. This started to impact the flow of MRCs to DCS and the evaluation of the service. It was subsequently agreed that the mandatory nature of some data items will be relaxed so that their absence does not delay the service returning a data set to the insurer. A follow up protocol may be required to agree how the resulting data gaps get filled. As the progressed and more insurers signed up for the service, the on-boarding procedures were refined to take into account the unique difficulties that some insurers introduced. Whilst the on-boarding process came under some criticism in the early part of the this has now developed into a smoother process which leaves little room for error. A technical check list for insurers on-boarding was developed and is under Appendix C. The service has evolved and expanded as lessons have been learnt and issues discussed in detail at the Project Managers and Process and Data Groups. This also contributed to thinking about future changes and enhancements which will improve the service over time enhancing the value provided to insurers registered for its use. 6. Evaluation of the Pilot 6.1. hodology A formal approach to quantitative and qualitative analysis of the was adopted. This included an objective analysis achieved through a suite of reports as well as surveys and interviews with participants conducted periodically through workshops and one-to-one meetings. Critical Success Factors (CSFs) were identified for each objective. They were the qualitative elements that must be present for the project to have achieved its objectives. Key Performance Indicators (KPIs) were identified to measure the health of each CSF. These KPIs had thresholds associated with them that defined the agreed tolerance levels for each KPI. In addition, an analysis has been performed to assess achieved versus planned service scope and variety of sources have been used to gather soft feedback on the service and Xchanging s performance. DCS Pilot Evaluation Report v1.0 Page 8 of 30

9 6.2. Delivery against Objectives A detailed presentation of the objectives, CSFs, KPIs and KPI thresholds is included in Appendix A with a commentary on each CSF. The following summarises the position. All formal objectives of the have been met. This position is subject to the following caveats: Although the service was opened up to all classes it has not exhaustively processed the capture of data for every class of business written in the market. Nevertheless, many of what are perceived as challenging classes, such as Marine Energy, have been processed satisfactorily. As has already been stated volumes (which were entirely under the control of participating insurers) fell short of planned volumes some insurers submitted less than planned and some were slower to start submitting Actual Target This was due variously to: the initial loss of momentum caused by firms needing to establish peer-to-peer rather than TMEL connections; a greater than anticipated overhead for some firms in submitting MRCs to the service under a manual process; a greater than anticipated overhead for some firms in manually checking DCS output for purposes (and therefore an inclination to reduce input); the limited value of the data set during in the absence of integration; and a contractual structure which was more complex and onerous than some firms had anticipated for a project s stage. However, the project s market groups considered the volume to be sufficient to draw conclusions and to form a basis on which firms can decide whether to progress to using the live service. Turnaround service levels were met for two (July and August) of the three months preceding the end of the, rather than all three. Xchanging s June performance, which was close to service level (91.6% against 98%), was adversely affected by the bulk submission of MRCs during the first week of June against staffing patterns which anticipated a more even spread of submissions. Whilst the Steering Group expects Xchanging to be able to deal with fluctuations in submission volumes, it felt the spike in volumes was disproportionate to the relatively low level of submissions at that point in the and did not representing a realistic scenario. The Steering Group has spent much time discussing the measure of quality with Xchanging. The service level in use is 98% of data fields captured correctly on first DCS Pilot Evaluation Report v1.0 Page 9 of 30

10 presentation (as a proportion of all data field captured by the service) and the definition of error and how this relates to measurement of quality is set out in Appendix B of Pilot Evaluation 1.1. As with all central services, there is the potential for service performance measured at market level to be different to service performance measured at individual insurer level. Whilst the Steering Group (and in due course the LMA and IUA service review panels) manage overall service performance, individual insurers can access performance data relating to their own submissions and take action with Xchanging if that is not satisfactory and/or can provide feedback to the central management of the service. Another issue affecting measurement of quality was uncertainty around the extent to which participating insurers were rigorously checking DCS output (as it is incumbent on an insurer to raise a query in order for any resulting correction to feed into the measure of quality). Nevertheless, the absence of any volume of quality issues raised by insurers and the very flattering feedback from insurers about the output quality supported the formal reporting by Xchanging of quality performance. As a result, the Steering Group is confident that Xchanging s ability to deliver output to the required quality is proven Delivery Against Scope The original customer requirements identified a number of functional deliverables which were described in the uirements v1.7, Workflow Requirements v2.2 and Data Requirements v2.2 documents. These documents identified 31 functional requirements that were to be delivered in the (and a further 26 to be delivered post-). The table below shows a summary of those deliverables. For full details, see Appendix B. Requirements for the Pilot Requirement met 25 Not met 4 No longer a requirement 2 Total 31 The requirements that were not met are: A central record of the captured data, including version history Web service links to allow information to be accessed from insurer' own workflow systems A means of tracking individual transactions displaying current progression status Rules to trigger alerts where factors such as SLA targets are not met at individual transaction level. The requirements that were not met are not seen as essential. Whilst a central record of captured data along with version history is not available as a specific database, it is discoverable in XML files for a period of time. Web Services links, the tracking of individual transactions, and the triggering of alerts when SLA targets are not met, are all low priority items and will be delivered in due course. This minor shortfall in scope was the result of shifting priorities that arose during the. Whilst there were five requirements that were not or were only partially met, Xchanging delivered six of the requirements scheduled for post- delivery during the and will deliver a further three before the end of the year. In addition, Xchanging have made considerable improvements to the internal operation of the system to improve efficiency and improve the process of data entry. DCS Pilot Evaluation Report v1.0 Page 10 of 30

11 Examples of these are: Support for additional transactions like FDO Validation of specific data items Smart Search for certain codes Additional codes (such as Country/State codes from ISO3166-2) Updates to Service Registration Management An ACORD Standards upgrade Monitoring input queues via Telemetry Enhanced MI Market Feedback and Other Considerations Project Managers have met regularly and shared requirements and experience across all aspects of the service. This has worked well in partnership with Xchanging. Similarly, the Process and Data Group have worked collaboratively with Xchanging. Both groups have contributed to feedback about the as have individual firms. This input has informed the content of this report, particularly section 5 ( The Journey ). Other particular points are: For most insurers to achieve real value from DCS necessitates the automation of submissions and the integration into underwriting systems of data output. This has proved to be a longer process than may have initially been supposed. Whilst the current data set (DCS output) is market defined it is limited to a sub-set of MRC content. For the DCS to have real value it needs to deliver a data set which more closely matches the totality of insurers data requirements. For this reason, early clarity on the development roadmap is essential to engaging more firms in the service. Work on this roadmap is underway and a provisional version is included in Appendix D. Anticipating this further development, progressive participants have been analysing how the dataset can be interfaced into their underwriting system, with minimal human intervention. To this end the LMA have been attending different software house user groups, have visited specific bespoke insurers and have generally supported data analysis on request, covering about half of all underwriting systems in the market. Despite the above, the has validated that the majority of the benefits originally foreseen as arising from shared data capture are viable and has provided immediate benefit to some insurers. Comparison between DCS and current data capture methods has been possible by all insurers and some have used DCS output as a basis for a manual or automated data QA check. The Benefits Statement published at the start of the project has been updated and republished on the LMA web site (see section 2). The majority of insurers interacted with DCS via ACORD messaging. However, an e- mail and attachment option was also available. Over time it is seen as desirable that all insurers move to ACORD messaging since that remains more robust, auditable and consumable than and service s original Customer Requirements assume a TMEL connection. Two insurers have connected their workflow applications to automatically submit to the service with minimal intervention and this has contributed to steady and consistent volumes of scanned DCS Pilot Evaluation Report v1.0 Page 11 of 30

12 slips. This set up is seen as the most desirable end state for all insurers with a workflow system implemented. As an elective service, albeit one provided under managing agents and companies central service agreements with Xchanging, participation by insurers is necessary to ensure viability. Insurers considering participation have rightly sought comfort over the stability and longevity of the service. A number of factors respond to this point: o This report provides a positive review of the service at this stage of development and confirms that it is viable in terms of process and service delivery. Further, the report documents evidence that insurers participating to date share in the vision for the service and believe in the value it can deliver. o The service has been developed by Xchanging at their risk. This has entailed considerable investment by Xchanging based on their belief that post-bind risk data capture represents not only a commercial opportunity for them but is also a strategic step in the evolution of the central services they provide to market customers. o The recently published Target Operating Model for the Central Services Refresh Programme identifies structured risk data capture as a key component of CSRP s first ( Post-bind Submission ) phase. This potentially represents a new opening stage and trigger for central processing. DCS is the early iteration of such a structured risk data capture service Queries on submissions to DCS are raised by Xchanging with the insurer. This is both logical from a DCS perspective but is also in line with the LMG s Framework for the Future and the CSRP model which aim to remove brokers from between insurers and their service providers and take away from brokers the overhead of resolving MRC queries. Over time, this may encourage an improvement in the quality and completeness of MRCs at point of bind but in the near term insurers will need to consider how they organise themselves to deal with such queries. The contractual issues arising between Xchanging and TMEL which adversely impacted volumes during the early part of the were resolved through urgent action at that time. However, market feedback suggests that a re-examination of the contractual structure is needed with streamlining of the arrangements where possible. In addition some elements of these arrangements (particularly TUPE provisions) require the involvement of legal teams which proved too onerous for firms merely seeking to evaluate the service. The concept for DCS has always envisaged the provision of risk data into central processing. The original uirements state: 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.. It is now clearer that these benefits are likely to be a product of CSRP s Post-bind Submission phase. However, the DCS Steering Group is continuing to discuss with Xchanging the potential quick win of integrating Underwriter Reference and UMR into central processing. DCS Pilot Evaluation Report v1.0 Page 12 of 30

13 Lessons learnt from the served to stimulate other, more creative, thinking on opportunities for process improvement such as: building on the LMA s Central Premium Payment Monitoring trial (where it was envisaged that early sight of risks written would facilitate quicker payment of premium through early resolution of queries and credit control activities); making DCS output available to brokers to help align technical account submissions and bureau records; and early sight of risk data to claims processing. These opportunities remain to be exploited via CSRP or elsewhere. The phase of DCS has been supported with a programme of market communications: periodic updates, presentations, one-to-one discussions and the publication of documentation via the LMA web site. Towards the end of the a questionnaire was circulated to managing agents asking about their future intentions regarding the service. Of the 22 agencies that responded, five indicated their intention to engage with DCS this year, seven in 1Q 2015, five in 2Q 2015, and one in 3Q A further four have yet to establish plans or will look to engage in Summary and Conclusions In summary, the has achieved its stated objectives and has shown that a centralised risk data capture service is feasible and attractive to insurers. Xchanging, as our selected partner, has shown that it is capable of delivering to the required service levels. The Steering Group with Xchanging and individual firms have developed a body of knowledge concerning the operation of the service, the processes which support it, the data, and the benefits which are available to insurers. This enables the market to move forward in enhancing the service. The strategic importance of early risk data capture in a future central processing model has been recognised. In addition to the above, the key conclusions drawn by the Steering Group from the phase of DCS are: a. DCS offers immediate benefit to some insurers. However, for benefits to be maximised for the majority of insurers a number of enhancements and dependencies need to be addressed: The data captured needs to more closely align with the totality of insurers data requirements: the requirements already identified for analysis include more comprehensive MRC data, data at quotation stage, endorsements, schedules, and off slip data. A provisional version of the development roadmap is included in Appendix D. Insurers need to be able to auto-submit to DCS and automatically integrate DCS data into underwriting systems: this latter point is shared with electronic placing support and, potentially, improved risk reporting processes for binding authority business. The DCS project has stimulated activity amongst insurers and suppliers to enable such integration. b. Establishment of the service under managing agents and company insurers XIS service agreements provides an efficient mechanism for building, enhancing and managing a shared service. However, the requirement for additional agreements dealing with TUPE and TMEL create a cumbersome contractual structure which some insurers have struggled with. This is particularly so where the insurer merely wishes to assess the service. DCS Pilot Evaluation Report v1.0 Page 13 of 30

14 c. Due to these dependencies, the adoption of DCS by insurers is likely to be a more prolonged affair than had been originally anticipated. d. Although DCS is predominantly an insurer-facing service and any structured risk data capture component of CSRP would work largely to deliver data to central processing, it would be illogical for the market to support two market-wide shared services. It will therefore be crucial to ensure the close alignment of the future development of DCS with CSRP. 8. Recommendations and Next Steps The following recommendations are presented by the DCS Steering Group for endorsement by the LMA s Market Processes Committee (MPC) and the IUA s Process Efficiency Group (PEG). The Data Capture Service provided by Xchanging is confirmed as fit-for-purpose and suitable for further development. A roadmap be developed by the Steering Group, with Xchanging, for agreement by MPC and PEG to build on the data set captured by DCS and to widen the service s scope to include those elements not included in the phase (as described above). The Steering Group to continue to encourage both insurers and system suppliers to develop and implement workflow integration capability (for automating submission to DCS) and a data integration capability in underwriting systems. The Steering Group to actively seek formal alignment of DCS with CSRP s structured risk data capture service to ensure that the needs of both DCS customers and central processing are met as effectively and efficiently as possible for bureau users without prejudicing the requirements of non-bureau users. Similarly, alignment to be sought with the market s initiatives to support placing as those initiatives, and CSRP, develop and mature. The Steering Group, with Xchanging, to continue to engage with London market insurers to promote DCS. Management of the DCS, in terms of service delivery by Xchanging as well as enhancement of the service, remains with the DCS Steering Group and its subgroups DCS Pilot Evaluation Report v1.0 Page 14 of 30

15 Appendix A: Objectives, CSFs, KPIs and commentary The objectives, CSFs, KPIs and KPI thresholds were agreed by the Steering Group and Xchanging prior to commencement of the and were published in Pilot Evaluation 1.1. All reference to MRCs means those MRCs agreed between the Steering Group and Xchanging to be in scope at any particular point in time. Objective 1: Insurer Submission Process The DCS can be initiated by insurers subsequent to recording a firm order line, including leader and follower procedures. CSF: All elements of the procedures and work flow have been designed, documented and proved during the for live risk data. KPIs and That there are no significant unresolved procedural or work flow issues within the control of Xchanging. thresholds: That a 'Systems, Processes and Procedures' manual has been signed off by the Steering Group for publication to the market. Commentary on CSF: Assessment against Objective: Once insurers had completed the on-boarding procedure and had tested the communications by their preferred route ( or ACORD messaging), they were able, per the uirements, Workflow Requirements and Data Requirements documents, to: o Submit all classes of business (by the end of the a broad range of classes had been submitted by the participating insurers) o Submit both subscription and singleton risks, including vertical placements o Include insurer-specific references as structured information o Submit risks as either a leader or a follower although the concept is irrelevant to the DCS. The concept of first submitted was established and subsequent submitters enjoyed very fast turnaround times as a result of data that had been prior-captured. There are no unresolved process issues within the control of Xchanging. The processing procedures were refined during the and have been consolidated in the DCS Systems Process and Procedures manual published on the LMA web site. Objective met.

16 Objective 2: DCS Internal Workflow DCS workflow correctly routes incoming submissions, whether new risks, repeat submissions, query responses or correction requests, to the appropriate Xchanging team for action. CSF1: All elements of the service process and work flow have been designed, documented and proved during the for live risk data. KPI and That there are no significant unresolved process or work flow issues within the control of Xchanging. thresholds: Commentary on CSF1: All touch points in the workflow are operating as expected. Insurers are able to submit MRCs to the service either by ACORD Messaging or by and the submissions are routing to appropriate work baskets within the DCS accordingly. Resubmissions and queries are correctly directed to the technician who worked on the original submission. There are no high-priority unresolved service process and workflow issues within the control of Xchanging. In particular, Xchanging were able to demonstrate their ability to: o Search the database for earlier submissions using the same UMR o Re-use data submitted by another insurer on the same risk, where the terms and conditions are the same o Identify cases where the terms and conditions differ between insurers on the same risk, thereby treating them as vertical placements o Link common queries, so as not to generate repetitive questions to the market o Add the MRC to the IMR once the data capture had been completed. CSF2: Inwards and outwards queries and query responses are managed effectively by the DCS KPI and That the number of delays and/or lack of response to queries as a proportion of the total number of queries are within thresholds: appropriate levels. Commentary Inwards Queries (Insurers to DCS) on CSF2: During the early months of the, a high level of frustration was experienced by insurers in trying to get helpful responses from the DCS. Significant delays were common, and the degree to which the response from the service answered the query was poor. This arose as a result of several factors, e.g. o The insurers did not fully understand the data capture rules that had been agreed o The query management procedures were inadequate o The DCS capture team was finding its feet o The types of query that were being generated challenged the original requirements and agreed rules. Over time, robust query handling procedures were put in place, the DCS capture team gained experience, and a number of specific issues resulting from queries were diverted to the Process and Data Group for resolution. During the, Xchanging has responded quickly to defects and non-functional changes and this has resulted in a smooth-running operation DCS Pilot Evaluation Report v1.0 Page 16 of 30

17 Commentary on CSF3: at the end of the. Xchanging maintain an up to date query log that is available to insurers for examination and they produce statistics showing the volumes and types of queries on a monthly basis. Outgoing Queries (DCS to Insurers) A large number of queries generated by the DCS were as a direct result of mandatory information that was simply missing from the MRC document. This generated a large number of outward queries causing frustration amongst insurers. This will be alleviated after November when a change will be introduced that will provide a better way of managing missing mandatory data. Analysis shows that the number of queries generated by the DCS as a proportion of the total number of submissions as at the end of July is about 20% and that this is a reducing figure. About 40% of the current queries will be eliminated when the mandatory data solution is implemented. CSF3: Corrections and resubmissions are routed effectively to the correct team by the DCS and by insurers' workflow systems (whether integrated or otherwise). KPI: That the number of resubmissions that are not aligned to the original submission are within appropriate levels. Assessment against Objective: During the there were very few occasions where it was necessary to resubmit a changed MRC to the DCS. In all such cases, the DCS correctly associated the resubmission with the original MRC and processed the case correctly. Returning the insurer s resubmission by the DCS to the correct team in the insurer s office was not an issue because the DCS sends all submissions back to the insurer with the references that it picked up from their incoming submission. This allows the insurer to route it to the correct inbox accordingly. Objective met. DCS Pilot Evaluation Report v1.0 Page 17 of 30

18 Objective 3: DCS Data Capture Process The DCS meets agreed turnaround service levels. CSF: Turnaround service levels reached and met consistently. KPIs: o Data output - data files are delivered to each insurer participating in the within SLAs. Service levels deemed to be met consistently if met for at least three months prior to end of phase for MRCs within agreed volume limits. o Outwards queries - queries raised with insurer on information received in order to deliver 'Data output'. o Inwards queries - review queries received from insurer on data output; queries resolved to insurer's satisfaction. o Corrections - delivery of a replacement data file to each insurer participating in the service following query of data. o Document load to repository - loading of insurer supplied MRC plus supporting documentation and structured output data in a document of the agreed format to a central document repository. o Support - manned helpdesk for service and data queries. Commentary on CSF: Assessment against Objective: The DCS Steering Group has monitored Xchanging s delivery against the contracted service levels. Despite some early teething issues, Xchanging are now consistently meeting the key deliverable of production of 98% of output data files within the required 6 hour timescale. The last three months of the have recorded turnaround times as follows; June 91.6% July 99.5% August 100.0% June performance was adversely affected by some bulk submissions in the first week which resulted in a number of those items missing SLA as staffing patterns were put in place to support a more even spread of work. Additional support was arranged and the SLA was maintained for the remainder of the month. Performance has been at 100% since early July. As a matter of interest, the average turnaround time at the end of the period was 3 hours and 23 minutes. Outwards queries (raised by the DCS) have been higher than anticipated, mainly due to the stringent rules concerning mandatory data conflicting with the less stringent controls over MRC completion by brokers and underwriters. This is not a fault of the service rather a benefit in identifying deficits in MRC completion but nevertheless changes are being introduced to relax the rules in the DCS so that insurers are not faced with the additional administrative burden of dealing with too many queries. For information, during July the DCS raised 111 queries of which 28 were in respect of data items that affected contract certainty and a further 19 were in respect of tax and regulatory data. In all respects, outward queries have been managed efficiently and in accordance with agreed capture rules and within SLA. Inwards queries (raised by insurers) have been handled within the rules and within SLA. During July, the DCS made 6 corrections, of which only 2 were attributable to their error. This is well within SLA. Similarly, Xchanging have met service levels across corrections and document load to the IMR. Objective met. DCS Pilot Evaluation Report v1.0 Page 18 of 30

19 Objective 4: DCS Data Quality The output from the DCS meets agreed quality service levels and conforms to the agreed standard. CSF: Quality service levels reached and met consistently. KPI: That quality and accuracy are as per Service Definition. Service levels are deemed to have been met consistently if met for at least three months prior to end of phase for MRCs within agreed volume limits. Commentary on CSF: Assessment against Objective: The DCS Steering Group has monitored Xchanging s delivery against the contracted service levels. Xchanging have consistently met the key deliverable of production of 98% of output data fields correct for the three months preceding the end of the. In fact, there have only been 3 errors attributable to Xchanging during that period and performance has been at 100% since the second week in July. Similarly, the service level associated with corrections has been fully met, i.e. 100% correct first time. The experience has shown that there are challenges in ensuring that service performance at market level properly equates to service performance at individual insurer level. This challenge exists across many of the market s collective services and is examined in more detail elsewhere in this report. Objective met. Objective 5: Insurers Business Case Insurers can demonstrate the business case for adoption of the service (including the required software changes to receive the DCS output). Commentary on CSF1: CSF1: Pilot participants confirm adoption plans for the service based on a valid business case. KPI: That a proportion of participants confirm adoption plans for the service based on a valid business case evaluated using feedback on the and in particular insurers' adoption plans and their views of the business case supporting adoption. Eighteen insurers participated in the with the majority involved across most of the seven month period. Of these, six have indicated that it is their intention to integrate DCS for live usage based on internal business cases. During August the thirty-six managing agents, which had yet to formally engage with DCS, were asked to indicate their intentions. Of the twenty two agencies that responded, five indicated their intention to engage with DCS this year, seven in 1Q 2015, five in 2Q 2015, and one in 3Q A further four have yet to establish plans or will look to engage in In total this represents fifty insurers engaged with DCS across 2014 and 2015, indicating that they have identified a business case whether on a provisional basis requiring further exploration or on a finalised basis. The recently published Target Operating Model for the Central Services Refresh Programme identifies structured risk data DCS Pilot Evaluation Report v1.0 Page 19 of 30

20 Commentary on CSF: capture as a key component of CSRP s first ( Post-bind Submission ) phase. The extent to which this may establish the post-bind submission of MRCs by insurers as a new opening stage and trigger for central processing enhances the business case for individual firms to become involved in DCS as the early iteration of such a structured risk data capture service. CSF2: Pilot participants confirm intention to integrate DCS output into underwriting systems. KPI: That a proportion participants confirm intention to integrate DCS output into underwriting systems evaluated using feedback on the and in particular insurers' future intention to integrate DCS data into underwriting systems. The identified three key stages for insurer integration (i) submission to the DCS service, (ii) interim use of the DCS dataset from the service, and (iii) full integration on the DCS dataset from the service into underwriting systems. Submissions During the course of the two insurers commenced automatic DCS submission into their workflow with the intention of expanding usage post-. Interim use of dataset ahead of full integration Discussions with both insurers and their system suppliers confirmed that a significant amount of analysis, specification definition, development and testing is required to integration of the DCS dataset into underwriting systems. In the interim, two insurers have already automated receipt of the dataset into new internal data quality and checking systems and processes to cross-check their existing data capture quality against the DCS output and manage any queries that arise. Full dataset integration into underwriting systems Seven insurers (of which six participated in the ) have confirmed their intent to integrate the DCS dataset into their systems, comprising: One in-house insurer anticipated integration December Five (plus one non-) insurers using NIIT anticipated integration in January Assessment against Objective: In addition, two further insurers are actively engaged with Northdoor to progress integration development. AgencyPort, who have three insurers and two further insurers who intend adopting DCS in 4Q14, are developing an integration prototype for their insurers to review late 4Q14. Objective met. DCS Pilot Evaluation Report v1.0 Page 20 of 30

21 Objective 6: XIS Scalability. The DCS can be implemented as a full scale market service following completion of an on-boarding process. CSF: Feasibility of scalability of service: demonstration of Xchanging expertise across all classes. KPIs: A feasible, practical and realistic plan has been agreed between Xchanging and Steering Group. Commentary Xchanging have provided a statement on scalability for DCS which is included in Appendix E. The Steering Group has on CSF: accepted this in the context of the service as it currently stands. Assessment against Objective met Objective: DCS Pilot Evaluation Report v1.0 Page 21 of 30

22 Appendix B: Functional Requirements Requirements for Pilot Ref Stage Requirement Source Status 1 Pilot To capture and transform information from a variety of input formats into ACORD structured data once on behalf of all insurers subscribing to an MRC. v1.7 page 3 2 Pilot Conduct a pre-defined data quality check once on behalf of all insurers subscribing to an MRC. v1.7 page 3 3 Pilot Clarify, through query and resolution, data once on behalf of all insurers subscribing to an MRC. v1.7 page 3 4 Pilot Create a central record of the captured data, including versions of this where changes have occurred. 5 Pilot The DCS will interact with the IMR to store a copy of the contract documentation and the data set. 6 Pilot The service must comply with UK and European competition law, and be in line with BIPAR principles. 7 Pilot The DCS must be 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. v1.7 page 3 v1.7 page 3 v1.7 page 4 v1.7 page 4 8 Pilot New business and renewals. v1.7 page 4 9 Pilot All classes of business (per doc) subsequently agreed as Property, Casualty, Marine Hull, Marine Cargo, Marine Liability, and Terrorism (per Data Req doc) Specifically excluded were Energy, Aviation and Treaty. v1.7 page 9 Data req. v2.2 pages 3 & 4 Not met DCS Pilot Evaluation Report v1.0 Page 22 of 30

23 Ref Stage Requirement Source Status 10 Pilot Includes open market placements. v1.7 page 4 11 Pilot Includes lineslip declarations requiring underwriter agreement, and binder contracts. Definition amended to Delegated authority arrangements where there is no single risk-level signing through central processing. 12 Pilot Include both bureau and non-bureau business. Non-Bureau Broker identifiers will be allocated by XIS as and when each new broker surfaces. An attempt will be made to use the DUNS code for the broker, but it is not mandatory to do so. v1.7 page 4 Data req. v2.2 page 4 v1.7 page 4 Data req. v2.2 page 5 13 Pilot Include both subscription and non-subscription risks, including vertical placements. v1.7 page 4 14 Pilot 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. 15 Pilot The DCS will provide web service links to allow this information to be accessed from insurer' own workflow systems. [Note: This is not the Query management requirement see item 27] v1.7 page 6 v1.7 page 6 16 Pilot A means of tracking individual transactions displaying current progression status will be available. v1.7 page 6 17 Pilot Rules will be established and implemented so that alert s are triggered where factors such as SLA targets are not met at individual transaction level. 18 Pilot The output file will contain the data elements defined in the 'DCS Data Requirements' document (as amended from time to time). 19 Pilot The output file will be compliant in all respects with the ACORD GLRC standard in use in the London market. 20 Pilot The available formats are an ACORD structured data message, a CSV format file, or an Excel spreadsheet. v1.7 page 6 v1.7 page 7 v1.7 page 7 v1.7 page 8 Not met Not met Not met Since removed DCS Pilot Evaluation Report v1.0 Page 23 of 30

24 Ref Stage Requirement Source Status 21 Pilot The outputs may be sent individually or bulked. v1.7 page 8 22 Pilot The supplier will build a measurement and reporting regime sufficient to enable it to demonstrate compliance with service levels. v1.7 page 8 23 Pilot Billing model v1.7 page Pilot Customer Registration v1.7 page Pilot ACORD AMS messaging transactions may be processed through the Exchange (TMEL) or on a peerto-peer basis in accordance with individual customer requirements. 26 Pilot For the, the mandatory structured data required as an input to the DCS is as follows; insurer reference(s), and correction identifier (only required on resubmissions). 27 Pilot A query management process will be provided. The DCS will submit the query to the insurer by telephone or by to a designated address for the insurer. The DCS will record the query on the log maintained by them. A query reference will be allocated and quoted in all communications between the DCS and the insurer. 28 Pilot The data items will be captured by the DCS at the most granular level possible from the information available in the MRC. 29 Pilot Sections will be represented in the DCS output file as they have been portrayed by the broker in the MRC. No attempt will be made to change the section structure to suit individual insurer's views on sectionalisation. From a data point of view it has been agreed that the section identifier will be assigned by the DCS service itself. 30 Pilot All long fields will be paraphrased by the DCS service. These include Interest, Contract Changes Agreement Basis, Basis of Claims Agreement, Claims Administration, Underwriters Delegated Agreement Role, Bureaux Arrangements, Non Bureaux Arrangements, Notice of Cancellation. The requirement to capture text for these fields was later removed. Workflow Req v2.2 page 4 Workflow Req v2.2 page 5 Workflow Req v2.2 page 7 Data req. v2.2 page 4 Data req. v2.2 page 5 Data req. v2.2 page 6 Since removed DCS Pilot Evaluation Report v1.0 Page 24 of 30

25 Ref Stage Requirement Source Status 31 Pilot Core data as per the DCS Data Requirements spreadsheet. Many changes and additions are now proposed. Data req. v2.2 page 6 Post-Pilot Requirements (for information only) Ref Stage Requirement Source Status 1 End state 2 Post The supplementary capture and transformation of any bespoke data items required by a particular subscribing insurer. Integrated with central processing through provision of the output data file to XIS. v1.7 page 3 v1.7 page End state For renewals, reuse previous year s data where possible. v1.7 page 3 4 End state Endorsements. In-flight Endorsements v1.7 page 9 Workflow Req v2.2 page 8 5 End state Quotations and pre-bind data. v1.7 page 9 6 End state Includes consortia placements. Consortia later qualified in Workflow document: Where data is processed in respect of a consortium, no attempt will be made in the to pass data to other members of the consortium even if they are signatories to the DCS service. v1.7 page 4 Workflow Req v2.2 page 4 Delivered in Pilot 7 End state Risk schedules. Analysis now under way. v1.7 page 9 8 End state Conformity rules (i.e. ensuring that common data is represented in a uniform way, such as 'Ltd' for 'Limited'). Such an aspiration will require the authority and backing of a market-wide governance body before considering implementation at market level. Data req. v2.2 page 4 DCS Pilot Evaluation Report v1.0 Page 25 of 30

26 Ref Stage Requirement Source Status 9 End state 10 End state 11 End state 12 Post 13 Post 14 Post 15 Post 16 Post 17 Post 18 Post Transformation and Interpretation Rules (i.e. those rules that using multiple data items to derive further information in a form that is not intrinsically contained in the MRC). To be clear, transformation is not the same as conversion of freeform text to agreed codes. If structured data has been received by the insurer from the broker as part of an electronic placement it may be sent on to the DCS for use by the service. The DCS end-state solution will use the broker data to achieve more efficiency. Data req. v2.2 page 4 Data req. v2.2 page 5 Subjectivities. Data req. v2.2 page 6 The following fields removed from the data set: Line Conditions, Underwriter Name, Estimated Signing, Bureau Arrangements/Non-Bureau Arrangements. Country of Origin added to ACORD message. Vessels. Two new class-specific data items (Vessel Name and IMO Number) added. Multiple Insured Names to be captured. Stop capturing large amounts of text captured for following fields; 14 - Interest 24 - Premium Payment Terms 36 - Contract Changes Agreement Basis 38 - Claims Agreement Basis 40 - Claims Administration 41 - Claims Delegated Authority. Aviation Additional Data Fields. Multiple Taxes Payable by Insured/Insurer to be captured. DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr Delivered in Pilot Delivered in Pilot Delivery in Sept Delivered in Pilot Delivery in Sept DCS Pilot Evaluation Report v1.0 Page 26 of 30

27 Ref Stage Requirement Source Status 19 Post 20 Post 21 Post 22 Post 23 Post 24 Post 25 Post 26 Post NAIC & FEIN Codes added to data set. FDO's. 14 additional data fields be added to the DCS data set for (1) Binders FDO, (2) Treaty FDO, (3) Bulking Lineslips FDO, and (4) Non-Bulking Lineslips FDO. Mandatory Data Items reviewed and a new method of dealing with them proposed. Remaining MRC data to be added. Analysis now under way. Queries by ACORD Messaging. Processing of queries to be made smoother and provide better control through ACORD messaging and workflow triggers. Premium Data Set to be enhanced to enable the capture of Adjustable Premium, Gross Premium Income Limit, Instalments, Settlement Currency, Reinstatements, and Discounts for Prompt Payment. In addition, further clarity concerning Premium Types and Settlement Due Date are to be introduced. Where Additional Insureds are captured, the Country Code for each Additional Insured is also be captured if available. Make several data items repeatable, i.e. Overriding Commission, Other Deductions, Locations, and Excluded Locations. DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr DCS Data Issues Regstr Delivered in Pilot Delivered in Pilot Delivery in Nov DCS Pilot Evaluation Report v1.0 Page 27 of 30

28 Appendix C: Insurers Checklist (also available in the Xchanging DCS On-Boarding pack) Action Review On-boarding pack Establish how you will record the MRC, reference and line and then submit to DCS (e.g. scan, etc) Define input / output formats ( / peer to peer / TMEL) For ACORD users, ensure 3 rd party gateway suppliers engaged (e.g. web connectivity) Establish status of generic integration with underwriting platform Approve contract registration letter(s) and submit to Xchanging Define business classes / contract types for inclusion Define submission volumes Establish primary contacts / contact approach (e.g. generic / specific mailboxes) Establish service preferences (e.g. market) Establish syndicate numbers / years of account For ACORD formats, define placing message details Finalise technical registration form and publish to Xchanging Define business / technical processing rules for submission to DCS and receipt of output from DCS Establish how you will use the data: as a quality control, to speed up manual entry, automated with underwriting systems Consider how internal processes may need to change e.g. alignment of front sheets, quality checks, query management Train DCS contact users Perform connectivity test on Training environment with Xchanging (ensure that you have access to network technician resources to assist in set up and testing) Perform connectivity test on live environment with Xchanging Go live Status

29 Appendix D: Provisional Development Roadmap DCS Pilot Evaluation Report v1.0 Page 29 of 30

30 Appendix E: Xchanging statement on scalability DCS Pilot Evaluation Report v1.0 Page 30 of 30