In the World of change, computing capacity doubles every 18 months, storage gets cheaper every year and regulation increases at a scary rate (although skilled resource doesn't get any cheaper!). This year will also see brokers face two specific challenges amongst their normal array of process change, tick boxes and reporting requirements.
These two are the unknowns of Brexit and Electronic Placing. I won't open the Brexit hornet’s nest, but the electronic placing challenge is one worth a visit.
I would hope all Lloyd's Brokers would have heard of PPL, the ex-AON Ri3K system that has been updated to meet the market's needs. One may ask - who was asked about the needs? The "market" had a requirements list I assume. Many obvious features appear to be well catered for in the deployed solution, and whilst I am an advocate of standards, collaboration and the return of the Common Core Record (CCR), I am also passionate about the need for the market not to replicate manual processes on a computer. I have seen this across many African countries leapfrogging technology from producing triplicate carbon copies of debit notes (in 3 colours) to requiring a computer to print 3 copies from different paper trays in their brand new, uber expensive, Cannon duplex, collating & stapling printer. This means REPLACING processes - rethinking, redesigning. I recently listened to a Webinar that had a well-qualified panel, discussing many of the recognised challenges this market faces. Many excellent points were made about cost of investment, change of process and the relevance of new technologies, but a significant aspect highlighted by the audience poll was the need for greater efficiencies which would cover the cessation of re-keying of data from one source to another. Was anything new highlighted by the audience or panel? There is nothing new about the striving for straight-through processing but the missing nugget from the discussion was how to connect the various systems. It is not just about going out any buying a new solution that will solve every question. If you are restricted by an incumbent system or availing yourself of a new one, the need to work with structured data requires connectivity between the systems, now and in the future. Think of it like the Skype button on your Outlook Calendar, a seamless practical one button (or no button) exchange of data or messages to retain one version of the truth. Here is where my issue is. Whilst recognising there has been some significant voices shouting and more activity in this are in the last 12 months than ever witnessed before, the issue still remains – the focus on the connectivity! In the automated world, we are talking API's and webservices. Whichever route is available to your organisation, it will need to use structured data - entered once. That Structured data can then drive augmentation to increase the power that data can leverage. It is now widely regarded that data is the most valuable commodity in the world. This means offering your partners and clients a webservice for their system to connect to, or a portal to capture and structure that data by product, or a method to repeatedly convert their data into a structured predictable form. Move to the other side of the equation - the onwards journey from your system to the next in the chain - now a webservice to connect to and send your data onwards, either based on a peer to peer or central services approach. To exchange this data in and out requires everyone agreeing what something actually is. The CCR was, in its day, a subset, albeit small, of a risk that everyone understood, a common set of items and known definitions. It would start with the UMR and include inception date, expiry date, number of sections, the clients name etc. Expand this out, and you get a common data dictionary. What would be logical, and very useful, is a common data dictionary, a market taxonomy - a set of standards the whole market can refer to. Enter stage left, ACORD. But this code set is vast, and with multiple sectors of the financial services catered for, code retirements and many having evolved over many years, it is not a logical tailored list for the wholesale insurance market. It needs context, even more so in an industry where we have so many different words for the same thing or the same word for different things; moreover names for things in their business process context not aligned to their computer behaviour process. Take "Risk" as just one example. So back to PPL. As a concept, in my opinion, full marks; As a platform choice I can see pros and cons, but there is never a perfect system so let's give it a B+/A-; As a participant in a joined up digital industry, I’d have to give it a D. But it wouldn’t take much to increase that failing grade? Easy, accessible, simple, stable connectivity and suddenly (with a little bit of that resource I mentioned) and core systems can send and receive data, preventing double keying and preserving that utopia of one version of the truth. Not just PPL but all of the various platforms. Everybody in this market wants to see cost-cutting through increased efficiency, the smooth exchange of data and the connection of multiple systems to augment that common understood data record - the need for efforts to be focused on the connectivity and standards is nigh, and the mantra that Integration will drive adoption to be fundamentally accepted.