Many in the London Market perceive the Back Office as a group of admin staff that are just adept at using Microsoft Office programs, and that they hold the keys to the mysteries of slip wordings and Covernotes. In a large number of Brokers and MGA's that may be the case. So I ask, are they making anywhere near enough investment to make the changes needed to prepare for new technology?
When I look at the market as a whole, it seems to me that we are rushing ahead to buy the latest shiny technology but aren’t we missing a crucial step first? Ignoring the elephant(s) in the room! Crucially, the core of the current market initiatives are about sharing data in a structured manner. The London Market already has the data!
There are a small number of specialist Back Office systems, we are one, each with valuable accounting, risk and claim information. All captured in a structured database. Any system that can produce a policy document, slip or LPAN without manual intervention, from data in a database, has the data needed by the market.
However, the transport mechanism by which this data is to passed from A to B must surely be a secondary thought. Surely? When email was invented there were stories of people writing an email, printing it off and handing it to the recipient. In fact, jest not, the tendency for Brokers, even now, to use reals of paper to print off an email (usually forgetting each time not to repeat the history with the print!) and add it to the paper file, is still evident even today.
This is all about the data, something appears to be massive after thought despite a great deal being said about it. We aren't talking about Big Data here, in the scale of what the London Market is talking, these are Data ponds rather than Data Lakes! Granted the data may grow, but first let’s structure, define and convey what data we already have available to us.
As mentioned, the current Back Office systems already have the data. Software vendors would, I am sure, be more than happy to export, move, push, pull, submit or fold into a paper aeroplane the data that is required, if only that data and the meaning behind it were to be clearly defined and agreed by the market. The financial transaction, the associated Risk or Claim and the ancillary data available all must be understood as to its relationship.
Enter ACORD stage left. We have a standards body who are in a unique position to collate and evaluate the market's needs identifying a piece of data. For example, the number "123" in a field must identified as what it represents. Gross premium, net premium, IPT, or the extension number for a loss adjuster? The source Back Office systems knows the number, and it knows what it calls it, but to pass that onto the next person, it needs to identify it in a common way, and for that ACORD have defined a number of Code Sets. These already cover the Product, to Line, to Class, to Londonism relationships covering about 480 products; the kind of cover provided - there are 37 of those; the codes that go with things, such as States and Taxes and Countries (ISO and Cresta codes etc), the type of transaction of which there are 47; and so the process goes on. But ACORD needs to provide more around these codes; support, workshops, working groups, not with the Carriers but with the Vendors. They need to be relevant to the market now.
When we get into the elements of data required around the Risk, plenty of this is common (we used to call it the common core record back in the 90's - the inception date, the expiry date, the class (- see above) etc. The insatiable need for more data has been posing a gargantuan mole hill to all concerned, but why don’t we go back to basics and bring back the common core record?
Could the method by which we transport this data take a back seat for a moment, in preference of agreeing what is to be captured or passed on? If one party sends "it" by email attachment, another sends "it" by an ACORD message through a gateway, does it matter that much? More importantly let’s stop this being an obstacle to getting the data these systems often already hold into flow? Then we can decide what vehicle has the shiniest hub caps
Why is this such a challenge? Because no one person/body is in charge and the people requesting the data are from a market of Syndicates through 57 Managing agents covering those 480 products in various processing styles (Binders, Lineslips, Open Market, Treaty, Reinsurance) collating from around 255 Brokers and over 4000 coverholders. All wanting different bits of data so they can slice and dice to get the competitive advantage. However, the specification of the data needs a collaborative approach, back to the common core record.
I'd like to see a shift in approach, and I am not alone. The current vendors are able to provide the solution to the problem, but historically they have been made to feel like second class citizens, grasping crumbs from the table, and made to feel that they should be grateful.
They are only approached in the capacity to provide a product to solve a problem. The difficulty is that ‘The Problem’ is not clearly defined, and the definition itself needs the involvement of the vendors, only this time as Collaborators. Is it so unimaginable to get a group of vendors together to agree with ACORD the data available, the relationships between the items in a databases and push through acceptance for something that is a technology issue for the technologists, not a business one? After all Lloyd's has been a market place for a group of entities that are both competitive and collaborative for years, is it impossible to think system vendors could do the same?
Is it time we had a shift in the way we all look at this and talk about that elephant!
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly