What’s new with API links between broker and carrier systems?

Before the pandemic, brokers started work on a breakthrough application programming interface (API) tech solution. APIs describe communication between a BMS and insurance companies’ back-end systems.

Think of APIs as digital restaurant waiters who communicate broker/client orders to the kitchen, which is staffed by insurance carrier chefs. The chefs prepare the orders, and the APIs deliver the data requests back to the broker’s BMS. This eliminates the chaos of restaurant patrons (brokers/clients) going into the kitchen and trying to find the right chefs to place their orders.

For brokers, APIs arrived with fanfare in 2019, with public introduction of the Insurance Broker Association of Canada’s (IBAC) Data Exchange (D/X) Initiative.

That same year, Canada’s creator and publisher of data standards, the Centre for the Study of Insurance Operations (CSIO), formed the Innovation and Emerging Technology (INNOTECH) Advisory Committee to evaluate the application of new and emerging technology and digital innovation in the industry.

The committee prioritized three digital solutions that would have the biggest impact on the industry’s common pain points, including API data standards, to address the gap in real-time data exchange between brokers’ and insurers’ systems.

Since CSIO and IBAC shared the same aims, the IBAC D/X Initiative was folded into CSIO’s INNOTECH project over a year ago. Several brokers involved in IBAC’s D/X Initiative are now members of CSIO’s INNOTECH API Working Group.

Today, brokers are more optimistic about realizing a version of the Single Entry Multiple Company Interface (SEMCI) dream. Why? Insurers are replacing outmoded legacy systems with state-of-the-art Guidewire and Duck Creek real-time data-processing technologies — the first step towards making API a reality.

“If I had to point to one industry trend [that furthered development of API JSON (JavaScript Object Notation) standards], it’s that carriers are now going to the Guidewires and the Duck Creeks of the world,” said CSIO president and CEO Catherine Smola.

“As a result, they need these API JSON standards and implementation guides. That has been a big momentum shift, accounting for the speed with which we’ve been working on this.”

Three years ago, IBAC’s D/X Initiative took strides toward developing APIs with the creation of a handful of individual carrier-to-vendor API proofs of concept. A year later, IBAC collected API schemas (blueprints) from a large number of carriers and vendors for more than 30 API transactions. These schemas are stored on the CSIO website and are freely available to all CSIO members.

APIs ensured broker and participating carrier systems could exchange data for routine broker transactions such as billing inquiries, quoting, claims updates, first notice of loss, etc.

But when the work started, it became obvious more foundational infrastructure projects were needed.

“It became clear we couldn’t do these use cases until we had an industry understanding of what the security model was,” said Kathryn Sinclair, CSIO’s vice president of strategy and operations.

“After we formed the INNOTECH API working groups to develop the JSON API use cases, we kept coming back to, ‘How are we going to authenticate these third parties?’ We have to decide that before we actually [build the API standard for the use case].’ So, we collaborated with a consultant to help flesh out those standards.”

CSIO published its first API security model in April. It’s accessible to insurers and vendors on the organization’s website. With the security standard now published, brokers have been figuring out their priorities for use cases. In December, CSIO completed the business requirements for 40 different use cases on its 2022 API roadmap for using API JSON standards.

“Brokers really need to own the priorities,” said CSIO board member Steve Earle, president of Bauld Insurance. “The brokers understand which workflows are the most inefficient, the workflows that are costing them money, the ones contributing to the number of people [brokerages] are employing to click keys….Brokers can say things like, ‘Okay, on policy change to habitational [insurance policies], the return is probably X,’ but the complexity is far too high.

“So instead, let’s look at policy change in auto, where the return would be huge, but the complexity is not as high.’ So, we’d be looking at complexity versus return, and prioritizing [API] use cases based on that.”

This article is excerpted from on that appeared in the February-March edition of Canadian Underwriter. Feature image by iStock.com/Thomas-Soellner