Countdown in Real Time

Use of the innovation initiative known as IBAC Data Exchange has resulted in some marketing departments blurring the lines of the project’s principles and definitions. As such, it may be an opportune time for a refresher on the project.

For those of us who wear the technology provider/partner hat and are vested in the broker distribution business, it is important to us that the right solution be identified. This will not only foster the viability of independent brokers, but also enhance their competitive advantage.

IBAC has been working with industry partners, insurance companies, brokers and broker associations, and broker management system (BMS) software vendors to pin down an acceptable definition of what “real time” data exchange is and how “real time” can benefit the industry. BMS vendors in Canada have been part of efforts to chart a path for its implementation from the onset, and IBAC has facilitated a spirit of great competitive co-operation.

What has cropped up, however, is the use of “real time” to describe integration processes that may not meet standards established by the IBAC initiative, producing some confusion within the industry. It is critically important that all industry participants possess a clear understanding of “real time” so that support can be given to the proper initiatives and projects.

IBAC literature generally defines “real time” as the ability to concurrently update a broker’s management system and an insurer’s system by exchanging standard, nonproprietary messages that are based on – and strictly adhere to – the CSIO (Centre for Study of Insurance Operations) XML language.

The literature goes on to describe what the “real time” process is not and what it is, namely that the communication taking place between systems uses XML as the language of choice, and any need to modify the content of this communication should naturally occur on the side of the transmission where the translation is needed. In situations – particularly when an insurer’s system is not capable of receiving or sending data in real time, or if its system is not built using a more current software technology platform – an insurer’s system may need to translate and store the incoming request so it can be processed at a later time.

When straight-through processing is not possible, a “real-time” response is limited to a simple acknowledgement of receipt. Similarly, workflows must avoid and do not require connection to, or a broker’s use of, an insurer’s web portal. Technologies such as bridging or traditional screen scraping have been developed and are used as a means to leverage an insurer’s web portal.

START TO FINISH

From a purely technical point of view, this approach will work. However, it is not ideal and can involve a much higher level of maintenance than solutions based on straight-through processing.

There are several properties inherent in the latter approach that support improved electronic workflow between a BMS and an insurance company’s system. Collectively, these properties define what real time is and, just as important, what it is not.

Consistent with the vision of a broker’s ideal electronic workflow, it is important that any and all transactions started within a BMS must also finish in the broker’s system.

The interaction between a broker and a customer requires a certain amount of data to be captured when entered into the broker’s system. Once completed, it is the broker’s system that initiates and sends the required data to the insurer’s system in a fashion that is secure, transparent, does not require user intervention, and strictly adheres to the CSIO’s standards.

A BMS is the originating system responsible for creating and sending the appropriate XML message for transmission to an insurer’s system. All too often, insurer systems have requested BMSs to send data in formats specific to them, which promotes inefficiencies in the workflow process by creating one-to-one relationships between each BMS and each insurer system.

Standardizing the method and content of the communication between systems promotes efficiencies and allows for the greater possibility of true real-time communication between these systems. The most ideal scenario would be one in which a BMS can transparently and electronically communicate with an insurer’s system – and uses CSIO XML as the language to do so.

This activity is performed as a function that is within and completely native to the BMS. The broker’s and the insurer’s systems will reflect the current status of the customer’s policy within seconds of that being updated from within the broker’s own BMS.

Today, there are many variations to this ideal scenario presented as being in “real time” when, in fact, they are not. Terminal or web-based screen-scraping tools, store-and-forward methods, batch systems and software-bridging techniques are among the common methods that may be disguised or marketed as real time. However, none of the aforementioned options comply with the standard, nonproprietary, straight-through, electronic message-based model illustrated earlier.

By IBAC’s own definition, it is clear that real-time policy change from within a BMS cannot be accomplished by using a web interface (portal) or middleware. Many existing company portals or middleware-provisioned services portals are being rebranded by simply not calling them what they are – portals. Portals that collect or change broker data after the BMS produces different data in both the broker and company systems. Some insurance companies and middleware providers are still trying to preserve this technology solution.

However, it is not difficult to identify the middleware solutions that diverge from the initiative.

This involves being presented with data collection screens that are not generated by your BMS provider. Divergence can further be confirmed if the resultant data collected in these interfaces is not retained in the BMS.

To concurrently update the broker and company systems with all data, one needs to start and end in the BMS. One cannot take a detour to some form of middleware (portal) and collect additional data for the company system without having a method to update the BMS.

IBAC has a number of companies committed to the Data Exchange project, with the goal being to start and end in the BMS, in real time, concurrently updating broker and company data. The foundation of this initiative is sound and with the involvement of BMS vendors from the beginning, that positive start can now move on to efforts to attract more insurer business partners until all are part of the initiative.

INDUSTRY-WIDE ADOPTION

This previously elusive objective now appears to be within reach. Brokers can do their part to help get there by using their considerable influence with carrier companies to garner support for the data exchange project as defined by IBAC, as well as encourage support for BMS vendors with a view to achieving industry-wide adoption.

BMS vendors, for their parts, will continue to compete on service and features beyond the ability to universally exchange data. This will undoubtedly lead to more research and development dollars being funnelled into the customer facing features – precisely where it needs to be.