By some accounts, straight-through processing (STP) is becoming downright common these days. Donald Light, senior analyst at Boston-based Celent LLC, estimates that in the personal lines property/casualty and automobile segment of the industry, 70% or 80%—maybe more—of applications are being processed using STP. “You’ve got rating and pricing and processing algorithms pretty much all in place,” he says.
In the commercial lines P&C segment, the rate of STP adoption is quite a bit lower, and straight-through processing tends to apply to a more limited range of products, Light says. For life products, it’s lower still, and it’s being applied mostly to simpler term life products and accidental death and dismemberment policies. Investment-oriented life products are just starting out when it comes to STP implementation.
Personal lines P&C is a concentrated segment of the industry, so saying that 70% or 80% of applications are processed straight-through is not quite the same thing as saying that 70% or 80% of personal lines P&C carriers process applications using STP. Todd Eyler, CTO of Fiserv Inc.’s Insurance Group, Brookfield, Wis., acknowledges that while there are significant pockets of STP implementation in P&C, it’s still early in the game for many insurers.
“Just thinking about the new business process, only a small minority of P&C companies have really modern, Web-based rating engines, for example,” Eyler says. “Many are working with 20-year-old or older policy admin systems that aren’t designed for the high levels of automation or integration that would really be required for STP.”
Usually, carriers implement STP either to attract new business or save money—or both. “Many of the products in the P&C segment are arguably commodities,” says Eyler. “If you want to differentiate yourself as a carrier, there is a finite set of things you can do. You can reduce your price; you can increase your commissions; or you can increase service. The first two options don’t necessarily have a very good impact on the bottom line, so really the best lever to pull is service.” Carriers can improve the buying experience for agents and customers, Eyler continues, by providing a more transactional, efficient, automated approach to service.
John Kellington, senior VP of the Association for Cooperative Operations Research and Development (ACORD), Pearl River, N.Y., sees STP as a way to wring costs out of carrier processes through more effective and efficient mechanisms. Coincidently, as STP momentum builds among carriers, the effects spill into other areas, too. “It makes the agents more effective,” he says. “They focus more on selling, as opposed to processing orders. This type of technology and this emphasis are healthy for everybody.”
“It’s about performance efficiency,” says Jamie Bisker, global insurance industry leader of the Institute for Business Value at IBM Global Business Services, and that ultimately means reduced costs. “You get efficiency in cost, in how you’re spending money to accomplish your goals,” he says. “At the same time, you’re reducing time—again, a component of the efficiency measure, which provides better service. We tend to think of service performance in terms of policyholders. However, it’s equally important to the internal service deliverers, whether they be agents, underwriters, customer service reps—they and the policyholder benefit when you’re talking about straight-through processing.”
Since it touches many processes, it’s tempting to view STP implementation as an enterprise-scale undertaking. Tackling STP as a single, organization-wide initiative potentially delivers the biggest bang for the buck, Bisker says, but “if you want to go about it in a more measured manner, it can be done.”
There’s nothing wrong with implementing STP one step at a time, as long as each step is consistent with past and future steps, IBM’s Bisker says. “It can be done, but it has to be done not thinking about making the first task the bright and shiny object. It’s got to say, ‘this powerful component of our value chain will be implemented in such a way as not to constrict or constrain the rest of our efforts as we proceed toward the strategic goal of improving our overall performance.’”
“Certainly, getting a start on implementing STP can be done regardless of what stage a carrier is at with its legacy systems,” Kellington says. “And, once a company implements, say, real-time billing inquiry or first notice of loss, the next steps toward full STP get easier, partly because the technical skills learned in the first step can be applied to succeeding steps.”
And it can be more than just experience that gets reused, Bisker says, noting that technologies such as service-oriented architecture let carriers avoid lots of recoding as they move toward STP. He cites a project IBM worked on with a larger carrier where more than half the services the IT team coded were reused. “That’s 50% of the code they didn’t have to rewrite,” he comments.
INVEST IN NEW SYSTEMS?
If you’ve upgraded your policy administration software, or any large system, recently, you probably already have elements of STP built into that system, says Rodney Griffin, senior VP for P&C product development and management at Fiserv. “Many of the older, legacy systems relied on batch processes and, while they had some transactions that were straight-through, they still had to wait for some kind of organized batch processes,” he says. More modern systems have mostly eliminated those batch processes in favor of real-time processing.
But it’s certainly possible, though a little trickier, to implement STP without installing major, new systems. “There are two broad categories of approaches,” says Griffin. “One is to build the capability internally within the actual application, and obviously a revamp of the application or a new application can provide that capability.
“But there is a large industry of vendors in the BPM [business process management] space providing some of these capabilities from an external perspective.” It’s inefficient, and adds a layer of maintenance and cost, Griffin continues, “nevertheless, you can achieve a tremendous lift and improvement, and extend the life of legacy systems by using BPM-type technologies.”
The elements needed to assemble STP, such as workflow automation and BPM capability, are more likely to come together when there has been an upgrade to, say, a new policy admin system or, in a more limited sense, a new underwriting system built on a modern language and modern platforms, Light adds. “If an insurer has acquired one of those, it then has the right tools on its workbench to design and implement STP,” he says. “If a company has not done that, it still can assemble the pieces, and with a strong rules-based or BPM system you can do STP with legacy systems, but it is more challenging.”
Full, front-to-back STP may not always be practical, says Griffin. “I don’t think one necessarily looks for 100% STP throughput of a particular transaction. Systems have some kind of assessment or triage process, which may be business-rules-driven, that you weed out the exceptions,” he says.
“What you’re trying to do is get the bulk of the transactions through—the kind of stock, standard, bread-and-butter processing,” Griffin continues. “I don’t think it’s a question of 0% or 100%; it’s usually a hybrid of manual intervention and straight-through processing for a particular transaction, so you can handle those exceptions.”
STANDARDS ENABLE STP
Perhaps the most significant enablers of STP are standards from industry organizations. Best-known of these is ACORD XML. Within ACORD XML, there are three domains: reinsurance and large commercial, property/casualty, and life and annuity.
ACORD XML originally was developed for interbusiness communications, between agents and carriers, for example. But increasingly, Kellington says, it’s being used internally, within individual carriers. “It’s very important to have an enterprise standard, a way for systems to communicate with one another,” Kellington notes. “With the ACORD standard being available in the public domain, it just makes a whole lot of sense to tie into that.”
The ACORD standard consists of hundreds of XML messaging structures—for billing inquiries, first notice of loss, quote and issuance and many more. New specs are proposed from time to time by working groups, they’re reviewed and voted on, and if they pass, they become part of the standard.
Kellington plans to take the process in a slightly different direction, by developing a “standards framework.” The standards framework is a series of enterprise models, he explains. One is called a capability model, a model of end-to-end insurance capabilities, “almost like a fictitious organization chart,” he says.
Next comes a process model that reflects the processes implied by the capability model. There’s a dictionary that defines terms and, finally, an information model that shows how everything relates to everything else. “I could take the business requirement, use process or data modeling techniques to model that business requirement in the enterprise framework, and drive the messaging scheme from that,” Kellington says.
In effect, Kellington’s models also would embed best practices into the ACORD standard. “We’re developing standards for the insurance industry, and we really need to follow the same best practices that the industry has,” he says. “Just because we’re creating a messaging standard doesn’t mean we’re off the hook. We still have to think enterprise; we still have to think about how that impacts insurers when they receive the messages, how they digest it and so on.”
On the investment products side, the National Association for Variable Annuities (NAVA) has developed its own set of STP standards for life companies that sell annuities. Newer than the ACORD standard, the NAVA standard is just over a year old and is meant to reduce the complexity of buying and selling annuities, and put them on more equal footing with other investments, such as mutual funds and stocks.
“One of the barriers to successful annuities investing is that the process of investing in an annuity is very complex, very paper-laden,” says Rob Dearman, assistant VP of broker dealer and RIA systems at Jackson National Life Insurance Co, Lansing, Mich. “It’s a multi-step process that is really more akin to a mortgage closing than it is to buying a stock.” Dearman is involved in four of NAVA’s six groups for STP implementation, and his own company has committed to participating in the STP pilot.
Annuities, he notes, are good options for retirement income, and as baby boomers approach retirement, there’s potentially a booming market for annuities. But that market is threatened by the complexity of the buying process, especially when compared with other, competing investments, Dearman says. Moreover, the brokers and financial advisers who sell annuities have to deal with different ways of doing business for each insurance company. They’re looking for a way to standardize how they submit new business, and they want to submit that business electronically.
“Many carriers were trying to leverage Web technology to make things easy on their own back office,” Dearman continues. “But it wasn’t being adopted at the rate they expected because at the point of sale, those reps didn’t want to have to know a dozen or more different systems. So STP overwhelmingly had the support of the insurance company partners of NAVA because they recognized that the only way we’re going to make STP happen is if it’s unified across the industry, and it’s easy to implement with our trading partners.”
STP RESPONSE
So far, the response among carriers to NAVA’s STP standards has been very positive, Dearman says. Distributors, on the other hand, “have been a little bit slower to the game,” he notes. That’s partly a chicken-and-egg situation: “Should carriers build the capabilities, or should they wait for the field to demand it?” NAVA is working with key distributors like Merrill Lynch and Raymond James, and Jackson National’s own broker-dealer firm, NPH, on implementing the standards.
One result of STP standards implementation could be to de-emphasize IT as a competitive advantage among carriers. Standardization, Dearman says, tends to commoditize some processes that carriers once used competitively — a shorter application form for agents, for example, or quicker turnaround on inquiries. In the annuities business, “It’s really pushing the competitive differentiators to be product features and service and performance—things that really matter to the end investor,” he says.
Formally, in standards-setting organizations such as ACORD and NAVA, and informally, through collaboration with peers and even competitors, carriers are sharing notes on STP, Bisker says. “I think we’re going into an era where it’s much more likely that some of these lessons will be shared, because it’s not an advantage, necessarily, to say that we are superior to our competition because we are so much better at IT. What people should be competing on is their ability to do the business of insurance, not necessarily the business of IT.”
Bob Mueller is a business writer based in Grand Beach, Mich.
Canadian Life Carrier Builds STP System
Four years ago, Assumption Life, a 100-year-old life insurance company in Moncton, New Brunswick, considered new ways to grow its business. The company sold policies and financial services in Canada’s eastern provinces, and its managers decided that one way to expand would be to sell its products nationally.
The question, according to Director of IT Derrick Smith, was how to get in the door at prospective brokerages. “We knew we had to have some sort of differentiator,” he says. “We couldn’t just walk in with the same products and the same processes that everybody else had. We looked at some other companies and what they were starting to do, and we decided to get into a quick-issue, online type of system where we could have an application sent electronically.”
Since most applications could be processed quickly, Assumption reasoned, so could commission payments to the producers. “That’s interesting to some of the brokerages in Canada,” Smith comments. “Instead of paying twice a month, we’re now paying twice a week. These people basically get paid within 48 hours of sending over a policy. Their pay is deposited in their account electronically.”
The first version of Assumption’s quick-issue, quick-pay system went live in 2004, with a simple life product. “We built an application that worked both from a Web site perspective, and as an installed application on the laptop. A broker or agent could be remote—not connected to the Internet—and still fill out an application with a client and submit it once they got back connected,” Smith says.
Assumption creates new releases of its system twice a year, each with new refinements. With each release, the company usually brings one or two additional products online. Input from producers play a big role in deciding what products are added, Smith notes.
“The initial versions of the system were certainly not what it is today,” he continues. Today, I would say pretty much everything that can be automated is automated. Back in 2004, there were certain steps that were still manual. They were invisible to the broker, but there were still some manual steps internally.”
The toughest part of implementing STP was building the front end for producers, Smith reports. “We had to make it simple to use because we knew that the buy-ins we were going to get from the producers often would depend on how simple they see the system.”
Other challenges included building links into Assumption’s policy admin system (originally a mainframe application, but recently switched to a Windows system), and making sure that the environment was stable and always up and running.
“We certainly had a variety of different challenges on the reporting side,” Smith continues. “All the data that moves around the system is XML. It includes information coming all the way from the PC application. All the streaming data is XML-based, and it moves in and out of the various systems we use.”
A key tool in implementing STP at Assumption Life was a product called XML Transport from Skywire Software, headquartered in Frisco, Texas, but with an office in Moncton. XML Transport transports documents into XML format, and Smith uses it throughout his organization.
“It’s been a great decision to go down this path,” Smith says. “It’s certainly made a difference in the volume of sales coming in through that avenue. We now do business in all 10 provinces in Canada. It seems like every time we put a new product on there, it grabs a few more producers’ interest and gets them on board.”
It’s also caught the attention of Celent LLC, the Boston consulting firm. Last month, Assumption won a Celent Model Carrier award for its STP system.
