Canadian Underwriter
News

What four insurers say about IBAC Data Exchange


August 13, 2018   by Greg Meckbach



Print this page

Reducing the workload for human beings is one reason some insurance carriers are participating in part of the Insurance Brokers Association of Canada’s Data Exchange project.

“We are constantly looking for ways to eliminate manual processes, to eliminate administrative functions, and try to focus those resources for higher value-add to clients,” said Mark Lipman, chief operating officer of American International Group Inc.’s Canadian branch.

Lipman was explaining – during the recent D/X launch in Toronto – why AIG is participating in a “proof of concept” of an application programming interface (API) intended to let a broker submit a first notice of loss (FNOL) to a carrier.

In essence, the intent of an API is to let a broker’s computer system communicate with an insurer’s computer system.  By contrast, many brokers say their people spend a lot of time typing in the same information twice – once in the brokerage system and a second time into a carrier portal.

Besides AIG, Saskatchewan Government Insurance, Travelers Canada and RSA Canada are also participating in the proof of concept.

In general, an insurer’s shareholders “are expecting to see some kind of uptick in the results of the company from an initiative like this,” John Elliott, RSA Canada’s senior vice president and chief information officer, said during the D/X launch, hosted Aug. 1 by the Toronto Insurance Council.

One upside for a carrier’s shareholders could be improved operating efficiencies, or  “taking human beings out of the chain in processing” information, Elliott said at the D/X launch.

With D/X, IBAC aims to reduce the collective time and effort needed to build APIs, or web services, that would let a brokerage’s software exchange information with a carrier’s software. With D/X, IBAC aims to give brokers, carrier and software vendors a “repository,” or a “reusable data services library.” That way, one company can build a data service and other companies could use it.

Insurers should work together instead of keeping APIs to themselves “and hoping somebody will come out with the next toaster, next best sliced bread,” Pattie Gibson, senior director for digital strategy and delivery at SGI.

APIs could be used for “simple things like direct billing inquiries, or claims status updates – those types of things”  said Steve Whitelaw, Travelers Canada’s vice president of information technology planning, execution and operational effectiveness.

“Last time I looked at the numbers, over 50% of calls into brokers were inquiry-related policy and billing,” said Whitelaw, who also volunteer as chairman of the board of the Centre for Study of Insurance Operations (CSIO). “Those are not value-add transactions.”

Carriers will benefit if they can “take out the cost” of dealing with such queries through initiatives like D/X, Whitelaw suggested.

“Where there is friction and inefficiencies, there are costs,” added Whitelaw.

“We make product sales harder than it has to be for brokers,” Gibson said of insurers. “All this information we need for rating – how can we simplify that and how can we use services out there to reduce the number of questions we ask and make that process seamless?”



Print this page

Related


7 Comments » for What four insurers say about IBAC Data Exchange
  1. I was at the demo and am very excited. The amount of time its takes just to get confirmation that a claim has been received and a claim number to give our Insured comfort the process is actually moving along — is at the moment grueling. I may not be a “techie” but Just this example illuminates the opportunities we can pursue via developing APIs as a community.

  2. Martin R says:

    If the IBAC is pushing a different agenda to what the industry is doing collectively I say to brokers push your associations to pull away from the IBAC. My company has taken the IBAO roadmap and adopted it for our own. We also take their timing. Next year we will build with them and our peers the access broker’s ask for. This is the fastest and best cost path for the industry. We spend now more than 40,000,000 on very poor data connectivity done vendor co to vendor co. It must stop. It costs too much and it is not good.

    • Michael Loeters says:

      Hi Martin. Your post suggests you do not have a good understanding of Data Exchange and the concept of re-usable data services. There is no one to one mapping of data as you are suggesting. That is the current expensive and non-feasible model which no one accepts as the path forward. I would encourage you to get the resources from the Toronto Insurance Council web site which I think does a very good job of explaining how Data Exchange actually works. Here is the link: https://www.ticbrokers.ca/initiatives/the-d-x-initiative . The reality is IBAO also supports Data Exchange and has always said it is where we need to get to. The reality is some industry actors want to get there now and not invest in an interim solution and as an industry we should respect that. We also need to respect those that feel an investment in an interim solution is their best path. We are all getting to the same goal.

      • Martin R says:

        I get you are a broker Michael. This is clear that you are not technical and I would like to guide you on this. My comment was on IBAC. They are supposed to be on side of the broker not the technology vendors. But they are undermining the work to benefit brokers. We don’t have any TIC brokers with our company. TIC can do what they want but as I say before you are not technically correct in your assumptions. I will contact you. Reusable data service is not what you think in insurance. How you present it is not the case. It does not work like that in insurance.

    • Martin R says:

      I look on your link also. The diagram is not good. There is big flaws. I will contact you. You need technical input from actual tech leaders from the tech focused insurance companies. https://www.ticbrokers.ca/wp-content/uploads/2018/08/Data-Exchange-Overview-FINAL-TIC.pdf

  3. Jack T says:

    I am a broker and I already have a call into my association. All of my markets are engaged with the IBAO project. It has real deliverables and real timelines and has given us hope that change will happen before we are put out of the channel by the big guys. I don’t get the specifics at a ground level. I do understand that the IBAO model looks to get everyone together with one connection from each insurance co. And that this will reach all the vendors. I know from my markets that the single connection is their preference as well. I am not surprised that the cost industry wide is more than $40 million. I know that when I golf with the vendor side they fly in on their private jets. I drive my VW! Things have to change. We need to remain together in alignment as an industry. I don’t know why IBAC isn’t with the brokers on this. Really makes me think on their motives. Why aren’t they supporting me the broker?

  4. The project TIC recently completed shows not only the importance of standards but how they can be used to deploy real solutions. BMS vendors have long advocated this approach which lays at the heart of IBAC’s Data Exchange model. Carriers across the country are starting to make the necessary investments to their infrastructure allowing them to develop APIs that can exchange data based on industry standards. The success of what TIC was able to demonstrate with their FNOL project follows similar success last year of Guidewire’s project which involved IBAC, CSIO, and two of Canada’s leading BMS vendors — CSSI and Keal. Demonstrating how live policy changes can occur or new policy issuance were clear examples of what this project accomplished. Using existing standards is a proven solution that already exists within the Canadian marketplace. I would encourage you to reach out to either myself or Mr. Loeters to discuss any other questions you have or if you wish to understand the D/X model more thoroughly.

Have your say:

Your email address will not be published. Required fields are marked *

*