The Missing Link

“Nothing in this world is certain,” declared Benjamin Franklin, “but death and taxes.” If Mr. Franklin had been an insurance broker at any point in the past few decades, he would no doubt have added “double data entry” to his list of unavoidable afflictions.

Broker surveys across the country consistently show insurer stand-alone Web sites remain a major source of broker frustration. Although insurer portals do provide a quick fix designed to issue a policy or an endorsement quickly, the disadvantages to brokers of using the ‘do-it-yourself’ technology far outweigh the benefits.

Best practices for brokers dictate that all details for all transactions — new policies, renewal instructions, changes or even cancellations — must be recorded immediately in the broker management system (BMS), for a multitude of practical and risk management reasons. When the broker is also required to convey that same information into an insurer’s network, and if there is no automated means to move that data, then a manual double entry workflow is forced upon the broker. This additional work siphons time and resources away from client interaction and service. Duplicating clerical work also means a doubled exposure to errors or omissions.

The burden is further magnified by the fact that brokers work with a number of insurers, each of which employs a different system. Given that each individual insurer’s site displays different interfaces, uses separate passwords and involves dissimilar workflows, a broker must have all staff trained on a multitude of systems — either that, or else dedicate particular staff to each company. The broker risks further bottlenecks with the latter option, however, when their own dedicated staff takes vacation or sick leave.

In addition, often there are unanswered questions regarding long-term responsibilities that are not addressed in broker-company contracts. For example, if the broker and insurer end their business relationship, what assurances exist that information will still be accessible? The broker risks becoming dependent on the insurer to perform routine system operations and security, ongoing maintenance and training and ultimately the long-term preservation of business records.

Based on consumers’ expectations of rapid service delivery, brokers are already challenged to match the instant turn-around service of call centres and yet still deliver on their own multi-layered value of choice and individual customization.

Current economic realities have commonly reduced brokerage staff resources; more than ever, brokers must make customer service the priority. It is simply no longer possible to accept added layers of work, especially when technologies exist to eliminate redundancies.

The Insurance Brokers Association of Canada (IBAC) has long asserted that independent insurance brokers should not be obligated to use stand-alone insurer Web sites. It has formulated an official position to that effect. IBAC’s ultimate objective is to see a true SEMCI-based transaction model (Single-Entry Multi-Company Interface) in general use in Canada. Ideally, brokers should enter information directly into their own broker management systems and transmit the identical details to their insurer partners. The pressing need to improve data exchange between broker and insurer systems is evident.

Recently, IBAC has taken their fundamental assertions further, articulating how brokers would prefer to transfer information between broker and insurer systems without duplicated effort. Figure 1 provides a graphic illustration of the workflow endorsed by the national association. This is a representation of the brokers’ ideal process for all policy transactions, including new business, endorsements, renewals, cancellations, inquiries and claims. Fundamental to the design are some basic principles developed by consensus from broker association members, namely:

• transactions must originate from and return to a broker’s management system;

• all data transmissions must strictly adhere to CSIO standards;

• workflows must avoid connection to and a broker’s use of an insurer’s Web portal; and

• variations dictated by any unique characteristics of individual insurer systems are to be addressed on the insurer’s side of transmissions, rather than programmed into broker management software.

A limited number of broker management software systems are commonly used in Canada; in contrast, a complex variety of software is found among insurers. Not all those systems are fully compliant with current CSIO XML standards. As a result, they require proprietary translations to accept and use information sent in standard formats. With such a large number of variables among insurers, however, customizing broker software to accommodate each insurer’s unique features becomes highly complicated and resource-consuming. For the brokers at IBAC, it appears more practical, then, to construct the variations or specific programming necessitated by an insurer system on that insurer’s side of data exchanges.

IBAC set out in November 2008 to explore ways to improve efficiencies and test the practical application of their concepts through a pilot project with the industry’s leading BMS vendors. Quite simply, the purpose of the ongoing venture is to benefit both brokers and insurers through a more efficient method of exchanging electronic information between systems, and satisfying the basic criteria listed above.

The precise challenge of the pilot project’s initial phase is to verify 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 specified location. For this first test only, the destination was an interim ‘placeholder’ mailbox provided by CSIO, delivered by simple SMTP email. It was recognized, however, that a later question to be addressed would be to ensure a more secure means of transmission.

CSIO, the governing body for standards for the broker channel within the Canadian property and casualty industry, played a crucial role from the outset. In addition to providing direction on the use of the chosen XML standards, it served as the final authority to approve or disqualify test transmissions.

There was a lot of discussion about which particular type of transaction would be used for testing. In the end, the committee chose to use a policy change transaction, to help manage one of the greatest problems faced by the industry. While some types of transactions generate new revenue to offset processing expenses, endorsements are generally revenue-neutral, with return premiums averaging out to equal additional charges. Nevertheless, providing clients the option of adjusting their coverage is an essential service, regardless of the costs. Finding a way to better automate this labour-intensive work would result in substantial economies for both insurers and brokers.

Certainly the group had not set themselves an easy task. Natural human tendencies and the inertia of established practices always produce resistance to change. The vendors, too, took on this assignment in addition to the real, ongoing commitments and business necessities within their own organizations.

Nevertheless, the individual vendors worked diligently and managed the challenges. Some of the participants chose to engage third-party integrators to assist with the execution of XML translations. The working group compared notes at intervals via conference calls and in conjunction with some of the broker association conventions. Staff at CSIO an- swered questions about how the existing standards can be used, and ultimately evaluated the submitted transactions.

By September 2009, IBAC was very pleased to confirm that a majority of the broker management system vendors had successfully generated the standard CSIO XML policy change transaction as defined for this project. CSIO approved the final transmis sions submitted by:

• Keal Technology (sigXP);

• Policy Works, Inc. (Policy Works);

• Custom Software Solutions, Inc. (TBW); and

• Zycomp Systems Inc. (Power Broker)

In addition, CIM-Data (VCIM) is still working on and has committed to completing this phase of the pilot project shortly, pending only completion of some sub-contracted XML translation work. The sixth vendor, Applied Systems (TAM, Epic), was unable to allocate development resources during this phase, but has continued to participate fully in the working group discussions.

All project stakeholders have demonstrated a strong willingness to continue on to further stages. The next phase will involve the other side of the test transmission, that is, the reception and integration of the standard CSIO transaction by insurer systems. The committee is currently discussing potential insurer partners for this phase, while several insurers have already expressed keen interest in joining the effort.

Given so many key players working together in cooperation, our achievements thus far have been huge. The use of standard, automated communication liberates stakeholders to compete and distinguish themselves to customers through the content of their products and the quality of their service. And perhaps with greater awareness, further discussion and more exploration, some of the inefficiencies the industry now sees as unavoidable might just begin to be obsolete.