The only news that really matters in the world of insurance technology this week is the suggestion that Lloyd’s of London has abandoned its limping Blueprint Two initiative. The Corporation itself has said only that it intends to leave the ‘Blueprint’ brand behind, and that “Lloyd’s remains absolutely committed to supporting the re-platforming of the market to a resilient, cloud based operational infrastructure.”

Reuters The Insurer just reported that two teams of 26 people in total have been disbanded. Clever individuals no doubt, they had been working on delivery of the products and engagement sides of BP2. For everyone in Lloyd’s and the London market – even them – the death of BP2, if not greatly exaggerated, is an enormous opportunity.

If BP2 has indeed gone the way of T.O.M., Kinnect, Project Blue Mountain, LIMNET, World Insurance Network, RI3K, EPS-S, and the other market and broker digitalisation initiatives that were all launched with fanfare then quietly abandoned since the 1990s, we have a wonderful opportunity to try again, and this time to get it right. 

Before delving further into that glaring white light at the end of the tunnel, it’s worth celebrating the successes that rightly fall under the BP2 umbrella. London Bridge II, Lloyd’s own capital transformer vehicle, has been a huge hit with investors, channelling billions into Lloyd’s. So has the awkwardly named Syndicate-In-A-Box initiative, which has acted as midwife to a plethora of new underwriting operations that have expanded the market’s functionality despite its legacy systems.

Those aspects of BP2 worked because the people who lead them started by talking to the people who would use them. The transformer people talked to capital-markets investors that may be interested in investing in risk sourced at Lloyd’s. The syndicate creators talked to insurance entities that could be interested in taking advantage of Lloyd’s global licences, brand, reach, and central security. The solutions they constructed were built to give those people what they need to meet their objectives.

That didn’t happen in quite the same way for the biggest, most difficult aspect of BP2: replacement of the market’s semi-centenarian premium and claims processing bureaux. Instead, the Corporation asked consultants. The outsiders thought big, and Velonetic started building. (The company was still the cagey-sounding “Joint Venture” then, and had been called the London Processing Centre when it created the ill-fated EPS, the Electronic Placing System, in about 1997. In between it was Xchanging.)

Delivery was slow, in part because – like the Target Operating Model initiative which came just before it – no one had asked practitioners what would make their lives easier. The system’s anointed architects charged on to create a “digital cloud-based platform,” but skipped the step where objectives are set. Instead they raced straight towards the solution.

Radical technological advances have been realised since the launch of the re-platforming part of Blueprint 2. By the time the beta version had been built, technology had raced so far ahead that the new platform was a legacy system before it had been adopted. What BP2’s champion John Neal had said must be adopted universally by 2025 was pushed all the way out to 2028 by his successor, and then just for testing.

Now’s the chance to adopt a different approach. Instead of ploughing money into a new, faster, better cloud-based platform that’s simply better able to manage the same old spreadsheets, it’s time to take a breath and wipe the slate. We can then work to articulate more clearly the problems we are aiming to solve. Only after that hurdle is overcome should we think about the best and most appropriate tech we should adopt to make the market more efficient through technology.

The process should begin by asking day-to-day users of London’s systems what would make their lives easier. When users say that they’d like the data standard to be wider to include the fields necessary for their peculiar type of business, it’s time to ask them if they really need a data standard, because recent tech makes standards redundant.

When they say they’d like better bordereaux, it’s time to ask them to think outside the legacy process and outline the data they need, how often, and where. The bordereau is an old solution to the problem of getting data from coverholders. Instead of improving an old solution, we need to embrace the idea that an entirely new solution is possible, and could be better than even the best new spreadsheet (which, let’s face it, is only a digitised ledger).  

When they say they’d like a smoother interface between the claims and premium processing operations, the underwriting workbench, the placing platform, and the delegated authority systems, we ask them to define the problem they’d like to solve with their proposed improved connectivity. Maybe it’s their frustrating inability to easily reconcile the numbers, written and paid, and the claims that go against them.

Whatever, only after such a process can we begin to think about the best way to solve a real, underlying problem with the available, amazing, evolving technology. Instead of solutionising on top of old solutions, we abandon the legacy, then blue-sky new possibilities against the near miraculous abilities of the latest tech.

I know that’s all very much easier said than done. The BP2 debacle proves it. But as we, the market, embrace the opportunity to begin (yet) again on the journey to replace the Victorian pipework that runs beneath EC3, we must not say: “This is what we’ve built, and you must adopt it by 31.6.” If this time it’s different, we must first ask practitioners what they want, then think outside the box (pun intended). And maybe, just maybe, we should ask someone else to run the project.