Skip to main content

Frequently Asked Questions

Take a look through our latest list of Frequently Asked Questions

Lloyd’s set out the vision and purpose for the CDR as part of its Future at Lloyd’s strategy to shift the market to a digital ecosystem, powered by data and technology. The CDR will ultimately enable standardised, quality data to flow through the Lloyd’s market, with the aim of significantly improving operations, reducing the cost and effort of doing business, and ultimately delivering a better service to customers. This premise is at the heart of the Blueprint Two programme, which is the second phase of Lloyd’s ambitious Future at Lloyd’s strategy.

The first iteration of the CDR published in March 2021 focuses on a limited set of use cases for the data, i.e. tax, sanctions, and accounting and settlement. Subsequent iterations of the CDR will include all the data required for Open Market North American Property insurance. Later versions will add in fields required for other lines of business and geographies. We will communicate clearly which iteration of the CDR contains all the data items required to deliver Blueprint Two.

The CDR is focused on the placement process, and primarily on the data available at the point of bind. Initially the focus is on new business.

We are currently focusing on regulatory reporting. Not all of Lloyd’s supervisory reporting fits with the nature of the CDR; where appropriate we will bring supervisory reporting into scope at a later date.

No. We are currently developing the data model and will release this at a later date.

One of the key principles of the CDR is to eliminate the use of Lloyd's specific identifiers and codes. Main examples of this are the Lloyd's risk codes and Foreign Insurance Legislation (FIL) codes. The CDR aims to collect the fundamental data points that drive the calculation of these codes.

We are working with the market to build the CDR with a view that it will be optimised for all classes of business. We will take an iterative approach to development seeking input and insight from the market. Ultimately, we envisage that the CDR will be used for all business placed in the future.

The Market Reform Contract (MRC) is administered by the London Market Group (LMG) on behalf of the associations. It is envisaged that, alongside the work we are doing to digitise processes for the Lloyd’s market, the iMRC will introduce more structure and guidance into the MRC with the objective to capture placement data in a more consistent format. Data fields captured in the iMRC will form the definitive record of the transaction and will be one of the sources used to populate the CDR. We will work with insurers, ACORD, market associations and placing platforms to support the design, iteration and deployment of the first version of the iMRC.

Data will be provided either through placing platforms or directly to Lloyd's.

All data is owned by market participants, and only the appropriate parties will get access based on ownership.

Market participants will own the accuracy of the data supplied to Lloyd’s. New governance and oversight committees will be set up to monitor data quality.

We are working with ACORD to define the certification framework and liaise with market participants to agree an approach. Where data provided to us is not in the standardised format but can easily be transformed, we will facilitate this, however it will be the responsibility of the data provider to validate any data transformations. Data providers will also be responsible for validating any enriched data prior to it being used for further downstream processing. The process for validating data is in the design phase. 

We are engaging with ACORD to help validate the standards that can be adopted and used in the CDR, to ensure that the data coming through to the Digital Gateway is of good quality and in the same format.

At each stage in the data journey where the CDR is acquired or transformed, we will embed automated data quality checks to ensure that the data driving the end-to-end process is acceptable and complete. We will work with the market to trial the process using test data, and ensure these checks are at the appropriate level to generate good quality data while minimising the burden on data suppliers. 

An optional pre-submission validation tool will be built to allow users to confirm data quality prior to submission. Any data quality issues identified will be raised as warnings to the user, giving them the opportunity to remediate any issues prior to submission. 

Data quality dashboards will be produced to inform periodic quality monitoring reviews, identifying key areas of the CDR which are proving to have the lowest quality data, that are critical to accurate downstream processes. Engagement with the market is critical to remediate any data quality issues and ensure the robustness of the CDR.

Where a data issue is identified and needs validating, this will be raised with the data originator (i.e. the relevant market participant).

Our aim is to enable better quality data across the industry and not just the Lloyd's market. This means that data quality standards should be applicable cross-market. We will publish quality standards and provide testing against those rules in due course.

Use of CDR data will be itemised, published and only used for approved purposes.

We will produce and issue security statements to give an overview of the security and technology used, including centralised security controls. All data stores will have these controls in place to ensure the appropriate data confidentiality for each entity. Encryption protocols will also be implemented to protect personal and sensitive information – this data will be encrypted on entry to the Digital Spine, as well as in transit between systems, and at rest.

The technical solution will have robust access and security controls in place to ensure the appropriate data confidentiality for each entity and that information is only shared based on agreed permissions, preferences and consent. 

We are currently undertaking research to understand how data may be shared between market participants in the event of changes in roles, renewals to contracts and other circumstances in which different parties will be required to share data. Further details on the proposed design will be shared in the coming months.

The Digital Spine will contain the necessary access control components to ensure that only users with the correct privileges will be able to see the relevant data. One example is the single sign-on capability, which increases security by checking a trusted identity provider for the latest source of truth when authentication is necessary. If a user does not have access to see the details of an individual’s personal data, only anonymised or masked data will be available. Lists of active users will be monitored and kept up to date, to ensure the correct permissions are maintained.

We will identify and evaluate risks of unfair bias and discrimination that can occur through data or through the human bias of the individuals programming any AI algorithms. This includes removing personal characteristics that cannot be objectively justified for use and understanding regional and international differences of ethical expectations. 

We will be transparent about any default settings and decisions we make or are taking that are driven by data and will be able to explain these to market participants, auditors and regulators in an appropriate manner.

Customers will be able to access an appropriate description of how they are interacting with AI or other automated systems to ensure transparency around the use of automation along customer journeys. 

We will provide clear definitions of roles and responsibilities that are understood by data owners, system owners, model owners and development teams, and data scientists will adhere to an ethical code of conduct. There will be robust processes and procedures to ensure AI models and explanations are documented and maintained. We will develop processes and frameworks to test, monitor and govern the potential liability around the ethical use of data, with individuals appointed to be responsible for the impact of any algorithms and AI. Employees will be aware of the limitations of AI and algorithms, and third parties will have ethical standards imposed by contracts.

We will adhere to the fundamental principle of data minimisation and retention in line with the UK General Data Protection Regulation (GDPR). The CDR aims to capture the minimal amount of personal data held on a risk that is required for downstream processing. Personal data will not be stored for longer than necessary to fulfil the lawful purposes for which that data is processed. 

We will respect the customer’s choice to have data deleted when requested, however a completed review form must be seen and a full record of data that has been destroyed or retained for a further period will be kept. Any information deleted from operational systems will still be present in back-up systems. 

The scope of the initial iteration of the CDR is focused on Open Market North American Property insurance as it is considered line of business and geography agnostic where terms are common. Many data items are common across all business (we estimate around 80%), others are specific to geography and line of business and will follow in later iterations.

We are sharing iterations of the CDR with market participants to gain insight and input, and this includes things that we may have missed. Guidance on how to provide feedback is available alongside the link to the CDR template.

The initial iteration of the CDR progresses the analysis work done previously, including the ‘spike’ work and LM TOM, and provides more detailed information regarding the fields.

SDC documentation (and other resources) were used as an input into defining the data items for the CDR.

ACORD Data Standards are aimed at helping the industry achieve the goal of straight-through processing. Lloyd’s is currently working with ACORD to establish a suitable mechanism to allow non-member access to the standards via a restricted license and will provide further information on this at the appropriate time.

The CDR, combined with other digital services delivered as part of the Future of Lloyd’s strategy, will eliminate the need for manual LPAN-based central submissions and supporting schedules. LPAN will remain for those participants who do not move onto the new digital services.

The CDR simulation is a series of tests to identify the fields that are required to power downstream processing. This is for the first scenario which is Open Market North American Property insurance. Specifically, the simulation will test:

the gap between the CDR template and the data the market currently captures for a policy;
data availability, formats, standards, where is the data stored, the granularity of the data stored; 
whether placement support services can produce required outcomes based on fields provided by participants and enriched fields sourced, e.g. tax calculations; and
enrichment opportunities within placement support services and in the Digital Gateway.

Risk codes have developed gradually over time and present a barrier to us fully automating processes; they do not enable us to segment risks to meet changing business needs and it is difficult for any party that is not familiar with Lloyd’s to understand and assign risk codes.

Lloyd’s long-term vision is to capture key details about risks as separate pieces of data within the CDR and to, ultimately, remove the need for risk codes.  

The colour wheel below shows the sort of information that needs to be captured to enable this new method of classification.
 

Lloyd’s recognises that risk codes are currently used in many systems and processes and plans to enrich the data in the CDR with the appropriate code(s) using the key facts provided about the risk.

For example:

Where the insured item is Fine Art, only one risk code FA can apply.  
Where the insured item is Bloodstock or Livestock applying a code is a little more complicated. Where the business is written under Excess of Loss, risk code NX applies; otherwise, if the insured item is Bloodstock, the code is NB, and if the insured item is Livestock then the code is N.
Where the insured item is property many different codes may apply. Typically, we will need to consider the:

-  coverage, e.g. difference in conditions or property damage;
- perils, e.g. fire, terrorism or war on land;
-method of placement, e.g. open market or binder; and
- location of the property.

This diagram shows how logic might be used to derive risk codes for Open Market North American Property Insurance business.

Foreign Insurance Legislation (FIL) codes are currently generated manually and are used by Lloyd's and market participants to group transactions and drive multiple downstream processes including regulatory reporting. There is a set of key data fields which we aim to collect through the CDR to enable the calculation of FIL codes automatically. This sort of logic is already being used in Lloyd's Direct Reporting (LDR). The example below illustrates how FIL codes will be calculated within the scope of Open Market North American Property insurance.