Some technology is focused on the life/annuity market, some on the property/casualty market, and some on the reinsurance market. And sometimes, it’s just about the technology. For ACORD, that gray area has a place to go and thrive—the Common Services Committee.

ACORD has always concentrated on standards for the various lines of business, because they have a lot of synergy and there are components that are similar within the different lines.

As insurers move beyond the data model of those particular lines of business and discuss issues such as service enablement, document retrieval, process choreography, those particular areas aren’t line specific, explains Jim Brain, director of enterprise architecture for CNA Surety and leader of the Common Services Committee for ACORD.

“Because we had everything lined up in the particular lines, there has been a need to have another area for all those things that are not line specific,” says Brain. “Where should we put that?”

In the past, ACORD has had a joint technical group for this common ground and the Common Services Committee is the next iteration of that domain, according to Brain.

“Joint technical group wasn’t as descriptive a term, so we moved to a new nomenclature,” says Brain. “Common services is a place we can put things like AML, the new way of representing the data model for the P&C area. There’s also ACORD messaging service. The newest version of that is called the ACORD Web Services Profile, so you can use Web services regardless of what line you are in and how you can transmit that business data through Web services.”

If carriers communicate with their business partners through a Web services interaction, Brain believes they need to adhere to industry standards and also include business data that follows the ACORD standards.

“That’s a good indicator of the pieces in common services to take standards and either create them or leverage standards that already are available in the industry,” he says.

Standards groups such as OASIS, W3C, and IEPF aren’t insurance specific, but ACORD can utilize those standards and create guidelines and specifications that stipulate which of those non-insurance-specific standards are to be used and how they are to be used in order to transmit or receive insurance-related data, explains Brain.

“By extension, anytime there is an opportunity for us to leverage a standard in the grayer technology space—even if it’s not something ACORD came up with—Common Services wants to be at the heart of that,” he says.

As an example, one of the insurance lines could ask the common services group for a way to handle currency or payments. Should ACORD create a standard or have the common services group either set up a working group to create a standard related to that domain of concern or should it find industry standards related to accepting payments electronically so carriers can leverage those standards and specify their use within the ACORD environment, asks Brain.

MORE COMMONALITY

Brain believes that even within the individual lines of business insurers can create more commonality. He explains all three lines have the concept of a person or a party related to the insurance product.

“We always need to capture similar information—who they are, where they live, various contact information—so there is commonality there among the programs and that’s somewhat insurance specific,” he says. “We may need to capture other non-insurance related data, so we could use an insurance specific representation of that for all of our business lines as opposed to right now where we have a concept of a party from the life/health/annuity space, a different concept from the property/casualty/surety space, and another in the reinsurance space.”

The problem with the individual line approach is most evident for a multi-line carrier who has to manage the data in three different standards, convert to one of those standards or come up with some internal standard.

“You would still have to convert if you are talking to another business partner in the standard that is represented by that partner’s line of business,” says Brain. “There’s not a necessity to do that, but it is part of the historical perspective of how the ACORD lines grew into the standards they are today. Over time there will be a push to create some commonality, particularly beyond the business data.”

Common services can help carriers that have business processes that have to be handled in order to transact business, explains Brain. Those processes can be represented in a standard business process language.

“Over time I think the amount of similar data that can be leveraged among the different programs becomes a larger component so in the end you have a common component and business data portions that are specific to the various lines of business,” he says. “You are not going to have an auto object for your life/health/annuity business so that rightly stays in the property/casualty standard and is specific to that standard. The part that can be similar we should try and leverage from a common services perspective. That just adds to the amount of commonality through all the business lines and offers more opportunity for the common service program.”

NON-SPECIFIC GROUPS

When discussing ACORD standards you are talking about a vertical industry so those standards are at a very high level, just as there are for other industries, explains Brain. The higher the level of the standards the less you can leverage outside the domain, he adds.

“The highest level of standard isn’t going to be something we can leverage in common services,” Brain says. “But as you move down to lower levels, if they perform Web transactions or Web services, which is common now, they probably will use the underlying technologies that have been put forth by groups like Oasis, more of a technology group as opposed to a vertical.”

What it comes down to is there are certain things that are unique to the insurance space and they are not going to be represented anywhere else but ACORD, according to Brain, but the important part of common services is they need to draw a line that states what makes insurance standards unique.

“Whatever that is, it is something we need to manage, own and enhance,” says Brain. “But those things that aren’t unique to the insurance business—technology components or lower-level functionality—we should be looking at ways to leverage those standards as opposed to reinventing the wheel.”