Data-first or Document-led approach: What do you need to know?

Blueprint Two is the latest incarnation of London Market modernisation efforts with the benefits described as:
  • Better, by process re-engineering and technology deployment
  • Faster, by new technology infrastructure with a foundation of data right first time
  • Cheaper, for those that adopt the digital process flow

Whilst this is easily understood, the change and implementation required to get those outcomes is anything but. With approximately 70% of the London Market trading client contracts as Word documents – rekeyed several times over into various supporting administrative systems, we have a long way to go to achieve the benefits of a data-led and digital future.

What is positive is that if followed through, the changes led by Blueprint Two will achieve a consistency of process, technology and data across Lloyd’s and Company Market placements.

Brokers and insurers are aware of the challenges ahead; the need to drive change and solve those gaps or problems filed in the ‘too hard box’ can no longer be ignored.

This blog focuses on the strategic choices and challenges faced by Brokers and Insurers across:

  • The Core Data Record (CDR) – read r10’s “The Core Data Record explained” blog for more details
  • The new Market Reform Contract (MRC) guidance v3
  • Connectivity and messaging
What do these challenges mean, and what changes are required?

The answer is of course… it depends!

It depends on your digital and data aspirations, the volume of business you transact, your business case(s) and, of course, your budget. The available talent will also have an impact. Is your workforce data literate and digital savvy, or will you need to upskill, reskill, or bring in support?

The two ends of the spectrum are:

  • Data and digital-first
  • Do the bare minimum

Clearly there are several steps and options in between, and as has been articulated by the Future@Lloyd’s team, there is no, “no action” option.

Digital and Data-First Approaches

What does it mean for Brokers?

With data-first approaches, the data leads. Data is collected and ingested or keyed* into policy admin systems and data creates, for example:

  • the client contract MRC (including the clauses) compliant with MRC v3
  • entries into the placing platforms via API
  • the CDR is one of the outputs to the gateway** via API
  • other uses for risk placement and analytics

[* ideally data flows directly from the client; otherwise, data can be extracted using AI or rekeyed so at least the start of the broking process is data]
[** The digital gateway is focused on CDR processing. It will receive CDR APIs, then validate, augment and store these, as well as making them available for retrieval by carriers or brokers.]

 

What does it mean for Carriers?

Being data-first is slightly more nuanced for Carriers. It depends on whether data is sent directly to them from Clients or Brokers and/or augmented with Insurtech solutions or third-party data sources.

At this point, with the Brokers’ challenge of E&O, few are willing to send data directly and thereby documents are the norm and data extracted, cleansed, triaged, and augmented. Many Carriers are readying themselves and building API capability as and when Clients and/ or Brokers will be willing and able to send data directly.

A data-first approach should be the overall goal as data first allows for example:

  • straight-through processing, parameter-based risk triage
  • the foundations for automation of tasks
  • data augmentation
  • greater analytics, profitability, and performance analysis
  • the client contract and CDR are ‘created’ from the data
What are the ‘must-dos’ for data-first? [Highly simplified view!]
  • Before embarking on any data-first journey, it’s imperative to have a data strategy. All other activity stems from the data strategy aligned with the business strategy. Without it, tasks, solutions, and people are fragmented at best, silo’d at worst.
  • After the data strategy, the key step is a data model – how the data hangs together, the data hierarchy.
  • Underpinning this is data management, data quality and data governance.

With these in place, and acknowledging that the CDR is not the full data set for a risk (for example, the list of perils included is not a full list of all perils in the insurance world) but only those that meet the four use cases (processing accounting and settlement, tax, regulatory reporting and first notification of loss), what practical steps can be taken to collect the CDR (and broader) data needs?

  • Current state review – understand the current processes for data capture, who captures what data and when and where is that data captured?
  • Understand the CDR – what data is required, for what purpose (i.e. territory and/ or coverage), what are the reference lists and by when is data required. Read r10’s “The Core Data Record explained” blog for more details
  • Gap analysis – what is the difference or data delta between the current data process and the future needs of the CDR (and broader) data needs? A key component of the gap analysis is not only the data gap, equally a technology or system of record gap. Here, the partnership with the system vendor is key – what steps are they taking to enable the collection of the CDR data? How close are they to producing a client contract from data? Is there a capability to send data to other systems – for example placing platforms?
  • Future state view – creating a future state for people, process, data, and technology usage will enable key strategic goals to be met and tasks and a change agenda to be aligned.
    A “quick” win… rather than entering data into a Word document, which is still data entry, enter the same data into a system of record.
Document-Led Approaches

What does it mean for Brokers?

Where the client contract is in document form, and it leads in the placement process, collected data is either fully or partially* entered into a Word document and ingested or keyed into policy admin systems. The document:

  • is sent to the placing platforms as part of the negotiation process
  • is the partial source for the CDR

The action for the Brokers is to adjust their Word templates to be compliant with MRC v3.

Note: The data for the CDR comes from 3 typical sources:

  • The MRC v3
  • The schedule of values (SoV)
  • Tax schedules

For a document-led approach, all three documents will need to be presented for extraction to form the CDR and have the correct data available in the documents/spreadsheets for effective extraction. A data-first way of operating allows multiple data sources to be collated from the CDR.

[* many Brokers start some of the placing process in Client Relationship Management tools or Policy Admin Systems for the basic data, output into a Word template, and the process continues in Word.]

What does it mean for carriers.

As Carriers are dependent upon how a Broker presents a risk, and anecdotally this is approx. 70% document-led in the London Market, it follows that Carriers are mostly document-led. From the documents, each Carrier will extract data, cleanse, triage and augment the risk. The trend du jour is using AI extraction capabilities to achieve this aim.

With documents, is less bad good?

Market Insights

During 2022, r10 undertook a series of market research interviews. Where are Brokers and Carriers on this spectrum of document-led to data-first?

From our research, it was clear that there are a handful of standout Brokers in terms of data-first/technologically advanced and then there are ‘the rest’ who are all in a similar spot. The ‘pointy-end’ of the Market have new broker platforms, contract builders and data insights and are itching to send data via APIs.

When asked about high-level macro trends, data is the dominant theme with significant investment across the Market in accessing, engineering and mining data. There is a noticeable shift towards using data to make better underwriting decisions and increase profitability. Further, there’s an obsession with data extraction, and most are looking at solutions to scrape data from MRC to capture better structured data to inform their data model to enable opportunities such as feeding automated capacity follow syndicates.

Indeed, accelerated progess on the data-led journey could be made by investing in data-first solutions of data to data rather than data to documents to data.

Understanding the MRC v3 (as was the iMRC):

The MRC v3 is a new set of guidance for contracts. The main changes:

  • Guidance on the format of fields to enable consistency of understanding and computer ‘readability’
  • Clarification on sections
  • Broader tightening of the guidance from previous iterations
  • Additional data fields to support the collection of the CDR data

This set of guidance applies equally to those that are data-first, document-led or anywhere in between! The consultation draft version including an example template can be found here – limoss.london.

The MRC v3 document is the lowest digital (ahem!) adoption route and will be used to extract the data for the CDR absent an API route. This will need to be supplemented with the two other document types: SoVs and tax schedules.

For data-first, all required data can be collated to form the CDR as data.

Sidebar: Computable Contracts

For those that are data-first, the journey is towards computable contracts and the MRC v3 is a small micro-step in that direction.

One of many definitions from Axiome Partners:

Computable contracting is a set of approaches that enable contracts to be built as digital objects with significantly greater levels of in-built structure and logic and represented in a way that is understandable (and usable) by humans and computers. As such, computable contracting represents a fundamental shift in thinking, as well as an opportunity to re-engineer the foundations upon which the insurance industry is built.

This is where contracts are formed using a contract builder type technology and where the contract is built from data, including the clauses. This is still some way from being the norm although there are many very promising initiatives towards a fully computable contract.

What can be done now?

On the way to computable contracting, a short-term vision should be that the data collected in policy admin systems is used to create the document (it might look like a document but might be a rendered version of a document) rather than creating the contract in Word and then rekeying (possibly several times over). Also, that data is then available to be sent to other organisations as appropriate, including sending the data to placing platforms and also sending the CDR data to the gateway for processing.

The complexity of validation

So far so good….

There are new data standards, a few new data points to collect and a contract standard MRC v3. The one missing capability is that of validation. How do you know if your CDR is compliant?

How do you know if you have the right set of data to fulfil the CDR whether data-first or document-led?

A reminder: In v3 of the CDR, there are 112 conditional mandatory fields.

With this number of conditional mandatory fields, there are circa 750 different rules and permutations of the data. Conditional fields are also dependent upon each other in some instances. For example, if the territory of the risk is Spain, then it requires the Spanish tax information. If during the placement process Germany is added, then similarly it requires the German tax information.

This is an important point because the CDR compliance cannot be validated in a linear way, as much data as possible/ known needs to be present to validate.

Additionally, it is essential to understand why and how the data is not valid during the validation process in order for the data to be corrected. This is especially pertinent because some data is mandatory for Lloyd’s and yet not for the Company market therefore it’s key to know which markets will be supporting the risk. So, the CDR needs to be ready whosoever supports it.

Each organisation will therefore need access to a validation process and ruleset to ensure compliance. Some of this validation will be performed by the gateway on a ‘soft-call’ basis. This will be available at some point during 2023/24.

r10 is close to completing a CDR validation solution with our partners for those that are data-first, document-led or anywhere in between that will cater for the three document types: MRC v3, SoVs and tax schedules or a singular data feed.

For documents, data will be extracted, validated and compliance results returned with appropriate reasons for non-compliance.

For data-first, the same validation and compliance process.

This is especially useful for Brokers looking to update their document and understanding the data delta between the MRC and MRC v3 as well as ongoing compliance.

Get in touch with r10’s Advisory team to help you comprehend further CDR, and your Future@Lloyd’s digital transformation journey, including understanding, defining and implementing your strategic priorities – including a tailored data strategy, right sizing technology, IT and process change management.

Conclusion

Doing nothing is not an option.

A data-first approach is the direction of travel. Whilst a document-led approach might seem less complex, when digging into the detail is more so given the wrap-around components needed to make it work and the commensurate ongoing costs of using extraction software solutions.

A data-first option will return on the investment of acquiring that data if its is able to be reused for multiple purposes not stuck in a document – just think, no rekeying!

This is the biggest change this Market has seen since the creation of the bureau – is it going to work ‘this time’?

In short, the market momentum is building, several large Brokers are working on or have announced a digital and data-first approach and at least one is willing to share data directly with carriers.

The big win… if a broker is data-first, and if they send data directly to carriers, faster and ‘better’ decisions are the norm. Alongside the greater analytics, the focus can be on profitability.

About the author

Hélène Stanway is r10’s Director of Advisory. Hélène is an award-winning and highly effective insurance leader with a proven track record in emerging technologies, innovation, operations, data, change, and digital transformation. Hélène shares r10’s vision to help companies in the global insurance market embrace change by achieving their desired strategic goals, improving processes, increasing efficiency, and deploying relevant tools.

Share this page

Get in Touch

Contact us