Simplifying Data Delivery

What does it take for a broker to send a policy change request from a consumer to an insurance company electronically, and then have the insurer transmit the changed policy back into the broker’s data management system?

Thus far, it has taken an insurance industry investment of several millions of dollars, two abandoned high-profile, industry-wide tech initiatives (SYNCRON and the CSIO Portal), and now a new, cautious re-commitment among brokers, insurers and technology vendors to take a phased, flexible approach to broker-carrier data exchange.

The most recent effort, dubbed the Insurance Brokers Association of Canada (IBAC) Data Exchange Project, is a pilot project now entering its third and final phase. And although this will be the toughest phase of the pilot — completing a round-trip data exchange between broker and carrier systems — the progress thus far has generated some reason for optimism and enthusiasm.

Round-trip Data Exchange

IBAC’s Data Exchange Project is targeting a specific, common transaction between a broker and an insurer — a policy change request. The policy change request could be changing the vehicle, changing the driver or modifying the limits or deductibles of the policy. Pat Durepos, president and CEO of Keal Technology, one of several technology vendors working on the IBAC project, says his figures show policy changes account for between 28% and 35% of a broker’s transactions with an insurer.

For a broker, policy changes represent “a substantial proportion of the work that needs to be accomplished each day,” says Brenda Rose, an IBAC technology champion. “It is also not at all automated right now. It’s extremely labour-intensive. It’s extremely expensive for the work to be done, for both insurers and brokers. It’s expensive because there’s no premium generated. When you do policy changes, there are credits or there are charges, so it nets out. There’s all of this activity — people hours, paper, all kinds of turbulence — it’s costing all of this money, and there’s no payoff for it. And we’re doing it right now in the most expensive way we possibly could.”

That is, through re-keying of information. Why does this happen?

“A broker has his or her broker management system (BMS) with a representation of the policy in it,” notes Doug Johnston, vice president of partner relations and product innovation at Applied Systems, a software vendor working on the IBAC project. “However, the actual policy for the term…is at the insurance company.”

Fulfilling a policy change request requires the two systems to communicate with one another. “How are you going to do that?” Johnston asks. “Are you [as a broker] going to throw it on a piece of paper and mail it to the carrier, where someone there re-keys it and changes the policy? Or are you going to log into the carrier’s [electronic] portal, and therefore know how to use each one of your five or six carriers’ portals? All of that takes time. And in the meantime, you have a customer on the phone saying ‘How much is this going to cost me?’”

Time, as they say, is money. Keal Technology, another vendor involved in the project, recently held discussions with brokers that fixed a dollar amount to the lost productivity. “We talked to a group of eight brokers for [our] last presentation, representing $290 million of client volume, and we showed them that on every transaction, they were losing $5.04 every time they did a policy change,” Durepos said. “That goes across the country.” And while brokers lose money making policy change transactions, they are not talking to new customers about revenue-generating activities — like bringing in new policies to the brokerage. And with the loss of organic growth comes the loss of broker market share.

IBAC Data Exchange Project

What, then, is the broker’s endgame? When a customer calls to make a policy change, the broker wants to send an XML data record of that change to the carrier in real time through their BMS. The carrier would then take that record of the change, pull it into their back-end policy administration system, process the policy change and then send the new policy back to the broker — including the new billing amounts — within seconds.

The IBAC Data Exchange Project has established a framework of principles guiding the development of such transactions. These principles are:   
•    data transactions should start and end in the BMS;
•    data should flow between systems electronically and transparently, without user intervention or data entry on insurer portals, systems or pop-up screens;
•    transmission formats and content should strictly follow Centre for the Study of Insurance Operations (CSIO) standards;
•    insurer systems should immediately respond to requests from broker systems through means such as a simple acknowledgement, error message or, ideally, a complete return transaction; and
•    any translation or manipulation of data to accommodate an insurer’s system should occur on the insurer’s side of the transaction (not within the broker system).

Any tech solution will do, as long as it conforms to the above principles. Thus far, IBAC’s project has followed an incremental, phased approach.

Phase I involved verifying the vendors’ ability to generate one standard, specific, CSIO-compliant XML policy change transaction from within their respective broker systems and electronically transmit it to a specific location, kind of like an empty mailbox. In Phase II, now completed, CSIO reviewed and approved electronic messages submitted by two insurers, Aviva Canada and Intact Insurance, as sample automated responses to policy change requests from broker management systems (BMS). Phase III of the project, now underway, aims to link the data transactions between the broker BMS and the insurer’s policy administration systems. Vendors — including Keal, Custom Software Solutions, Power Broker, PolicyWorks, CIM-Data and Applied Systems — have been working with several participating insurers to pilot a virtual round-trip transaction from broker to insurer system and back again.

Key Challenges

This may sound easy in principle, but it is a major challenge. “One of the biggest issues is that policy change is the most complex of all transactions in insurance,” says Johnston. “It gets down to the complexities of how insurance companies are required to manage the data that represent their policies. There are regulatory and accounting issues that make the representation of a policy very complex within an insurance company. I think if most people could actually get a visual image of what the data records looked like within an insurance company to manage a policy, they’d be flabbergasted.”

The complexity is partly a consequence of an insurer’s obligation to report a policy change to a regulator. When a policy change is requested 95 days into a policy, for example, the original 365-day policy doesn’t exist anymore. So an insurer must then report to the regulator a transaction that essentially lops off the back 270 days of the full-year policy, showing the policy as it existed for the first 95 days, and then what the replacement policy looks like for the remaining 270 days of the 12-month policy cycle.

Things get even more complicated when you further slice and dice the policy. What happens, for example, if you issue a policy on Dec. 1, make a change on Jan. 20, and then the client calls back and says they forgot to report a change that occurred on Jan. 5? In this scenario, an insurer essential
ly has to report the original state of the 365-day policy issued on Dec. 1. Then it has to reflect the Jan. 20 change (by reporting the policy in force for the 51 days leading up to the change, and then for the remaining 314 days of the 12-month policy cycle). But once the Jan. 5 change is called in, the insurer then has to revert back to the original Dec. 1 policy for the first 36 days, apply the Jan. 5 change for the next 15 days, and then re-apply the Jan. 20 change to get back to what the policy really should look like for the remaining 314 days of the 12-month policy cycle.

Further complicating matters, insurers have their own back-end policy administration systems for implementing these changes. Each system handles these changes in its own unique way, and each process has its own timeframe. It is therefore challenging to link all of these various systems and methods of policy administration into a broker BMS.

Which is not to mention that each broker BMS is different as well. Scott Andrew, president and CEO of Custom Software Solutions, says even a simple request to change a deductible requires broker systems to contain information about multiple carriers’ underwriting rules. “If you do a deductible change — let’s say you want to go from a $500 deductible to a $1,000 deductible on a coverage item — you as a broker need to know the options [i.e. the deductible amounts an insurer offers],” says Andrew. “A $1,000 deductible might not be an option. It might be $500, $700 and $1,500 with that [insurance] company. You need that information in your program management system somewhere. You need access to that information, so you either need to request those parameters from the company system or you need to have a BMS sophisticated enough to know what those underwriting options and rules are.”

Cautious Optimism

For these and other reasons, IBAC’s data exchange project, which is currently in a proof-of-concept stage only, does have its work cut out for it. All vendors note Phase III will be the most challenging of all of the project’s phases, for a variety of different reasons.

Applied says the forthcoming introduction of its EPIC broker management system, anticipated in early 2013, will facilitate the kinds of transactions envisioned by IBAC’s project. Andrew says CSS pioneered this round-trip transaction 10 years ago, before an XML standard existed to support the transaction. “It’s just a matter of doing this within the selected (CSIO) standard now,” Andrew says. Durepos says brokers must now take up the banner and advocate for insurers to be aware of and become involved in the project.

Whatever the future challenges may be, participating technology vendors are striking an optimistic, if cautious chord. “If you put a group of smart insurance company people in the room, then a group of smart CSIO people and other brokers, you could probably figure this out,” says Johnston. “But it’s a very complex problem. We have talked to insurance companies that say, ‘We support our brokers, we support IBAC and we want to be supportive of this process. But technically this is really, really hard.’”