Whose Data Is It, Anyways?

For a long time, industry observers have pointed out that many property and casualty insurance companies use a ‘silo’ method of storing disparate data and information. It’s a valid observation, but what about brokers? Every day, insurance intermediaries collect, store and send a myriad of client information. Yet when it comes time to access that data and use it to meet their unique business needs, brokers encounter far more obstacles than opportunities. For the modern broker, these hurdles exist for many reasons.

CHANGING LANDSCAPE

First, the nature of the brokerage landscape has changed. Increasingly we are seeing specialized, niche brokers in areas such as association or group marketing and distinct market segments (i.e. specialty commercial). We are also witnessing unique distribution strategies. For example, brokers may have closer links to one or more insurance companies, acting as a sales arm of the carrier(s).

The information needs of these brokers have changed dramatically in the past five years. Brokers no longer merely require the standardized reports generated from a broker management system (BMS). They need the ability to access and manipulate data for specific, targeted results.

Second, the stored information most brokers currently have is often customized in certain applications; there is limited ability for one program to interface with another. Therefore, if a broker wants specific information on, say, cross-selling travel and health insurance to segmented clients, the program has to be customized, often by a third-party vendor. This means there is no central data repository in the broker’s office, but rather a series of scattered programs and reports across the operation.

Third, many technology vendors seem to be moving in the opposite direction when it comes to openness of data and access to information. Instead of extending functionality and creating standard interfaces, some technology vendors are encrypting data and creating even greater barriers for brokers to access their own information. This is not the way to go.

UNIQUE BROKER NEEDS

Solutions should recognize brokers’ unique informational needs and requirements. The data residing in broker systems belongs to the broker, and Canadian courts have recognized this fact. Brokers’ data does not belong to the insurance company or the technology provider. So why shouldn’t technology applications and tools allow brokers to access data as freely as possible?

To achieve this goal, brokers need the building block of an application programming interface (API). The term ‘API’ has been thrown around a great deal in the past. A traditional API enables integration of two applications together in some way to perform a purpose or function. Historically, this has been a very technical exercise; programmers, for example, have worked on individual implementations involving customized development. If, for instance, a broker needs a specific report on fuel tax permits for long-haul trucking clients in the U.S., an API would bridge two applications such as a BMS and the application used by a third-party vendor or reporting service.

But the API can be used in a slightly different context. Instead of having a series of different API implementations, one type of interface can be provided so that all integrations are done using the same fundamental mechanisms. Using the XML format of the Centre for Study of Insurance Operations (CSIO) standard, this process has become much easier and more feasible. For example, Keal Technology has shown that, through its partner Brovada and the nexisys solution, brokers can exchange data seamlessly with insurance companies through the industry XML standard.

The next step, using API, is to open the door even wider, through standardized XML messages. We want to extend functionality beyond just sending policy information back and forth to insurance companies. The API allows brokers to access their information and manipulate it as they see fit without negatively impacting the product. That is the central benefit and the driving force behind Keal’s interest in the API.

Of course, to gain the full benefits of API, brokers need centralized control of their systems, with effortless access to insurance carrier data, client information and other third-party reporting services. The choice of what BMS to use is up to the broker, but the ideal solution is to have a central data repository that can send and accept XML standardized messages to and from various sources. This becomes the “master” repository for information; the broker can then integrate to whatever third-party source or vendor necessary. A good example of this is the sigXP system.

SEAMLESS LINK

The bottom line for brokers is they get the benefit of a better data view across their operations. Currently, various parts of broker operations have data stored in different applications: Web, BMS and third-party reports. API offers the potential for a seamless link between these applications, based on one industry-based XML standard. This extends functionality directly to how brokers use data and information.

For brokers needing ad hoc reporting capabilities, various tools on the market, such as Reporting Services and Crystal Reporting, can leverage Microsoft SQL Server databases upon which Keal products are built. This allows brokers to get access to the valuable data residing in their operation and use it for their focused business needs.

“We are able to access our sigXP database to generate a myriad of reports tailored to our particular business needs,” says Bill Corbett, manager, operation and systems for Vancity Insurance. “This includes daily revenue reports, which are automatically emailed to all of our branches and form one of their key business metrics.”

Corbett said his organization also uses data from sigXP to do frequent ad-hoc data analysis to better understand trends in its book of business. It can also be used to customize reports, allowing staff to manage their accounts on a daily basis.

Another example of data integration is when vendors provide underwriting evaluation and risk reports. If a vendor supplies this information in a program or report, a broker currently has to either manually re-type it or try to awkwardly merge it into the policy application. With a truly functioning API tool, the modern broker can simply integrate that data right into the BMS, based on the CSIO XML standard. As long as any vendor recognizes the standard, the BMS will recognize it as well through the API.

We still have a ways to go, but given the tools and resources that have been developed thus far, the time taken to implement such integrations or build ad hoc reports will be progressively faster and more robust. This is the direction that we must go.

Brokers need solutions that help them prospect for new business, manage and monitor their entire book of business and provide value-added services to their clients. Their specialized needs could be as varied as providing customized reports to niche customer segments or cross-selling to high net-worth clients. To achieve these goals, brokers need the ability to access and manipulate data for unique business needs. It is brokers’ data, after all, and they need the tools to help them use it effectively.

Open architecture, integration standards based on CSIO XML, enhanced reporting capabilities and more seamless methods of data capture, storage and access. These are the traits today’s insurance intermediaries should be demanding from their technology providers.