In 4000 BC (give or take a century), Egyptians created papyrus,providing them with something more convenient to write on thanstone tablets. Papyrus evolved to paper, and over the next 6,000years, humankind perfected the art of producing it to the pointthat it became no longer the rare substance reserved for religioustomes and timeless manuscripts but one of the most ubiquitousproducts in the world.

One piece of paper, however, can have only one usea bill, a pageof an application, a sheet from a claim fileand it can be in onlyone place at a time. These limitations are why insurers have workedto achieve straight-through processing (STP) and to remove paperfrom the transaction wherever possible. STP, simply put, iscapturing data electronically and using that data throughout theentire insurance transactionissuance, bill payment, claims,reinsurance ceding, and so on.

The tools exist to achieve STP: The Internet has become themeans of connecting all the parties to the insurance transactionand exchanging data, XML has facilitated the process by helpingeliminate the need to develop custom EDI connections betweeninsurers and their business partners, and Web services are maturingas front-end technologies and effective integration mechanismsbetween disparate back-end systems. However, carriers have onlybegun to realize the benefits of STPs enter once, use many in theirbusiness processes.

The process that has gained the most traction across all linesof insurance, according to industry analysts, is acquisition. Thereare opportunities from end to end, from new business throughservice through claims, but the biggest are around new business,says Craig Weber, senior analyst in the insurance practice atresearch firm Celent Communications. Theres an opportunity toimprove the service to the sales channel and decrease the cycletime to get the policy issued. Anything carriers can do to speedthat up is going to carry a little extra weight over [otherprojects].

Life insurers in particular can benefit by automating thetraditionally paper-intensive new-business process, says JohnJohnsen, managing director of TCi Consulting and Research andformer insurance company CIO. Almost 40 percent of all paperapplications that are sent in are not in good order and need to getsent back or require a call back to the agent. The work involved inthat is enormous.

Theres a lot more pain in the life process, because the averagenew-business cycle time is about 45 days, Weber adds. On average, apaper point-of-sale application takes about 10 days to reach thehome office. So most carriers find that simply by capturingapplications electronically they can eliminate most of that delayand get underwriting information ordered almost instantly. And onceyou have the data electronically, theres no need to have anexpensive human interface between systems that use that data, whichis where XML has the most promise.

Maximize Sell Time
Zurich Life, Schaumburg, Ill., whose pending purchase by Bank Onewas recently announced (see sidebar, p. 26), realized the benefitsof streamlining the life insurance application process when theinsurer created a fax-based system more than five years ago. Agentswould complete a paper pre-application and fax it to ZurichsTeleLife unit, which would re-enter the data and complete afollow-up call to the applicant to fill in the remaining details.The aim, according to Michael Slades Sladek, senior marketingdirector of e-commerce for Zurich Life, was to reallocate the bulkof the cumbersome application process from the field agent to thecall center and maximize time for selling in the field.

The system achieved that goal and evolved to become the basisfor straight-through processing of new applications. In early 2002,Zurich completed conversion of the fax-based system to itsWeb-based Z-App (thats Z App, not zap) system. Rather than completea paper form, the agent fills out a pre-application online andsubmits it to Zurich. Application data is sent directly to Zurichspolicy administration system, and e-mails are automatically sent tothe TeleLife unit for work assignment and to the agent forconfirmation of receipt of the application. In 2003, the insureradded an electronic payments capability to the system to allowapplicants to submit electronic payment at the time ofpre-application.

We essentially said to the general agent, Its too costly for youto baby-sit term applications that are $300 a case, Sladek says.Rather than the agent completing all the application questions atthe applicants home or in the office, an agent can talk on thephone and, in under two minutes, submit the pre-application, whichimmediately goes into the call center queue.

Z-App runs in an IBM WebSphere, Java environment on Solarisservers running Unix. XML is used to connect Z-App with Zurichslegacy policy administration system from CSC, and it also lays thegroundwork for connection with agency management systems,third-party aggregators, or other future policy applicationsources.

Our agents told us that in the long run they didnt want thefunctionality [of Z-App] exclusively on our Web site, so when wedeveloped the middleware [to connect Z-App to CSC], the majority ofrules for data validation and system edits are built into themiddleware and not the front end, Sladek says.

Paramed reports and other supporting documents also are receivedelectronically, with the exception of attending physicianstatements. Zurich currently has not found the need to digitize orimage these statements due to the fewer than 10 percent ofapplications on which these statements would be ordered. At onetime, Zurich Life had an underwriting judgment processing system inplace, but the insurer found this system did not allow for theneeded flexibility in underwriting borderline applications andremoved it.

The Z-App system has met Zurichs objectives so far. Theapplication process for the agent takes less than five minutes. Italso has reduced the amount of paper sent back to the agent, theinternal errors, and the turnaround time because the data comesdirectly from the agent whos typing in the information. Its reducedour cost, and its increased our relationship with a number ofgeneral agents, some of whom have marketed Z-App so well theyvebeen able to double their production, says Sladek.

Last year, we saved about $90,000 in the first year ofinception. The system cost was a little higher than that, so itshould be a 24-month payback just in cost savings, Sladekcontinues. That doesnt include the fact a lot of our general agentshave improved their business, resulting in all the additionalpremium weve received.

Acquisition easier
While the pain point may be higher in life insurance for newbusiness, even in the other lines of insurance, acquisition hasbeen the area of focus. Part of the reason is other processes, suchas claims, tend to present greater business and workflow challengesfor STP.

Weve seen instances where [new- business STP projects] requirejust 20 to 40 percent of the effort to do claims processing, saysGautam Desai, vice president of research at Doculabs, a technologyconsulting and research firm in Chicago. He attributes that to thevariation of claims handling rules and processes among companiesversus the relatively homogenous process of, for example, personallines underwriting. Larger companies in particular see their claimsprocess as a competitive advantage, making it difficult for vendorsto create a single [STP] solution.

In addition, since the claims process involves ad hoc contactwith many potential third parties, it not only makes achieving STPmore complicated but also raises security concerns. Insurers seethe benefit to improve efficiency and lower their costs for simpleclaims, for example, by using policyholder service portals toinitiate a claims request and to take the data entry for that claimout of the call center, which lowers the transaction cost. But theissue is if youve created an automated end-to-end transaction inclaims, theres a potential for fraud. Theres only so muchautomation you can put in place, or else youll be very efficientbut losing money in the end, Desai asserts.

This is not to say, however, that insurers are completelystopping their STP projects at the acquisition level. AFLAC, forexample, is using the success of its new-business STP work as aspringboard for future projects, according to James D. Lester III,senior vice president and CIO of the supplemental disabilityinsurer. Its application system, SmartApp, dates back nearly 10years and is based on the system originally sold to AFLAC byPortable Systems Technology, the company Lester founded and workedfor before joining AFLAC in 1999.

For the past year and a half, AFLAC has been reengineering theSmartApp system, originally written in C++, to make use of Webservices technologies and Microsoft .NET. In January, we completedthe last engineering step in the process by taking a largeassembler batch program that handled underwriting and rating, saysLester. We now run it real time in WebSphere.

The SmartApp system is a core system for AFLAC, with 86 percentof the applications the insurer receivesabout 2.5 millionsubmittedelectronically via SmartApp. AFLAC has deployed the laptopcomponent of the system on 12,000 agent PCs nationwide. Agentstypically complete applications offline for batch upload.
Once AFLAC receives an application, SmartApp parses the applicationdata and passes it to the mainframe via IP connection.Simultaneously, the system renders an application image from thedata, which it routes to an image server, and also sends theapplication to an expert underwriting system built by AFLAC in Javaand running real time in WebSphere.

Nearly 55 percent of the applications routed to the underwritingsystem are jet-issued, meaning they meet underwriting criteria, andthese applications are routed for nightly batch printing andmailing. The system sends remaining applications to underwritersfor review.

Agents can, for example, transmit 100 applications and, sincethe system runs real time, dial in and see just how many [failed]and what error codes were generated, Lester says.

He adds AFLAC sees two key areas of opportunity for STP:acquisition and service. With the former firmly in hand, AFLAC hassought to target the latter. Were broadening our architecture toencompass other transactions and events, such as claims, Lestersays. As in new-business processing, STP in service also willrequire rearchitecting legacy service-based systems for real-timeprocessing and with component-based architecture.
AFLAC retained BearingPoint in late 2001 to help identifyopportunities for STP in service, from low hanging fruit to heavyresource projects. What AFLAC found was that, in contrast to theSmartApp system that was best served by an internal rewrite, theinsurers service systems will be best handled by using webMethodsto integrate applications and create new infrastructure forbusiness process management, automation, and monitoring. Thepurchase of webMethods was recent, and work is in progress withAFLACs current Internet-based billing system being the firsttarget.

Western-Southern Life, Cincinnati, Ohio, whose newstraight-through under-writing and application system was featuredin the September 2002 issue of Tech Decisions, similarly isplanning a gradual evolution of STP now that the system has comeonline in 2003.

The biggest payback has been in new business, but now that wewill be bringing the application into our systems in electronicform, we can automate other areas as well, says Jim Teeters, seniorvice president insurance operations for Western-Southern. The nextproject will involve automating policy assembly, andWestern-Southern has purchased Document Sciences policy solution toaccomplish that.

Once we do that, particularly with our captive field force, wewill be ready to take the next step of printing directly in theagents office, Teeters says. After our issuance projects, wellattack self-service over the Internet. Western-Southern currentlysupports the ability to do some changes to in-force policies viathe Web, but further work has been slowed by what Teeters reportsis the untested world of e-signatures. We still have to follow upwith policy owners and get a wet signature on Internet-initiatedchanges, he says.

demand-driven semci
In addition to meeting defined business goals, responding to marketdemands has driven and will continue to affect the insurers STPefforts. Perhaps primary among these demands is the clamor ofindependent agents for SEMCI. Left to their own devices, carriersprobably wouldnt push for [SEMCI]. But increasingly some of theirdistribution channels are demanding it, Weber says. The carrierdoesnt want to be marginalized, but if the [sales] channel is bigenough, its going to have more influence on how the carrier doesbusiness. There always will be some 800-pound gorillas out there,says Weber.

Because of the use of independent [agency] channels, theemphasis will be on capturing data through whatever tool the agentuses, Weber continues. However, most carriers still have captiveagents, or they have independent agents who dont use an agencymanagement system. So carriers need to support both methods of datacapture, through both proprietary portals and by interfacing withagency management systems.
Cincinnati Equitable Insurance Com-pany is an example of aproperty/casualty carrier doing just that. The carriersadministration systems for both policies and claims are based onApplied Systems Diamond platform. At Cincinnati Equitables own Webportal, agents have policy, billing, and claims inquirycapabilities, as well as the ability to report claims, requestpolicy changes, and apply payments posted in real time. Automationof the quoting and application process is in progress.

[The portal is] the primary method we support because about halfour agents dont use an agency management system, explains TerryBrown, vice president of information systems at CincinnatiEquitable.
Each of these transactions will process straight through theadministration system in real time with no additional intervention.When the agent initiates the transaction, a Web service is invokedthat passes ACORD XML into Diamond. Diamond returns the same XMLinstance to the Web service with additional data fields populated,such as policy numbers and error codes. The Web service thendisplays the result to the agent at the portal.

Cincinnati Equitable also accepts applications uploaded fromthird-party comparative rating software, which is more commonlyfound in the offices of the insurers agents. Applications upload-edvia comparative raters invoke the same Web service used by theportal. However, the process still involves some manualintervention at this time. The data gets into the system [from thecomparative rater file], but it usually has to be tweaked on ourend before it can be issued because of company-specific fields,Brown says. Still, a great deal of the rekeying has beeneliminated.

With its administration system based on Diamond, CincinnatiEquitable also has been in a good position to interface withTransformation Station, the XML-based communications infrastructurefrom IVANS that is supported by Applied Systems agency managementsystems. Support for Transformation Station is being rolled out atCincinnati Equitable on a transaction-by-transaction basis, withpolicy and billing inquiry currently available for auto andproperty. And, by using ACORD XML standards, Cincinnati Equitableeventually will be able to interface with other agency managementsystems and comparative raters as well. If the vendor can provideACORD XML, we love that, but not all vendors do. Some still provideonly text files, Brown says.

Zurich also built its Z-App system with the future of agencyconnections in mind and currently interfaces with Agencyworks in apilot program at the insurance distribution division of Bisys. Youhave to have development partners. In the first go around, wellhave select partners, but we support XMLife, so we can support any,says Zurichs Sladek.

xml supports stp
XML and the development of the various XML standards have beenessential for insurers ongoing STP efforts. The standards are awork in progress, but they are a very usable piece. We see manysoftware providers building in support of ACORD XML, but carriersare still experimenting with it: quoting, policy issuance, addingendorsements, renewals, billing, and claims inquiries. By no meanshave we peaked in our use of XML as a tool to enable STP, saysWeber.

If all of the software vendors were using ACORD standards, itwould make achieving STP much easier, adds TCis Johnsen. You coulduse one vendor for new business, another for policy administration,and it would be easier to pass data back and forth. Unfortunately,theyve got a way to go.

Also proving important has been the maturation of XML Webservices. However, rather than fulfilling their promised destiny asdistributed components accessible on an ad-hoc basis via theInternet, Web services currently are being used by insurers forinteroperability and integration of systems as part of STP, as inAFLACs and Cincinnati Equitables systems.

Web services are a key integration technology, says Desai. A lotof companies have built adapters that have exposed themselvesthrough Web services, but right now there still needs to be somesort of middleware to direct them, rather than having them connectpeer to peer. Thats important because what weve had happen iscompanies have built Web services to interact with mainframe[applications], but those services started taking up cycles on themainframe. Middleware allows you to plan for security and to managethose services in a centralized manner.

T+1
In addition to marketplace drivers, various regulations andindustry guidelines have impacted (or threatened to impact) the STPplans of insurers. The most visible among these has been HIPAA,whose requirements
include the upcoming October 2003 deadline for electronictransactions between health insurers and providers.

Another proposed requirement that has surfaced over the pastseveral years is T+1, which would require securities trades to besettled in the day after trading. The question has been just whatthis requirement would mean for insurers, particularly those thatoffer annuities and whole life products. While the SecuritiesIndustry Association, the driving force behind the T+1 proposal,has postponed the issue indefinitely, it is worth examining becauseof the number of financial services firms that have been workingtoward that goal.

The bottom line is that any future requirement for T+1 tradeswould have little, if any, impact on the business insurers do withtheir policyholders. Each policy is not managed individually. Its agroup of products that are managed as a fund, explains DavidCornelius, recently global STP leader at Cap Gemini Ernst &Young and now vice president of financial services at FileNet, acontent management and business process solutions provider.

T+1 would factor into any trades an insurer made to its owninvestments or to the investment portfolio supporting a book ofbusiness, but the compliance burden would rest with the securitiesbroker. Additionally, Cornelius sees any move toward T+1 being onlytangential to an insurers overall STP efforts. The emphasis hasbeen on linking order and portfolio management with financialaccounting systems to provide better real-time financial modeling,he says. Insurers are pursuing STP for cost or risk reduction,rather than any T+1 deadline.

E-Commerce/Web Services Tech Guide

Accenture
Palo Alto, Calif.
650-213-2000
www.accenture.com

AdminServer, Inc.
Malvern, Pa.
610.578.0112
www.adminserver.com

Allenbrook
Brunswick, Maine
207-725-6600
www.allenbrook.com

Applied Systems
University Park, Ill.
800-999-5368
www.appliedsystems.com

AscendantOne
Nashua, N.H.
603-598-5427
www.ascendantone.com

BMC Software
Houston, Tex.
713-918-2632
www.bmc.com

CGI Group, Inc.
Montreal, Quebec
541-841-3200
www.cgi.com

Connective Technologies
Houston, Tex.
800-856-6788
www.connective-edi.com

Connextions
Orlando, Fla.
877-772-6868
www.connextions.net

COSS Development Corp.
Milwaukee, Wis.
262-241-8989
www.cossdev.com

CSC Financial Services
Austin, Tex.
800-345-7672
www.csc-fs.com

Duck Creek Technologies
Bolivar, Mo.
866-DUCK-TEC
www.duckcreektech.com

EDS
Plano, Tex.
972-604-6000
www.eds.com/insurance
eHealthSystems
Sunnyvale, Calif.
408-542-4800
www.ehealthsystems.com

ePolicy Solutions
Torrance, Calif.
310-819-3210
www.epolicysolutions.com

Examen
Sacramento, Calif.
916-921-4300
www.examen.com

Fair Isaac
San Rafael, Calif.
415-472-2211
www.fairisaac.com

Fiserv
Brookfield, Wis.
800-422-3220
www.fiservais.com

Genelco Software Solutions
St. Louis, Mo.
800-983-8114
www.genelco.com

GRX Technologies
Providence, R.I.
401-331-6932
www.grx.com

I-Alliance
Indian Head, Pa.
800-997-5871
www.iallianceonline.com

INSTEC
Naperville, Ill.
630.955.9200
www.instec-corp.com

Insurity
Hartford, Conn.
860-616-7452
www.insurity.com

MFXchange Holdings
Toronto, Ont.
866-639-6399
www.mfxfairfax.com

National Con-Serv
Rockville, Md.
800-251-6274
www.accessflood.com

NaviSys
Edison, N.J.
800-775-3592
www.navisys.com

PilotFish Technology
Wethersfield, Conn.
860-257-0523
www.pilotfishtechnology.com

Results International Systems
Dublin, Ohio
614-540-3666
www.resultscorp.com

S1 Corporation
Atlanta, Ga.
404-923-7637
www.s1.com

SEAGULL
Atlanta, Ga.
404-760-1560
www.seagullsw.com

Sun Microsystems
Santa Clara, Calif.
650-786-0662
www.sun.com/finance

Swingtide
Portsmouth, N.H.
603-431-4081
www.swingtide.com

Torrid Technologies
Marietta, Ga.
770-565-6405
www.torrid-tech.com

TOWER Technology
Boston, Mass.
888-733-5500
www.towertech.com

Visibillity, Inc.
Chicago, Ill.
888-484-7424
www.visibillity.com

webMethods
Fairfax, Va.
703-460-2500
www.webmethods.com

Whitehill Technologies
Moncton, N.B., Canada
630-579-1534
www.whitehilltech.com

WorldGroup
Emeryville, Cal.
800-785-4526
www.wgcusa.com

technology a factor in bank ones purchase of zurichlife
Zurich Life considers its Z-app front-office system as acompetitive differentiator. This and other systems also werefactors in the recent decision of Bank One to purchase the insurer.According to a Bank One press release, Bank One identified thebenefits of Zurich Lifes front-office technology as well as stronglife and annuity back-office processes and systems.

There were many factors that made this [acquisition] attractive,and certainly technology was an important one, says Thomas A.Kelly, Bank One spokesperson. Zurich Life has committed a lot ofresources to technology applications to become a leading-edgeplayer, and we expect to reap the benefits of that goingforward.

Neither Bank One nor Zurich Life could comment on any specifictechnologies discussed in the negotiation. Michael Sladek, seniormarketing director of e-commerce for Zurich Life, reports Zurichconsiders its technology assets to include both the Z-App front endas well as robust integration technology that supports any mannerin which agents submit new business to Zurich Life.

We recently developed in-house a Java-based messaging middlewareapplication that allows general agents to submit electronically newbusiness from any platform, not just the Z-App front end, heexplains. It takes standard TXLife transactions and reformats themto the format required by the CSC [policy administration] system.If general agents want to work through an agency management systemor through their own Web site, this will import that XMLtransaction directly to the back end.
Additionally, Sladek references Zurich Lifes TeleLife unit andrelated back-office processes for new-business life insurance.After the TeleLife staff complete the application that wassubmitted by the agent, our back-office systems create anapplication packet that gets sent to the proposed insured, heexplains. This in turn is picked up by the paramed when he or sheis at the applicants house for the exam. When Zurich Life receivesthat application packet, it is scanned and linked to the examresults and other medical information for underwriting review.

Again, this streamlined application process is something we viewand market to agents as an advantage over other carriers, Sladeksays.