Welcome to the PRR Consultation
The PRR consultation moves us further along a path that will see truly fast flows of all our customer and risk information between the many participants in our often syndicated, delegated or layered market. Instead of sharing Word documents and PDFs, data will ultimately be transferred at ultra-high speed between those who need to share information.
|
Term |
Definition |
|
Accreditation standards |
Platforms used for CDR submission will be required to comply with new accreditation standards. It is the responsibility of the platform provider to acquire and maintain accreditation. The standards have not yet been defined, but will be released in the near future. |
|
Accredited platform |
A platform that meets the accreditation standards. |
|
ACORD |
ACORD (Association for Cooperative Operations Research and Development) is the global standards setting body for the insurance and related financial services industries. |
|
ACORD CRP Message |
ACORD CRP messages (using GRLC standard) events are used to exchange data (and attached documents) with the JV Gateway. |
|
Approver |
The participant responsible for reviewing and accepting the CDR data supplied by the creator. |
|
CDR |
The Core Data Record (CDR) provides the critical transaction data which is required to drive automated downstream processes: |
|
CDR API |
The API collects the relevant CDR data elements exchanged and approved during the risk placement process and submits this data to the Digital Gateway for validation. It is also the method used to achieve soft validation calls during the placement process, if required. |
|
Contract Complete |
A term created by the PRR Working Group to define the point in the placement process where the broker has received all written lines required to fulfil the order. No further underwriting of /subscription to the risk is required and sign down has been completed, if necessary. |
|
Creator |
The participant responsible for supplying CDR data into the placing process. |
|
Derived field |
CDR fields that are derived during JV Gateway processing, using the logic applied to the provided data in the CDR. |
|
Digital Gateway |
The Digital Gateway will receive CDR submissions related to risks underwritten by Lloyd’s and Company Market carriers who will use central Digital Processing Services for premium and claim processing. The Digital Gateway ingests, validates, enriches and stores the CDR data. It also generates responses to the CDR submission back to the source platform and provides a method for servicing requests for retrieval of CDR data by authorised carriers and brokers. |
|
Each Lloyd's Re/Insurer |
Any Lloyd's syndicate participating on the MRC, irrespective if you are a lead or a follower. |
|
Each Re/Insurer |
All carriers participating on the MRC, irrespective if you are a lead or follower (Lloyd's or Company Market). |
|
Errors |
Errors are intended to advise participants of information that is invalid/missing and requires rectification and resubmission before being accepted into downstream processing. |
| Financial account |
Agreement to settlement transaction data. |
|
Hard Submission |
Triggered by any accredited platform, ‘Hard submissions’ to the JV Gateway allow participants to submit a complete and accurate CDR, creating a referenced and versioned record in the Joint Venture Gateway IROS. |
|
Irrefutable CDR |
Once the CDR submission has successfully completed all Digital Gateway processing and is considered complete and valid it will be considered ‘irrefutable’. Prior to submission to the Digital Gateway, the data content of the CDR will be approved by the broker and carrier(s) subscribing to the risk, and any data errors identified by gateway validation will be resolved following the same principles. This ensures once the CD R completes gateway processing the data content is accepted by both brokers and carriers and will not be contested or questioned when it is used to validate risk premium technical account submissions &/or first notification of loss. |
|
Lead Re/Insurer - Bureau User (Lloyd's or Company Market) |
This is the Slip Lead, which could be either Lloyd's or Company Market, whoever is responsible for setting terms on an (re)insurance contract that is subscribed to by one or more (re)insurers. |
|
Lloyd's Lead Re/Insurer |
Where there are Lloyd's and Bureau company market participants, it is necessary to separately identify Bureau or Lloyd's Lead, where applicable, to cater for any Lloyd's specific data or Bureau processing data. |
|
Lloyd’s mandatory line by line submission |
Lloyd’s Corporation requires that, for Lloyd’s business, a (partial, near complete) CDR submission is made to the Gateway at the time each Syndicate writes their line. The process expects the action of a Syndicate writing a line to automatically trigger a CDR submission. |
|
MRC |
Market Reform Contract (MRC) is a standardised contract used by the London Market, that has been enhanced (Version 3.0) so that key data exchanged during the placement process and required in the CDR can be readily extracted and assembled for inclusion in a CDR sub mission to the Digital Gateway (and potentially other use cases). MRC use for transacting business with Lloyd’s Syndicates is mandated by byelaw. |
|
MRCe |
MRCe is the standardised format for endorsing any changes to a contract, formed under a MRC. |
| Own systems | Broker and carrier-own systems can be used to provide data, either directly to the JV Gateway or via a placing platform. For example; PAS, financial systems or where acting as a placing platform. |
| Phase one digital
|
Where end to end, ACORD based, automated downstream Digital Processing Services is not possible, central services will offer means by which any short comings can be remedied. These interventions are referred to a transition services and can assist where for example a complete and valid CDR is not available at the time of Technical Account processing &/or where the broker or carrier(s) have elected not to implement a ‘full digital’ operating model. |
|
Placing platfroms |
This includes Third-Party Placing Platforms (TPPP) and proprietary platforms. Both of these types of placing platforms have User Interfaces (UI) and those performing a 'Headless' function where no UI exists but rather data is exchanged between systems, through APIs. |
|
Platform |
Any accredited system that is acting in the capacity of a placing platform. |
|
Preferred platform |
The platform that your organisation uses to assemble data for the CDR. |
|
Provided fields |
The core data fields in the CDR. |
|
Signing down |
The broker completes the task of, where necessary, adjusting and notifying ‘signed line(s)’ to all carriers subscribing to the risk. Adjustment is required on occasions when a risk is oversubscribed, i.e. underwriters’ written lines exceed the total contract order then, absent some contrary instruction, those lines will be proportionally reduced ('signed down') by the broker until they total the contract order. An underwriter may insist on preserving their written line in which event the written lines of the other underwriters will be proportionally reduced until they total the contract order when added to the preserved written line of the other underwriter(s). |
|
Signed line |
The amount or proportion of a risk that an underwriter has been allocated by the broker’s signing down process. It may be the same as the underwriter’s written line or, if there is over subscription then participants may be signed down to a lower amount/proportion of the risk. |
|
Soft submission |
Triggered at any time throughout the placing journey via any accredited platform, ‘soft-calls’ to the JV Gateway allow participants to check the accuracy and completeness of the CDR data without creating a record in the Joint Venture Gateway (IROS) |
|
Structured data |
Structured data is the data which conforms to a data model, has a well defined structure, follows a consistent order and can be easily accessed and used by a person or a computer program. |
| Submission of the CDR
|
Submission of the CRP which contains the CDR data |
|
Submission platform |
The source of a CDR submission to the JV Gateway. This can be done via CDR API submission by a placing platform, or through direct CDR API submission by the broker or carrier systems. The data submitted must be agreed between broker and carrier(s) prior to submission. |
|
Technical account |
Risk Premium Accounting data. |
|
Warnings |
Warnings are intended to advise participants where submissions are atypical and would benefit from review. They do not prevent a full submission from being accepted into downstream processing. |
1. What are the consequences of not having a complete CDR?
The automation and simplification of risk premium technical accounting (and related tax and regulatory reporting for Lloyd’s Market) will not be achievable. Processing will require manual intervention by central services. This will cost more and take longer.
2. What happens if I complete the required elements of the CDR as lead insurer, but the follow markets do not? Will I still have to process the risk manually?
This represents an incomplete CDR scenario (see Q1).
3. How will queries raised on data required in the CDR be managed? Who is responsible for responding to queries?
The party who created the data will be responsible for dealing with any questions or queries raised by the party responsible for approving the data. Errors identified by the Digital Gateway Service validation will be returned to the source of the CDR submission. This source platform will be required to orchestrate the error resolution process and pass it to the relevant party for their review and corrective action.
4. If I am trading directly with another market participant and one of us sends the CDR via API to the Digital Gateway directly, how will the Gateway know that the correct sequence of presentation and agreement has taken place?
The ‘how’ is out of scope of the PRR Working Group and the consultation. However, for a CDR to be submitted, it will be required to have gone through a presentation and acceptance process. This will form part of the accreditation process for all submitting systems/platforms.
5. If the Technical Account (TA) contains information that is lacking from the CDR, can the data in the TA be used to complete the CDR?
No, it is the intention that the ACORD Technical Account submission will be validated against a complete and valid CDR which contains data that the broker and all carriers on risk have agreed at the time of the CDR submission to the Digital Gateway.
6. How will non-structured data be added to the CDR e.g. Schedule of Values (SOVs)?
This is a matter for the accredited system/platform operators to decide with their customers. What’s important is clarity on which party is responsible for creating the data from information sources they have in their possession.
7. Will an incomplete or invalid CDR impact the ability to effect a valid contract of insurance?
No. If errors are detected by Gateway validation with the completeness &/or validity of the CDR, this does not impact the contract formation.
8. How will non-bureau carrier lines written as part of a risk be handled in CDR processing?
Non-bureau lines should not be included in the CDR submission to the Gateway. If they are, they will be rejected by the Gateway validation. The Gateway Service operates to support businesses to be transacted using central Digital Processing Services.
9. Why has Lloyd’s mandated the submission of the CDR when the Lead Lloyd’s Line is written?
It is important for managing agents to record the insurance contract as soon as it is written and make the data available at the point of bind to drive all necessary downstream processing and reporting. This also provides improved visibility to a near real-time view of business being written which assists Lloyd’s in its market oversight and reporting obligations to regulators on the country/class exposure should there be an immediate need to (e.g. Ukraine). Currently, Lloyd’s gets visibility only once the business has been processed through XIS, which may occur many weeks after binding.
10. How will the data required for the CDR be created and approved during the placement process?
There will be a presentation and acceptance process, orchestrated via an accredited system / third-party placing platform, through which the CDR data will be assembled (created and approved) by the market participants involved. MRC data extraction solutions may or may not be involved depending on the method of CDR assembly in-play.
11. As an underwriter, should I check that all the data included in the CDR is accurate before it is submitted to the Digital Gateway?
Yes, the underwriter(s) involved in the risk need to be confident that the data has been accurately recorded before it is included in a CDR submission to the Gateway. Use of the ‘soft validation’ may assist with this, as may any data assurance processes carriers operate as part of updating policy administration systems with risk data. The underwriters decide how to manage this process and what assistance is required from third-party placing platform or data quality assurance systems they use.
12. As a broker, should I supply all the data that is required in the CDR?
Most of the data, but not all the data. MRC v3 content is an indicator of most, not all, data required for the CDR that the broker is responsible for creating.
Precise information is contained in the CDR Assembly Table
13. How can I ensure the completeness of a CDR for any given risk?
Users can optionally check the completeness of a CDR for any given risk by performing a “soft call” to the Digital Gateway. The response will highlight errors, queries, or missing information for a given risk. This can occur well in advance of written lines or submission of the CDR to the Gateway.
14. Will the CDR apply to non-London Market insurers?
No, unless the non-London re/insurer is a central Digital Processing Services customer. See Q8 also.
1. As a broker, how significant are the changes in the process required to submit a complete CDR?
It depends on how far that broker is on their journey to being a ‘data-first’ operation. No fundamental changes to the Submit, Quote, Bind, and sign Down placement process were proposed. However, what is required is earlier creation and approval of risk data and interaction with the Gateway Service, which validates that data.
2. Can I send the data required to complete the CDR via ACORD placing and pre-accounting standard messages (XML)?
The CDR is using a JSON message standard. If there is an XML-JSON convertor, then it could be used.
3. What happens if a claim is received before the CDR is complete?
If a claim is received before the CDR for the placement is complete, then the claim will need to be validated against the MRC v3 and processed outside of the digital processing services solution.
4. Where will my third party supplier get the necessary information to understand how to implement the CDR submission process?
Each third party supplier who wishes to assemble and submit CDRs will need to go through an accreditation process. This will provide information on how to implement the assembly process within their solutions.
There will be an ACORD GRLC Contract, Risk & Pre-Accounting Toolkit available for third party suppliers.
Each supplier should have a dedicated point of contact through the Lloyd’s Market Engagement team, who they can reach out to with any queries.
5. What is the CDR going to be used for?
The main purpose of the CDR is to enable automated digital processing of risk premium technical accounts,Lloyd’s tax and regulatory reporting (if applicable) and automated validation of new claim notifications against a policy record.
6. Why does the CDR have to be ‘irrefutable’?
Automated premium processing is only possible if all parties to the transaction have agreed that the contents of the CDR can be relied on to validate the technical account submission. Avoidance of a situation where a broker or carrier says: ‘that CDR data is not reliable’ is the aim. The CDR also provides the data that will be used to fulfil Lloyd’s tax and regulatory reporting obligations.
7. What is the ‘definitive’ source in the event that the MRC (v3) and CDR do not match?
The MRC (v3) document which forms the basis of the contract with the client. However this entire consultation process aims to secure understanding and commitment to process, roles and responsibilities for ensuring the documentation and CDR data are consistent.
8. If the placing platform I use does not support the CDR, or business is written outside of a placing platform, how will the CDR be submitted?
There will be several methods and platforms available to users, and they can decide which one is most appropriate.
Some options could be:
• Use a placing platform which supports the CDR
• Build your own system/platform, but it will need to get accredited
• Use another service provider.
9. If I use multiple e-trading platforms to complete a single contract with a single Unique Market Reference (UMR), how do I create a single CDR?
You cannot submit the CDR in parts. Therefore, although you can use multiple platforms for any given CDR submission, you will be required to submit the entire CDR up to that point in the process, restating all data from any previous submission(s).
10. What are the benefits of this recommendation for me?
Refer to the Blueprint Two Benefits Framework
11. What happens if the CDR passes validation when submitted, but participants identify that there is something wrong and wish to change the CDR?
For any changes required to a CDR post-submission, an amendment will be required. For more information, please see the Market Journey section of the PRR Final Recommendations publication.
