Guillaume Bonnissent’s Insurance Technology Diary: Interfacial relations

Descended from Abyssinian gazelles, the last quadruped with unicorn DNA – the rarest animal of all – is the pushmi-pullyu. The horned, llama-like beasties are very hard to catch, because they have a head at each end and can always see you coming.

Doctor Doolittle author Hugh Lofting didn’t say much about the duo-cranial critters’ brain functions, be we get the idea that a pushmi-pullyu is very much like an imagined pair of conjoined twins, or the unfortunate Richard E Grant in his pre-breakthrough film How to Get Ahead in Advertising. Each end has its own brain and memories. They’re joined but not connected.

Insurance company technology is like a pushmi-pullyu. Most internal “tech ecosystems” have independent software, joined only by the company in the middle. The absence of a connection between them is a huge, lingering pain point for the sector.

Enter the application programming interface, or API. It has three key functions. First, APIs allow the front end of a web application to communicate with the back end. Second, APIs allow third-party data to be integrated into first-party systems.

In practice, this means you can feed data from, say, the Pacific Disaster Center straight into your exposure management system, or allow brokers to send submission forms from their own broking platform to your own underwriting platform. This ability to connect different players is the sexy bit of APIs. Insofar as they get any kudos at all, it goes to these “publicly exposed” connections.

But the other thing APIs do is far more useful for most insurers, given the current stage of the sector’s tech take-up. They facilitate the integration of different, existing systems within companies, and allow those disparate, now-connected tools to draw on and modify a single, central data repository.

These “internal APIs” connect the ends. All the gizmos in between can link up too, so they all sing always from the same song sheet, a.k.a. the central data repository.

There’s a hitch. Legacy systems can neither send nor receive data through APIs. That means many old systems cannot benefit from APIs. The solution is a mass data migration to extract the old data, then replacement of old tech with a new, modular system fed by a shared data repository – your new single source of truth. If that sounds expensive, start with just one function, or even a single team.

The big benefit is a seamless link between policy fulfilment, sanctions checks, claims, exposure management, accounting, and all the other disparate functions required.

The second big benefit is that all permitted users can select, display, modify and save data. Any of it can be reviewed or analysed by any function in the business at any point of the process.

Unfortunately, most people don’t think about APIs when they’re selecting new insurance technology. They should. Any new application absolutely must be API ready, or it will always be left in its own silo, deaf and dumb like an armadillo. It needs APIs to push or pull the data to wherever it’s needed.

Guillaume Bonnissent is CEO of Quotech