The Core Data Record (CDR), facts and figures…
There has been a lot of noise about Blueprint 2, Market modernisation and more recently the CDR. Those that know me have generously tolerated my pathological interest in this and my eternal ability to spout specifics, sometimes to a seemingly endless duration!
This is not just because I have spent a long time reviewing the field-by-field detail – so as to fulfil my role as Advisor to the Chair of the Data Council and more recently as Chair of the Data and Standards group, but because I firmly believe in the motivation to provide a digital central settlement service.
Spoiler alert…. To do this it is not sufficient to be above the detail, strategic view is needed but not without understanding the mesh of technology, process and dependencies – it’s imperative to be up to one’s proverbial in the weeds.
Of course, there are always naysayers along the way: the document procrastinators as much as the process change adversaries and their valid views and concerns are amplified where the headlines are often without context or indeed detail. In turn this encourages the knee-jerk reactions to things cited as being too big to solve or chucked in the ‘too hard bucket’. Or politely dismissed as “the devil is in the detail” without necessarily looking into said detail!
Here the CDR is a classic example. From modest beginnings of around 80 fields then to 140 fields for first approval, then further extended to 199 fields prior to being aligned to the ACORD GPM, there are a few more required now it is being aligned… Sharp intakes of breath, tutting and head shaking, Gasps from all corners! Quickly followed by… “surely we can’t be expected to collect all that data for every risk!” *
Q: how many fields do we have to supply?
Ok, so what IS the devil in the detail? sticking to V3.1 for this analysis. The 199 number is, in fact, a feature of how to breakdown information into its small, identifiable, bite sized bits of data. this makes it clear and unambiguous. What appears in an MRC as “GBP 1,000 any one loss” is one innocuous line within a large, sometimes complex document, one piece of information, but is actually at least 4 items of data:
1. What it is – a limit,
2. A currency – GBP (using standard ISO code)
3. An amount – 1,000
4. A qualifier – any one loss
Q: So where else can the number be inflated but not meaning its new data?Addresses are a good example here. In the CDR there is an address for the Policyholder, for the Additional Insureds, the Surplus Lines Brokers and other intermediaries – all of them are always the same 6 items of data:
1. Name,
2. Street No and Street,
3. City,
4. Zip,
5. Country Sub-Div
6. Country
So a risk with one of each has 24 address fields not including the placing Broker’s own address that’s another 6, so 30 of those 213 are just addresses.
Q: What about how certain fields are presented?
A premium can be expressed as a currency and an amount (so, with a Type = Premium that’s 3 CDR fields) OR a premium expressed as a rate and a basis (also 3 CDR fields). So when we talk about the number of fields for premium that’s a list of 5 fields: type, rate, basis, currency and amount, but only 3 are will be necessary to complete. This repeats in commission, discounts, taxes and order.
Next, let’s consider the Conditionalities; the fields that only need to be reported under certain situations.
In the CDR, there are many more fields required for an insurance contract than a reinsurance one. For example, for a simple Fac RI, single section for a single type of insurable interest with no additional insureds or other intermediaries, it’s possible to complete a valid CDR with 54 fields and 4 of those are just expressing “Facultative, Non-Proportional, Excess of Loss, Reinsurance”.
Taking these fields and comparing against current MRC guidelines (which are prone to some interpretation!) only 6 fields are not in the current approach.
So yes, the devil is indeed in the detail!
So, what of the most complex of complex risks? Do we still get to top line number of fields? Let’s take a multi-section insurance contract for policyholders in Spain or Canada, with multiple taxes, discounts, fees and instalments for Marine, Aviation or Property insurable interests located in Australia or most of the EU, with an intermediary in Germany or Denmark who handle one or more of the taxes, with Company and Lloyd’s carriers then … (drum roll) we get to around 146 items of data (66%)
Q: But what about US Property
Even a US property risk with a Surplus Lines Broker and average other complexities only just breaches 120 data items.
The one watchout is to understand the rules (which are in the publicly available <Airtable>) to determine which data points are needed for which conditions.
Q:What else to consider that inflates the number?
Derived data is included in the CDR, the data that will be derived from other data supplied, six of the total are the Broker’s own name and address, in fairness they probably do know this! but there are 18** or so items of data that are derived in total.
Then, from the Broker’s perspective there are four items of data that are per carrier data and only known to the carrier, so the broker won’t collect them. it may be easier to not get distracted by the headline numbers, as once we understand that the headline number of data items is probably a little misleading, it’s not really in the ‘too hard bucket’.
Whatever your view on the numbers, they are probably less in reality than the headline. Even if there are some additional items of data required to collect in a uniform and standard way, why has there been push back? Given it would not be questioned as to the benefit of using “GBP” over “STG” for the UK’s currency (although of course that would be “GB’s currency”!) so adopting standards and consistency in data can only herald significant benefits. The CDR should not be an ambition, it should be the by-product of a greater digital strategy that causes barely a blip on the CIO’s radar of concern.
Q:But we don’t want our Producing brokers being data entry clerks!
Well they are already, if they typing the information into a document, File-Save As-last year’s slip, it would be great if the common data items were selected from lists and governed at the earliest stage eg: can’t handle business from Iran so IR is not a permitted country code to select.
Q: But what about the contract?
All this does not detract from the client contract. The standard data presented in a standard way, the bespoke clauses and wordings and products (and service) offering still remaining the competitive edge of the market practitioners. With a data first collection process, the document is just one of the output, not the source. That data can then be used and reused for multiple purposes.
So what’s stopping you?
** the proposed 213 is with 7 removed fields from V3.1 and 21 Added fields between V3.1 to proposed V3.2 – most are qualifiers for example a Unit of measure to qualify the Weight of an Aircraft or Gross Tonnage of a Vessel – else they may as well be measured in apples!.
* Risk codes have been agreed by all to remain primary for now.
Morning Data Blog 